amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste << 22 23 24 25 26 -27- 28 29 30 31 32 Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

05.05.2004, 15:18 Uhr

[ - Direktlink - ]
Thema: GCC 3.3
Brett: Programmierung

Zitat:
Original von Solar:
Zitat:
Original von gni:
Solar, Du hast bei Deinem Zitat etwas unterschlagen... putchar() ist genau wie putc() ein _Makro_! Das bedeutet doch wohl, das sowohl putchar() als auch putc() (und getc()) nicht als Funktion in einer Linker-Library sein müssen.

Der Linker hat ja auch keine "unresolved reference" gemeldet, sondern "can't find reference". Ich würde hier eher vermuten, das GCC bei Optimierung -O1 aus printf("\n") das "billigere" putchar('\n') macht, und sich dann irgendwo verhaspelt.
Macht GCC3 ja auch. Das funktioniert aber nur wenn putchar auch als Linker-Funktion existiert. Da die Man-Page es aber als Makro definiert, muss es nicht als "echte" Funktion existieren. Entweder GCC hat ungültige Annahmen oder Funktions-Makros müssen auch als echte Funktionen da sein.
Zitat:
Mein Zitat bezog sich nur darauf, das putchar() sehr wohl Teil des Standards ist; nicht auf die eigentliche Fehlerursache. ;-)
Ja, da hatte ich mich vertan.
 
gni   Nutzer

05.05.2004, 14:22 Uhr

[ - Direktlink - ]
Thema: GCC 3.3
Brett: Programmierung

Zitat:
Original von gni:
Zitat:
Solar:
Zitat:
Original von gni:
putchar ist keine ANSI/ISO Funktion und deswegen nicht Teil von libnix...

Da muß ich Dich enttäuschen... putchar() ist Teil des Standards, und definiert als "equivalent to putc with the second argument stdout"...
Tatsächlich, das war mir entgangen :-/ Da putchar als Makro in stdio.h definiert war, ist das Fehlen von putchar als Funktion nicht aufgefallen.
Solar, Du hast bei Deinem Zitat etwas unterschlagen... putchar() ist genau wie putc() ein _Makro_! Das bedeutet doch wohl, das sowohl putchar() als auch putc() (und getc()) nicht als Funktion in einer Linker-Library sein müssen.
 
gni   Nutzer

30.04.2004, 12:54 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
Mazze:
Zitat:
BTW, Du weisst, das GCC 3.3 unter Umständen bei Verwendung von LP-Inlines nicht-funktionierenden Code erzeugt?
Habe ich nicht gewusst. Allerdings muss ich ein #define setzen, wenn ich ReAction-GUIs erstelle. Dies hat möglicherweise etwas mit den LP-Makros zu tun.
Das ReAction-Define hat wohl nichts mit der GCC3+LP Makro Problematik zu tun.
Zitat:
Eine C-Funktion mit einem Pointer als Argument:
Bsp: void test(void *p)
würde ich in einer Library mit den Makros aus Clib-SDI folgendermaßen deklarieren
ASM(VOID) LIBtest (REG(a0, APTR p))
Kann ich a0 durch d0-7 ersetzen?

Ja. Manchmal ist es natürlich von Vorteil, wenn man Zeiger in Adressregistern übergibt. Da spart man sich u.U. ein "move". BTW, Ergebnisse werden unter AmigaOS/68k immer über _D0_ geliefert. Auch Zeiger ;-)
Zitat:
Leute, ich stelle das Thema "Library erzeugen" erstmal zurück und binde stattdessen den C-Code direkt ein. Wahrscheinlich habe ich einen Fehler gemacht, den ich erst finde, wenn ich mit etwas zeitlichem Abstand noch mal von vorne anfange.
Ich weiss nicht wie Du es gemacht hast, aber ich würde wohl Wrapper für die Original-Funktionen schreiben, da man dann die Originalquellen nicht ändern muß. Das macht die Bibliothek leider etwas langsamer, ist aber viel besser wartbar.
 
gni   Nutzer

30.04.2004, 08:58 Uhr

[ - Direktlink - ]
Thema: NcodeR mit Cyberstorm PPC
Brett: Amiga, AmigaOS 4

Zitat:
analogkid:
Zitat:
tploetz:
Hallo,
das Programm NCodeR läuft auf meinem Amiga 4000T mit Cyberstorm PPC
wie eine Schnecke. Für eine Musikdatei von 4 Minuten braucht
das Programm zum Encodieren 30 Minuten und in diese Zeit läßt
sich die Maus nicht bewegen.

was spricht gegen SecondSpin ?
Dessen Schutz des AREXX-Skriptes? Manipulierte Exe die an AREXX rumpatcht um das Skript auszuführen. Wer so was mag, kann es ja benutzen ...
 
gni   Nutzer

29.04.2004, 13:09 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
Mazze:
Zitat:
Machst Du Assembler oder C?
Ich programmiere in C und zwar gcc3.3 unter Amithlon/AOS3.9BB2.
Also C. In diesem Fall mußt Du Dir um Scratch-Register _keinen_ Kopf machen. Der Compiler kümmert sich um die Details. BTW, Du weisst, das GCC 3.3 unter Umständen bei Verwendung von LP-Inlines nicht-funktionierenden Code erzeugt? Das kann mit einem Update von inline/macros.h behoben werden, das aber noch nicht verfügbar ist :-(
Zitat:
Wenn ich in einem normalen C-Programm Registervariablen verwende, dann trifft es auf jeden Fall zu, dass die Registerinhalte an einen sicheren Ort gebracht werden.
Was ist für Dich eine Register-Variable? Eine lokale Variable mit "register" Zusatz? Oder redest Du von Parameterübergabe in Registern?
Zitat:
Aber was passiert, wenn ich eine Library-Funktion aufrufe? Weis der C-Kompiler, dass bestimmte Register (Scratch) "hinterrücks" von den Library-Funktionen verändert werden können?
Alle Libraries müssen AmigaOS-ABI konform sein, soll heissen alle non-scratch Register _müssen_ nach dem Funktionsaufruf den selben Wert wie _vor_ dem Funktionsaufruf haben. Scratch-Register _können_andere Werte haben, aber sie _müssen_ nicht. Wenn eine Funktion vom allgemeinen Schema abweicht, ist das meist dokumentiert (zb. Forbid/Permit, etc.) aber das ist nur für Assembler wirklich interessant. Für den Compiler ist der OS-Funktionsaufruf wie jeder andere, dh. er erwartet das "Standardverhalten".
Zitat:
Ich habe jetzt mal in der Library die Registerparameter a0 und a1 durch a3 und a5 ersetzt.
a4/a5[/a6/a7 ;-)] vermeiden. a4 und a5 werden vom Compiler verwendet. a0 und a1 sind vollkommen korrekt.
Zitat:
Jetzt bekomme ich im Test-Programm einen Parse-Error. Als Ursache vermute ich folgendes Makro im Inline-Header:
code:
#define sl_map(root, func, data) \
	LP3A5(0x3c, APTR, sl_map, APTR, root, a2, struct Hook *, func, a3, APTR, data, d7, \
	, SL_BASE_NAME)

Hier fällt zunächst mal auf, dass der 3. Parameter statt auf a5 auf d7 liegt.
und das Maktro heisst LP3_A5_. A5 kann nicht ohne weiteres als Argumentregister verwendet werden. Deshalb wird das Argument erst nach d7 (hoffentlich ist das frei ;-) gepackt und danach nach A5. Das wird vom speziellen LP Makro erledigt.
Zitat:
In meinem inline/macros.h ist kein LP3A5 definiert. Hier klappt offenbar das Zusammenspiel zwischen fd2pragma und gcc nicht.
inline/macros.h enthält nur die Makros., die von OS-Funktionen verwendet werden. Wenn eine 3rd-Party Library eine Kombination verwendet, die eine System-Libraries nicht hat, dann fehlt das Makro.
Du solltest Dir für Deine Library ein Inline erzeugen, die die LP Makros "direkt" verwendet (ohne Einbindung von inlines/macros.h).
Zitat:
Frage: gibt es einen Unterschied zwischen Adress- und Wert-Register? Kann ich eine Adresse an ein Wert-Register übergeben? Oder muss ich mich übergeben? :lach:
Die Frage verstehe ich nicht.

[ Dieser Beitrag wurde von gni am 29.04.2004 editiert. ]
 
gni   Nutzer

29.04.2004, 12:51 Uhr

[ - Direktlink - ]
Thema: BattClock
Brett: Programmierung

Zitat:
melior:
Zitat:
2. Wie sind denn die genauen Sekunden zwischen 1.1.1970 und 1.1.1978?
252457200 (ohne Gewähr)
IMHO fehlen da 60min: 2922 is the number of days between 1.1.1970 and 1.1.1978 (2 leap years and 6 normal)
 
gni   Nutzer

28.04.2004, 09:04 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
thomas:
Zitat:
Library-Funktionen werden _immer_ relativ zur Librarybasis aufgerufen. Direkte Aufrufe sind nicht möglich. Der Prototyp in clib/ ist nicht der Name der "echten" Funktion im Quell-code sondern der des Einsprungs relativ zur Basis.
Das stimmt so nicht. Wenn du nur die clib/xyz_protos.h einbindest und die amiga.lib dazulinkst, hat jede OS-Funktion einen C-Stub, der ganz normal mit Stack-Parametern aufgerufen wird und auch eine absolute Adresse hat.
Dennoch wird auch hier die Libraryfunktion relativ zur Basis aufgerufen und genau darauf kommt es an. Es ist völlig unerheblich, an welcher Stelle der relative Aufruf erfolgt. Hauptsache es wird so gemacht :-)
 
gni   Nutzer

28.04.2004, 09:02 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
obw:
Zitat:
gni:
Das habe ich auch so verstanden. Und genau das verursacht auch den Stackoverflow. Library-Funktionen laufen immer im Context des Programmes, das die Library benutzt. Wenn das Programm "wenig" Stack hat, Du aber viel benötigst, gibts einen Crash. Entweder Du verlangst genügend Stack oder Du wechselst den Stack, wenn zuwenig da ist.

Interessante Frage: Wie stelle ich fest, ob zu wenig da ist? Spontan
würde ich sagen: StackSwap() auf Verdacht und dann stk_Pointer und stk_Lower vergleichen. Dann wieder zurückswappen. Kann man als Stack für die StackSwapStruct einfach beliebig allozierten Speicher verwenden (Alignment?)?

Normalerweise über die SP-Einträge in der Task-Struktur bzw. Einträge in der Process-Struktur wenn das Programm aus der Shell gestartet wird. Wurde der Stack bereits ausgetauscht ohne StackSwap(), dann bekommet man ein "falsches" Ergebnis". Bei getauschtem Stack eines Shell-programms würde man auch "falsche" Werte bekommen egal wie der Stack getauscht wurde. Solange das Ergebnis lautet "zu klein" geht alles glatt ;-) War der Stack groß genug, wird ja wohl niemand auf die Idee gekommen sein ihn zu tauschen. Was man eigentlich wissen will ist, ob noch genügend Platz ist.
Zitat:
Zitat:
Library-Funktionen werden _immer_ relativ zur Librarybasis aufgerufen. Direkte Aufrufe sind nicht möglich. Der Prototyp in clib/ ist nicht der Name der "echten" Funktion im Quell-code sondern der des Einsprungs relativ zur Basis.
Wenn ich also eine Funktion habe, die sich z.B. rekursiv durch einen Baum arbeitet, mache ich das am besten wie? so?
code:
ULONG lib_func(ULONG foo)
{
  return do_func(ULONG foo);
}

static ULONG do_func(ULONG foo)
{
  [...]
  bar = do_func(bar);
  [...]
}

korrekt?
Ja.
Zitat:
Für lib_func() gibt es ein öffentliches Interface in den Includes. do_func() ist rein intern.
Ich bezog mich auf die öffentliche Funktion, die muß immer relativ zur Basis aufgerufen werden. Was dann weiter intern passiert, ist Sache der Bibliothek.
 
gni   Nutzer

28.04.2004, 08:54 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
Mazze:
Zitat:
Non-Scratch Register werden bei Funktionseintritt gesichert.
Angenommen, ich habe in einer Funktion eine Variable auf ein Scratch-Register gelegt.
Machst Du Assembler oder C? In C mußt Du Dich um so was nicht kümmern. Das erledigt der Compiler für Dich, weil er sich an ein ABI hält. Soll heißen, Parameter kannst Du in SCratch-registern übergeben, da der Compiler die Argumente bei Bedarf an einen "sicheren" Ort bringt.

[ Dieser Beitrag wurde von gni am 29.04.2004 editiert. ]
 
gni   Nutzer

28.04.2004, 08:49 Uhr

[ - Direktlink - ]
Thema: BattClock
Brett: Programmierung

Zitat:
melior:
Über die battclock.resource stellst Du nur die Echtzeituhr des Amigas. Wenn Du die Uhrzeit Deines Rechners dauerhaft verstellen willst, dann mußt Du sowohl die Systemuhr (timer.device:setSysTime) als auch die Echtzeituhr stellen.

Und das alles kann man sich schön im Quellcode von UnixClock anschauen ;-) Was auch immer es da nicht zu verstehen gibt.

[ Dieser Beitrag wurde von gni am 28.04.2004 editiert. ]
 
gni   Nutzer

27.04.2004, 13:40 Uhr

[ - Direktlink - ]
Thema: BattClock
Brett: Programmierung

Zitat:
THDany:
Ich will das die Uhr zur Sommer und Winterzeit automatisch die BattClock umstellt, spricht die aktuellen, mit time(); ermittelten Sekunden +-3600 in die BattClock speichert.

Eventuell ist UnixClock (AMiNet) Dir eine Hilfe. Das ist der Quellcode dabei.
Zitat:
#include <time.h>
#inclue <proto/battclock.h>

void main()
{
time_t jetzt;

time(&jetzt);

jetzt -=3600;

WriteBattClock(jetzt);
}

Du kannst nicht einfach OS-Funktionen mit Funktionen der C-Standardbiliothek mischen! Es gibt auch eine ReadBattClock Funktion.
Zitat:
Will ich es so compilieren bekomme ich die Fehlermeldung vom Linker, dass BattClockBase nicht nicht definiert ist.
Füge ich nun struct Library *BattClockBase; hinzu compiliert er das Teil anstandslos und beim Ausführen schmiert es mir ab. Ich würd ja gern eine Library für das Teil öffnen, nur welche?

Nur die Variable definieren reicht auch nicht. Schau Dir die Quelle von UnixClock an.
Zitat:
Oder mache ich sonst etwas falsch?
Ja. void main() ist falsch.


[ Dieser Beitrag wurde von gni am 27.04.2004 editiert. ]
 
gni   Nutzer

27.04.2004, 08:46 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
Mazze:
Zitat:
von gni:
Zitat:
Mazze:
Um der Fehlerursache näher zu kommen: Was passiert, wenn sich eine Libraryfunktion rekursiv aufruft?

Das klingt nach Stack-overflow.
Ich habe mich ungenau ausgedrückt. Die Funktion wird absichtlich rekursiv aufgerufen.
Das habe ich auch so verstanden. Und genau das verursacht auch den Stackoverflow. Library-Funktionen laufen immer im Context des Programmes, das die Library benutzt. Wenn das Programm "wenig" Stack hat, Du aber viel benötigst, gibts einen Crash. Entweder Du verlangst genügend Stack oder Du wechselst den Stack, wenn zuwenig da ist.
Zitat:
Zitat:
Library-funktionen (auch eigene!) sollten immer relativ zur Librarybasis aufgerufen werden.
Bei den eigenen Funktionen kenne ich den Prototyp. Aber in den Protos der Systemlibraries taucht doch der Basepointer gar nicht auf?
Library-Funktionen werden _immer_ relativ zur Librarybasis aufgerufen. Direkte Aufrufe sind nicht möglich. Der Prototyp in clib/ ist nicht der Name der "echten" Funktion im Quell-code sondern der des Einsprungs relativ zur Basis.
 
gni   Nutzer

27.04.2004, 08:37 Uhr

[ - Direktlink - ]
Thema: Timer
Brett: Programmierung

Zitat:
THDany:
Wenn das Programm keine Funktionen findet kann es diese auch wohl schlecht ausführen.

Der Linker schaut nur auf die Namen.
Zitat:
Oder gehst du jetzt nur von den Prototypen ohne Funktion aus? Die will mein Compiler (Storm C V3) auch haben sonst gibt es Fehlermeldungen.
Dann kann Dein Compiler den hier geposteten Code nicht akzeptiert haben. Ausserdem solltest Du auch casten. Z.B. der IO-Request des Timers hat die passende Struktur für die Exec-Funktionen (tr_node).
 
gni   Nutzer

26.04.2004, 09:58 Uhr

[ - Direktlink - ]
Thema: Timer
Brett: Programmierung

Zitat:
THDany:
Ja klar war es das __saveds. Hab den Timer aus nem anderen Programm das mit Near-Code compiliert wurde. Ich arveite aber mit Far-Code. __saveds gelöscht und schon gehts.

Wenn Du mit DATA=FAR[ONLY] kompilierst, dann bewirkt __saveds nichts. Das es ohne __saveds geht, klingt supsekt.
Warum Du im übrigen time.h einbindest, ist mit schleierhaft. Dafür lässt Du alle OS Includes weg.
 
gni   Nutzer

23.04.2004, 16:41 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
Mazze:
im Moment sieht es so aus, dass alles bis auf eine Sortierfunktion funktioniert.
Um der Fehlerursache näher zu kommen: Was passiert, wenn sich eine Libraryfunktion rekursiv aufruft?

Das klingt nacht Stack-overflow.
Zitat:
Werden dann die Register gesichert oder muss ich mich selbst darum kümmern?
Non-Scratch Register werden bei Funktionseintritt gesichert. Noch ein Hinweis: Library-funktionen (auch eigene!) sollten immer relativ zur Librarybasis aufgerufen werden.
 
gni   Nutzer

19.04.2004, 16:54 Uhr

[ - Direktlink - ]
Thema: Alle Laufwerke finden...
Brett: Programmierung

Zitat:
Holger:
Also bei mit steht in den protos:
code:
#if defined(__OPTIMIZE__) && !defined(__NOINLINES__)
#include <inline/dos.h>
#endif

Mag jeder selbst raten, welche compiler-optionen dafür gesetzt sein müssen.
So sahen GCC Proto/ Dateien ganz früher aus. Mittlerweile wird das inline immer eingebunden (hängt aber u.U. auch davon ab wer die protos Erzeugt)
Zitat:
Ich habe das Beispiel ohne weitere Optionen übersetzt und zumind. mit Version 2.7 keine Probleme gehabt.
Die Warnungen kommen nur wenn man die Inlines auch verwendest, was Du aber nicht getan hast... Dafür hättest Du optimieren müssen.
Zitat:
Allerdings habe ich den starken Verdacht, daß auch die inlines anders aussehen und bei diesem Beispiel auch keine Warnungen produzieren würden. Habe jetzt auch keine Lust, für dieses Beispiel jetzt noch andere gcc-Versionen durchzuprobieren.
[...]
Sollten neuere Compiler/Umgebungen jetzt Fehler oder unnötige Warnungen verursachen, ist das nicht gerade eine Motivation zum Umsteigen.

Das hat nix mit einer speziellen GCC Version zu tun, sondern ausschliesslich mit der Art des Inlinens von VARARGS Funktionen.
 
gni   Nutzer

19.04.2004, 11:09 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
Original von Mazze:
Nach dem ich free durch FreeVec ersetzt hatte, bekam ich bei dieser Funktion den Fehler mit der fehlenden SysBase. Der Fehler tritt nur auf, wenn ich die Funktionsadresse zuweise (z.B. func = FreeVec). Beim normalen Aufruf klappt das. Ich habe deshalb die Library-Funktion so umgebaut, dass keine Zuweisung der Funktionsadresse stattfindet.

Wenn Du die Funktionsadresse benutzt, dann verwendest Du den Stub aus libamiga.a. Alle dortigen Wrapper verwenden globale Librarybases (wie solls auch anders gehen?). Das Exec Symbol ist SysBase.
 
gni   Nutzer

19.04.2004, 11:05 Uhr

[ - Direktlink - ]
Thema: Library erzeugen
Brett: Programmierung

Zitat:
Mazze:
/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libnix/libnix.a(free.o)(.tex t+0x2a): undefined reference to 'SysBase'
/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libnix/libnix.a(malloc.o)(.t ext+0x18): undefined reference to 'SysBase'
[/code]
Da wird doch eindeutig noch free/malloc von libnix verwendet.
[code]
Ich verstehe das nicht. SysBase wird in libinit.c definiert.

Vieleicht als static. Der Linker kann aber kein globales SysBase finden.
 
gni   Nutzer

16.04.2004, 17:33 Uhr

[ - Direktlink - ]
Thema: Alle Laufwerke finden...
Brett: Programmierung

Zitat:
Original von whose:
Hm, also mit meiner GCC-Installation hab ich gar nichts veranstaltet... der 3.3 ist der aus der GoldEd-Installation und läuft ohne irgendwelche "Anpassungen".

Und welche Includes verwendet diese Installation? Die üblichen Inlines verwenden LP Makros und genau diese Includes sind dann auch die Ursache für die Warnungen der VARARGS Funktionen.
Zitat:
Der 2.95.2 ist der StormC4-GCC mit Includes die ich mir per fd2inline neu erzeugt hab, weil die mitgelieferten arge Probleme haben (weshalb meist ein NO_INLINE_LIBCALLS notwendig wird, wenn man AOS-Funktionen nutzt)
Wo wird NO_INLINE_LIBCALLS definiert?
Zitat:
Zitat:
Zitat:
Übrigens: Hat nicht H. Wrobel den ersten Port des 3.x erledigt? ;)
Wozu der Smiley?
Aus Spaß an der Freud?
Vermutlich weisst Du es nicht besser.
Zitat:
P.S.: Ich hab nochmal nachgeschaut, die "Option" heißt __USE_INLINE__. Ich nutz die beim 3.3 selten, weil ich den meist nur für Testzwecke einsetze. Beim StormC hab ich das als Default, da heißts dann "Dont inline" und ist ausgeschaltet.
Ich kenne auch __USE_INLINE__ nicht. Was soll das sein?


[ Dieser Beitrag wurde von gni am 16.04.2004 editiert. ]
 
gni   Nutzer

10.04.2004, 12:13 Uhr

[ - Direktlink - ]
Thema: Alle Laufwerke finden...
Brett: Programmierung

Zitat:
whose:
ob der GCC meckert oder nicht, sollte er den Jungs schon glauben, wenn sie es sagen. Bei mir meckern nämlich auch beide Versionen nicht (2.95.2 und 3.3)

K.A. was ihr mit euren GCC Installationen veranstaltet. Wenn Ihr keine Hilfe benötigt, ist ja gut.
Zitat:
Sagt Dir die Option "do-inline" was? ;)
Nie gehört. Aber gut, ich kenne den GCC auch nicht so gut wie Du...
Zitat:
Übrigens: Hat nicht H. Wrobel den ersten Port des 3.x erledigt? ;)
Wozu der Smiley?
 
gni   Nutzer

07.04.2004, 17:04 Uhr

[ - Direktlink - ]
Thema: gcc und floating point funktionen
Brett: Programmierung

Zitat:
nferno:
habe mal wieder ein gcc - Problem :)

Dokumentation lesen soll helfen.
Zitat:
---- test.cpp ----
Erster Fehler: Laut Suffix ist es eine C++ Datei, laut Inhalt aber C.
Das Frontend "gcc" wählt anhand des Suffixes den zu verwendenden Compiler. In dem Fall also the C++ Compiler. C Quellen verwenden ausschliesslich .c
Zitat:
c++ -noixemul -o test test.cpp

übersetze, dann funktionierts.

Das C++ Frontend (g++/c++) linkt automatisch gegen -lm -stdc++ (kann man gut mit -v sehen).
Zitat:
gcc -noixemul -o test test.cpp

übersetze, dann kriege ich die Fehlermeldung:

"/t/ccRj10SW.o(.text-0x30): undefined reference to 'sin'"

Hier wird der C Compiler benutzt und nicht mehr automatisch mit -lm gelinkt. libnix hat Mathe-Sachen in dieser Bibliothek. (ohne -noixemul sollte es ohne -lm gehen, da ixemul alles in der "normalen" libc.a hat.

[ Dieser Beitrag wurde von gni am 07.04.2004 editiert. ]
 
gni   Nutzer

07.04.2004, 16:47 Uhr

[ - Direktlink - ]
Thema: gcc und floating point funktionen
Brett: Programmierung

Zitat:
Otokai:
Im gcc.guide (gg:guide/gcc.guide)

Invoking gcc ->
Option summary ->
Machine Dependent options

findet ihr eine komplette Auflistung aller 68k (oder auch PPC etc.) spezifischen Optionen.

Die Amiga-Spezifischen Optionen stehen da aber nicht. Die sind in gcc-amigaos.guide erklärt.
 
gni   Nutzer

07.04.2004, 09:56 Uhr

[ - Direktlink - ]
Thema: gcc und floating point funktionen
Brett: Programmierung

Zitat:
Inferno:
Das Problem war die Reihenfolge. -lm muß unbedingt HINTER die object-files.

Das Problem ist das Frontend. Zum Linken immer das C++ Frontend verwenden, entweder c++ oder g++.
 
gni   Nutzer

05.04.2004, 17:34 Uhr

[ - Direktlink - ]
Thema: C-Anfängerkurs
Brett: Programmierung

Zitat:
OMad_Dog:
Zitat:
gni:
Zitat:
Palgucker:
Wohlgemerkt, die anderen Aufrufe von
struct Library *IntBase; bis ...
if (IntBase != NULL) CloseLibrary(IntBase);
wurden nicht geändert.

"IntBase" ist dem Compiler völlig egal.
Da gab's aber auch so Schlaumeier, die behauptet haben, der Zeiger müsse zwingend *IntuitionBase heißen, weil in proto/intuition.h ein solcher als globaler Zeiger deklariert ist...
Das widerspricht nicht meiner Aussage. Wieviel weisst Du über die AmigaOS Programmierung und wieviel von C? Der Typ der Variable "IntuitionBase" kann unter bestimmten Bedingungen varieren. Hauptsache es ist ein Zeiger und "passt" zu "struct Libary *". APTR ist so ein Typ. Der _Name_ der Basevariable ist in C _nicht_ egal. Der muß zwingend richtig sein oder es passiert was anderes als Du denkst. Das sich ein Programm trotz falscher Librarybasisname richtig verhält, liegt am automatischen Öffnen von verwendeten Bibliotheken (geht meist nur für die Standardbibliotheken).
 
gni   Nutzer

05.04.2004, 17:25 Uhr

[ - Direktlink - ]
Thema: C-Anfängerkurs
Brett: Programmierung

Zitat:
Mad_Dog:
Zitat:
gni:
Es steht nirgends, das das NDK ohne Fehler ist ;) Die Type-Probleme entstehen erst, wenn man die proto/ Header verwendet. Ursprünglich waren die NDK Beispiele nur für SAS/C und verwendeten clib+pragmas ohne "extern base" (wurde da nicht benötigt).

Wobei in die proto-Header laut Kommentar ursprünglich für Lattice C gedacht waren.
Stimmt, Lattice/SAS habe diese Header erfunden. AFAIK, um die Benutzung von clib+pragmas zu vereinfachen. Eventuell haben sie auch daran gedacht, Unterschiede zwischen Compilern zu verstecken. Fakt bleibt, mit den proto/ Header ist es vollkommen irrelevant wie die spezielen Header eines Compilers heissen. Alle Arbeit wird im proto/ Header gemacht.
 
gni   Nutzer

05.04.2004, 13:02 Uhr

[ - Direktlink - ]
Thema: C-Anfängerkurs
Brett: Programmierung

Zitat:
Palgucker:
Wohlgemerkt, die anderen Aufrufe von
struct Library *IntBase; bis ...
if (IntBase != NULL) CloseLibrary(IntBase);
wurden nicht geändert.

"IntBase" ist dem Compiler völlig egal.
 
gni   Nutzer

05.04.2004, 12:24 Uhr

[ - Direktlink - ]
Thema: C-Anfängerkurs
Brett: Programmierung

Zitat:
Mad_Dog:
Trotzdem kommt mir das ganze Rumgecaste noch reichlich sinnlos vor.

Ganz ohne Casts gehts nicht, wenn man die "richtgen" Typen verwenden will und auf globale Librarybasen steht. Bei lokalen Librarbasen als Funktionsargument oder in Strukturen, ist der Typ belanglos. Es sollte natürlich ein zu "struct Library *" kompatibler Type sein, zb. APTR. Wenn man C++ nutzt muß man dann aber auch casten bei OpenLibrary.
Zitat:
Dann muß ich einen Typecast machen, bevor ich den Zeiger zuweise, weil OpenLibrary einen Zeiger auf eine Struktur vom Typ Library zurückgibt:
code:
// Intuition Library öffnen
  IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",36L);


Der muß sein.
Zitat:
Beim Schließen muß ich nochmal Casten, da CloseLibrary als Eingabeparameter ebenfalls einen Zeiger auf eine Struktur vom Typ Library erwartet:
code:
// Librarie schließen
  if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase);


Der _muß_ nicht sein. Hier sollte man folgendes benutzen:
code:
&IntuitionBase->LibNode

Dann stimmt plötzlich der Type ohne Cast... Ups.
Zitat:
Ich halte also einen Zeiger auf IntuitionBase, obwohl ich eigentlich einen Zeiger auf Library brauche. Ziemlich strange.
Überhaupt nicht. Falls es Dir noch nicht aufgefallen ist, das ganze ist objektorientiert. Intuition hat eine "erweiterte" Librarybasis.
Zitat:
Und daß der Zeiger tatsächlich IntuitionBase heißen muß, liegt an der Definition des globalen Zeigers IntuitionBase in <proto/intuition.h> :
code:
extern struct IntuitionBase * IntuitionBase;


Da könnte auch APTR bzw. "struct Library *" stehen. Aber in dem Fall kommst Du nicht mehr _ohne_ Cast an die speziellen Felder von IntuitionBase wenn das mal benötigt werden sollte.
Zitat:
Für meinen Geschmack ein Bischen viel Kuddelmuddel. Mir scheint, der gcc will auf Biegen und Brechen Lattice C kompatibel bleiben.
Das hat damit _nichts_ zu tun. Mir scheint eher, das zuwenig über den Sinn und Zweck von Casts nachgedacht wird. Viel zu oft werden Casts ohne Nachzudenken benutzt, um Warnungen loszuwerden.
Zitat:
Ich persönlich fand meinen ursprünglichen Code irgendwie schlüssiger...
Dann verwende keine proto/ Header und gut.
 
gni   Nutzer

05.04.2004, 11:54 Uhr

[ - Direktlink - ]
Thema: C-Anfängerkurs
Brett: Programmierung

Zitat:
Mad_Dog:
Seltsamerweise ist das in einigen Beispielen der NDKs auch mit struct Library *IntuitionBase; gelöst. Jedenfalls kann man sich so die lästigen Typecasts sparen.

Es steht nirgends, das das NDK ohne Fehler ist ;) Die Type-Probleme entstehen erst, wenn man die proto/ Header verwendet. Ursprünglich waren die NDK Beispiele nur für SAS/C und verwendeten clib+pragmas ohne "extern base" (wurde da nicht benötigt).
 
gni   Nutzer

05.04.2004, 11:48 Uhr

[ - Direktlink - ]
Thema: C-Anfängerkurs
Brett: Programmierung

Zitat:
Solar:
Zitat:
Original von gni:
Frag mal Solar bezüglich seinen Erfahrungen mit Storm und seinen SFStools.

Öhm... ich glaube Du verwechselst mich mit jemandem.
Na sowas, Helios != Solar.
 
gni   Nutzer

02.04.2004, 17:01 Uhr

[ - Direktlink - ]
Thema: C-Anfängerkurs
Brett: Programmierung

Zitat:
Mad_Dog:
code:
#include <clib/intuition_protos.h>
#include <clib/graphics_protos.h>
#include <clib/exec_protos.h>


Die proto/ Header sind IMHO besser, aber clib/ geht natürlich auch. Das vermeidet das Problem der inkompatiblen Librarytypen...
Zitat:
code:
struct Library *IntuitionBase;  // Zeiger auf IntuitionBase-Struktur
struct Library *GfxBase;        // Zeiger auf Library-Struktur


Wie hier. "Richtig" ist "struct IntuionBase *" bzw "struct GfxBase *".
"struct Library *" geht halt nicht, wenn man die proto/ Header die "richtigen" Typen verwenden.
Zitat:
1.) Der gcc mag nur Zeiger auf Library-Structs, die genauso heißen wie der Datentyp des Structs selbst, also z.B. struct Library *IntuitionBase; StormC hingegen schluckt auch sowas wie struct Library *IntBase; . Dabei finde ich es von Stil her schöner, wenn der Zeiger nicht unbedingt den gleichen Bezeichner hat, wie der Typ des Structs.
GCC schluckt auch IntBase. Dann passiert aber was anderes als Du denkst. Wenn Du nicht selber das richtige Symbol belegst dann macht der Compiler das für dich...
Zitat:
2.) Das geschilderte Problem mit dem Syntax Error kommt, daher, daß es der gcc einem übel nimmt, wenn man bei einem Typecast den Datentyp nicht in Klammern setzt. StormC ist es egal. Deshalb hat mein Makro random() auch nicht funktioniert.
Storm Fehler. Frag mal Solar bezüglich seinen Erfahrungen mit Storm und seinen SFStools.
Zitat:
3.) Der gcc gibt Warnings bezüglich der Header-Datei <clib/graphics_protos.h> aus. :dance3: (bin etwas ratlos - flasche Includes?)
GCC wird schon seinen Grund haben, zu meckern.
 
 
Erste << 22 23 24 25 26 -27- 28 29 30 31 32 Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.