ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Programmierung > C++ von GCC 2.95.3 nach GCC 3.3 portieren | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
-1- 2 3 | [ - Beitrag schreiben - ] |
01.05.2007, 21:40 Uhr Reth Posts: 1858 Nutzer |
Hallo zusammen, auf meiner Suche im Web zu diesem Thema bin ich noch nicht so recht fündig geworden. Da ich GoldED AIX zur Entwicklung verwende habe ich beim C++ und dem GCC die Wahl zw. diesen beiden Compilern. Bisher habe ich mit dem 2.95.3 gearbeitet und mein Projekt compilierte mit diesem Compiler fehlerlos. Da 2.95.3 unter AOS4 bei mir aber nicht funktioniert, der 3.3er scheinbar schon, will ich nun meine Sourcen mit dem GCC 3.3 compilieren. Doch ich bekomme nun eine endlose Latte von Fehlermeldungen, die ich beim 2.95.3 nicht hatte! Gibt es irgendwo sachdienliche Hinweise, die einem hier bei der Portierung von C++ vom 2.95.3 auf den 3.3 helfen?! Vielen Dank schon einmal Ciao [ - Antworten - Zitieren - Direktlink - ] |
02.05.2007, 16:45 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: 3.3 scheint viel pingeliger zu sein wenns ums Vorzeichen geht (zuweisungen signed -> unsigned, bzw. andersrum). Welche Fehlermeldungen kriegst du denn? [ - Antworten - Zitieren - Direktlink - ] |
02.05.2007, 17:14 Uhr thomas Posts: 7718 Nutzer |
Ich bin etwas verwundert über die Version 2.95.3. Soweit ich mich erinnere, war beim OS4-SDK immer die Version 3 von GCC dabei und das neueste SDK hat sogar Version 4.0.2. Und ja, die Version 4 ist etwas pingeliger als die Version 3. Aber wenn man erstmal anfängt, die einzelnen Warnings zu beheben, kommt man schnell drauf, daß sich gar nicht so viel geändert hat. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
02.05.2007, 20:28 Uhr Reth Posts: 1858 Nutzer |
Zitat: Z.B.: Auszug aus ner Header Datei (keine .cpp Datei dazu, alles im Header aber nicht als inlines) : C++ code:void setTitle(const string title = "") { displayTitle = title; } Parse error before '=' token Meines Wissens sind Default-Argumente doch legal!? Oder hier: C++ code:string getTitle() const { return displayTitle; } Parse error before ')' token Wobei eine Zeile obendrüber folgendes steht (ohne Error): C++ code:BOOL isExclusive() const {return exclusive; } ? Da werd einer schlau draus! Sicher gibt es auch ne Menge Folgefehler, aber das sind die ersten beiden! @thomas: Ich verwende nicht die Version des AOS4-SDK, sondern die von GoldED! Da ist die 2.95.3 (oder .4?) dabei und die 3.3. Ich will zunächst mal 68k-Sourcen erzeugen, die 3.1-kompatibel sind, um eine größtmögliche "Userbasis" zu haben! Ciao [ - Antworten - Zitieren - Direktlink - ] |
02.05.2007, 22:20 Uhr thomas Posts: 7718 Nutzer |
Zitat: Das sieht für mich so aus, als wenn da schlicht die Header-Datei fehlt, in der string definiert ist. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
03.05.2007, 12:17 Uhr gni Posts: 1106 Nutzer |
Zitat:Die Frage bezieht sich nicht auf ppc-amigaos sondern auf m68k-amigaos. [ - Antworten - Zitieren - Direktlink - ] |
03.05.2007, 12:19 Uhr gni Posts: 1106 Nutzer |
Zitat:Ich würde eher auf den Namespace tippen... [ - Antworten - Zitieren - Direktlink - ] |
03.05.2007, 14:47 Uhr mausle Posts: 92 Nutzer |
Zitat: Das würde ich auch sagen. Probiers doch mal mit #include <string> ... ...std::string... ciao [ - Antworten - Zitieren - Direktlink - ] |
03.05.2007, 21:24 Uhr Reth Posts: 1858 Nutzer |
@mausle: Danke! Werd ich tun! Mit Namespaces war/bin ich noch nicht so firm, da das bisher beim 2.95.3 wohl kein Problem war! hatte folgendes: C++ code:#include <string> ... void setTitle(const string title = "") { displayTitle = title; } Gab keine Probleme beim comilieren! Ciao [ - Antworten - Zitieren - Direktlink - ] |
04.05.2007, 08:37 Uhr gni Posts: 1106 Nutzer |
Zitat:Dan solltest Du dich damit vertraut machen. GCC2 hat einige Dinge laxer gehandhabt als die Nachfolgeversionen. Zitat:Wenn der obige Code mit GCC3 Probleme macht, dann liegt es definitiv am fehlenden Namespace. Entweder Du verpaßt jedem nacktem string den Prefix "std::" oder Du arbeitest mit "using namspace std;". Die Prefixvariante funktioniert im übrigen auch mit GCC2.95.x.C++ code:Gab keine Probleme beim comilieren!#include <string> ... void setTitle(const string title = "") { displayTitle = title; } [ - Antworten - Zitieren - Direktlink - ] |
04.05.2007, 22:14 Uhr Reth Posts: 1858 Nutzer |
Jep! Vielen Dank! An diesem Problem war der Namespace schuld! Werde nochmal meinen C++ Primer dazu wälzen, aber gibt es irgendwo eine Übersicht über den momentanen C++ Standard, so dass man klar nachlesen kann, was man wie tun sollte? Meine Suche nach dem C++-Standard im Web gab diesbezüglich noch kein positives Ergebnis! Ein anderes Problem habe ich aber noch! Der GCC 3.3 findet die slist nicht, der 2.95.3 allerdings schon! Bin immer noch bei den GCCs von GoldED AIX! Nun ist es so, dass die includes dazu beim 2.95.3 im Unterverzeichnis g++-3. Dieses gibt es auch beim 3.3er, dort ist aber auch noch das Unterverzeichnis c++, welches die anderen STL-Typen enthält (zumindest die, welche ich nehme), dafür keine slist! Wenn ich nun das g++-3 Verzeichnis beim GCC 3.3 bei den Compiler Options mit als Include angebe, dann bekomme ich massig deprecated Meldungden und Fehler angezeigt! Weiss jemand, wie hier zu verfahren ist, damit die richtigen Includes genommen werden? Oder sind im neueren C++ Standard nicht mehr alle Container der STL (von GDI glaub?) enthalten? Ciao René [ Dieser Beitrag wurde von Reth am 04.05.2007 um 23:09 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
05.05.2007, 20:13 Uhr gni Posts: 1106 Nutzer |
Zitat:Vermutlich deswegen: The slist class, and the slist header, are an SGI extension; they are not part of the C++ standard. Zitat:Im Verzeichnis g++-3 sind die C++ Header für GCC 2.95.x, im Verzeichnis c++ sind die C++ Header von GCC3. Da Du sowohl 2.95.x als auch 3.x installiert hast, sind logischerweise beide Verzeichnisse vorhanden. Zitat:Das macht man auch nicht und kann man auch nicht machen! Jeder C++ Compiler hat seine _eigenen_ Header und auch _nur_ die kann man mit dem jeweiligen Compiler auch nur verwenden! Wo der Compiler seine Standard-Includes findet, weiss der Compiler selbst. [ - Antworten - Zitieren - Direktlink - ] |
05.05.2007, 21:21 Uhr Reth Posts: 1858 Nutzer |
Zitat: Hm, schade. Gibt es einen adäquaten Ersatz in der STL? Zitat: Nun nicht ganz, da beide Compiler bei GoldED einen komplett eigenen Verzeichnisbaum haben. In dem des 2.95.3 liegen u.a. die g++-3 und in dem des 3.3er die g++-3 und c++! Ciao [ - Antworten - Zitieren - Direktlink - ] |
07.05.2007, 08:56 Uhr gni Posts: 1106 Nutzer |
Zitat:Was soll "eigener Verzeichnisbaum" bedeuten? Die C++ Includes liegen normalerweise in gg:include, dh. beide Compiler benutzen gg:includes für die Includesuche. Aber auch wenn die C++ Includeverzeichnisse in dem Verzeichnis sind, so sucht doch jeder Compiler nur in seinem eigenen C++ Verzeichnis. Zitat:Bitte etwas ausführlicher. [ - Antworten - Zitieren - Direktlink - ] |
07.05.2007, 22:57 Uhr Reth Posts: 1858 Nutzer |
Hi nochmal,Zitat: Also: GoldED kommt u.a. mit 2 GCC-Installationen, die sich umschalten lassen. Dazu werden die entsprechenden Assigns angepasst und in die entsprechenden Verzeichnisse gewechselt (Path und was weiss ich noch alles). Die Verzeichnisstruktur sieht wie folgt aus: 2.95.3 (dir) code:Assigns:sbin (dir) m68k-amigaos (dir) var (dir) usr (dir) tmp (dir) sys (dir) share (dir) ps (dir) os-include (dir) man (dir) libexec (dir) lib (dir) info (dir) include (dir) html (dir) guide (dir) etc (dir) dvi (dir) bin (dir) AUTHORS COPYING COPYING.LIB INSTALL MIRRORS NEWS README VERSION code:bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin C Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin DEVS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/devs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/devs etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/etc gg Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/info L Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/l Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/l LIBS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/libs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/libs man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/man S Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/s Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/s usr Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/var 3.3 (dir) code:Assigns:sbin (dir) m68k-amigaos (dir) var (dir) usr (dir) tmp (dir) share (dir) ps (dir) os-include (dir) man (dir) libexec (dir) lib (dir) info (dir) include (dir) html (dir) guide (dir) etc (dir) dvi (dir) sys (dir) bin (dir) AUTHORS COPYING COPYING.LIB INSTALL MIRRORS NEWS NOTES-3.3 README VERSION code:bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin C Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin DEVS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/devs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/devs etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/etc gg Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/info L Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/l Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/l LIBS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/libs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/libs man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/man S Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/s Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/s usr Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/var Je nachdem welchen Compiler Du in GoldED auswählst, wird der entsprechende Verzeichnisbaum aktiviert (s. Assign-Auszüge) und nur dieser verwendet! Ich frage mich allerdings, wieso im 3.3 im Vgl. zum 2.95.3 (meiner Meingun nach) sinnvolle Erweiterungen wie slist gecancelt wurden und sich anscheinend wohl "nur" auf den Standard konzentriert wurde. Kann ich denn die slist mit den vorhandenen Includes innerhalb des 3.3 dennoch nutzen? Oder wie ist denn die Standard-Alternative zur slist? Ciao [ - Antworten - Zitieren - Direktlink - ] |
08.05.2007, 09:40 Uhr gni Posts: 1106 Nutzer |
Zitat:Bei den Listings der Verzeichnisse ist nirgends g++-3 zu finden. Bist Du sicher, das das wirklich auch bei 3.3 vorhanden ist? Zitat:Wenn Dich das wirklich interessiert, dann mußt Du auf der GCC Entwickler-ML nachfragen ;-) Zitat:Das weis ich nicht, vermutlich aber eher nicht. Nimm "list" und gut. [ - Antworten - Zitieren - Direktlink - ] |
08.05.2007, 10:28 Uhr Reth Posts: 1858 Nutzer |
Zitat: Das liegt daran, dass diese Verzeichnisse in den jeweiligen include-Verzeichnissen liegen (wenn gewünscht kann ich davon auch ein Listing machen). Zitat:Zitat:Das weis ich nicht, vermutlich aber eher nicht. Nimm "list" und gut. Dann muss ich mich nochmal mit den STL-Komponenten befassen, welche Sortiertechniken/-möglichkeiten mir dort gegeben sind, da hier die Sortierung eine wichtige Rolle spielt. In Java kann man dass ja z.B. gut mit den Comparatoren bzw. Comparable machen. Hab kurz gekuckt! Und: Oh weh! Mir schwant Übles! Muss den <-Operator überladen, damit ich sort() anwenden kann! Ciao [ Dieser Beitrag wurde von Reth am 08.05.2007 um 10:43 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
08.05.2007, 12:28 Uhr gni Posts: 1106 Nutzer |
Zitat:Wenn im Include-Verzeichnis des 3.3 Baum wirklich ein g++-3 Verzeichnis zu finden ist, dann gehört das definitiv nicht dahin -> Löschen. [ Dieser Beitrag wurde von gni am 08.05.2007 um 12:29 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
08.05.2007, 13:54 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was ist daran übel? Das ist doch nichts anderes, als das Comparable interface zu implementieren. Wenn Du lieber einen Comparator benutzt, kannst Du das natürlich auch, nur das der in C++/STL natürlich als Funktion implementiert wird. Einfach als letzen Parameter an sort übergeben, das ist wirklich genauso wie bei den Java-Collections. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
08.05.2007, 22:05 Uhr Reth Posts: 1858 Nutzer |
Zitat: Hm, werds erstmal wegsichern oder umbenennen, nicht, dass der Compiler danach nicht mehr mag! So sieht übrigens der jew. Include-Verzeichnisbaum aus: 2.95.3: code:libraries (dir) clib (dir) sys (dir) rpc (dir) protocols (dir) nfs (dir) netinet (dir) net (dir) machine (dir) m68k (dir) arpa (dir) amitcp (dir) g++-3 (dir) proto (dir) inline (dir) a.out.h ansidecl.h ar.h assert.h bfd.h bfdlink.h bitstring.h bstring.h ctype.h db.h dirent.h err.h errno.h fcntl.h FlexLexer.h float.h fnmatch.h fts.h glob.h glue.h gnu.a.out.h grp.h gvarargs.h inetd.h init.h ix.h kvm.h limits.h locale.h malloc.h math-68881.h math.h memory.h mpool.h ndbm.h ndir.h netdb.h netgroup.h nlist.h packets.h param.h paths.h pwd.h ranlib.h regex.h regexp.h resolv.h search.h setjmp.h sgtty.h signal.h stab.def stab.h stdarg.h stddef.h stdio.h stdlib.h string.h strings.h struct.h sysexits.h syslog.h termcap.h termios.h time.h ttyent.h tzfile.h unistd.h user.h utime.h utmp.h values.h varargs.h vis.h wait.h 3.3 code:c++ (dir) libraries (dir) clib (dir) sys (dir) rpc (dir) protocols (dir) nfs (dir) netinet (dir) net (dir) machine (dir) m68k (dir) arpa (dir) amitcp (dir) g++-3 (dir) proto (dir) inline (dir) a.out.h ansidecl.h ar.h assert.h bfd.h bfdlink.h bitstring.h bstring.h ctype.h db.h dirent.h err.h errno.h fcntl.h FlexLexer.h float.h fnmatch.h fts.h glob.h glue.h gnu.a.out.h grp.h gvarargs.h inetd.h init.h ix.h kvm.h limits.h locale.h malloc.h math-68881.h math.h memory.h mpool.h ndbm.h ndir.h netdb.h netgroup.h nlist.h packets.h param.h paths.h pwd.h ranlib.h regex.h regexp.h resolv.h search.h setjmp.h sgtty.h signal.h stab.def stab.h stdarg.h stddef.h stdio.h stdlib.h string.h strings.h struct.h sysexits.h syslog.h termcap.h termios.h time.h ttyent.h tzfile.h unistd.h user.h utime.h utmp.h values.h varargs.h vis.h wait.h Gibts da noch mehr falsch Abgelegtes? Ciao [ - Antworten - Zitieren - Direktlink - ] |
09.05.2007, 08:50 Uhr gni Posts: 1106 Nutzer |
Zitat:Wenn Du mit -v übersetzt, dann kannst Du sehen, in welchen Verzeichnissen Includes gesucht werden. Zitat:Sieht nicht so aus. Du kannst ja mal die Verzeichnisse mit diff vergleichen. [ - Antworten - Zitieren - Direktlink - ] |
09.05.2007, 09:20 Uhr Reth Posts: 1858 Nutzer |
Zitat: Danke für den Tip! Zitat:Zitat:Sieht nicht so aus. Du kannst ja mal die Verzeichnisse mit diff vergleichen. Meinst Du die des 2.95.3 mit denen des 3.3 oder innerhalb einer Compilerversion? Ciao [ - Antworten - Zitieren - Direktlink - ] |
09.05.2007, 12:51 Uhr gni Posts: 1106 Nutzer |
Zitat:Ja, so meine ich das. [ - Antworten - Zitieren - Direktlink - ] |
09.05.2007, 22:13 Uhr Reth Posts: 1858 Nutzer |
Hallo nochmals, nun habe ich ein neues Problem: Nach den ersten Compileversuchen wurde das nicht angemeckert, aber nun bekomme ich bei folgenden Zeilen: C++ code:Den Fehler:// filterHook ist vom Typ struct Hook this->filterHook.h_Entry=reinterpret_cast<HOOKFUNC>(HookEntry); this->filterHook.h_SubEntry=reinterpret_cast<HOOKFUNC>(SMFilterFunc); code:ScreenModeHookC.cc:16: error: invalid conversion from 'long unsigned int (*)(...)' to 'ULONG (*)()' Wieso wird der Fehler erst jetzt gemeldet und nicht schon bei den ersten 3.3er Compilierversuchen? Das einzige, was ich getauscht habe war make, indem ich es in der GCC-GoldED-Installation durch das aktuellste AOS4-Binary getauscht habe!? Ciao [ Dieser Beitrag wurde von Reth am 2007-05-09 um 22:21 Uhr geändert. ] [ Dieser Beitrag wurde von Reth am 2007-05-09 um 22:21 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
10.05.2007, 10:52 Uhr Holger Posts: 8116 Nutzer |
Zitat:Na ja, h_Entry und h_SubEntry sind ja auch vom Typ LONG und nicht HOOKFUNC. Zitat: Ähm, weil Du bisher andere, schwerwiegendere Fehler zu beheben hattest? Wenn Du Parse-Fehler in einem Source code hast, wird sich ein compiler sich nicht um Typkompatiblität kümmern. Ausnahme sind vielleicht einige IDEs mit interaktiver Fehlerüberprüfung. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
10.05.2007, 21:03 Uhr Reth Posts: 1858 Nutzer |
Zitat: Hm, aber auch ein: C++ code:bzw.this->filterHook.h_Entry = (ULONG)HookEntry; this->filterHook.h_SubEntry = (ULONG)SMFilterFunc; C++ code:this->filterHook.h_Entry = reinterpret_cast<ULONG>(HookEntry); this->filterHook.h_SubEntry = reinterpret_cast<ULONG>(SMFilterFunc); Brachte nen Fehler: code:ScreenModeHookC.cc:16: error: invalid conversion from 'ULONG' to 'ULONG (*)()' ScreenModeHookC.cc:17: error: invalid conversion from 'ULONG' to 'ULONG (*)()' Hm, vielleicht muss ich genauer casten. also: C++ code:this->filterHook.h_Entry = reinterpret_cast<ULONG (*)()>(HookEntry); this->filterHook.h_SubEntry = reinterpret_cast<ULONG (*)()>(SMFilterFunc); Und siehe dann, nun klappts! Wieso hat das ganze dann aber zuvor der g++ des 2.95.3 anstandslos compiliert und das Programm wurde auch immer normal ausgeführt!? Ciao [ - Antworten - Zitieren - Direktlink - ] |
10.05.2007, 22:32 Uhr Holger Posts: 8116 Nutzer |
Zitat: Ausführen tut AmigaOS das, weil es sowieso nicht weiß, auf welchen Typ Du die Adressen castest. Ansonsten scheinst Du aber andere includes zu haben als ich, und möglicherweise auch unterschiedliche pro compiler. Das würde es auf ziemlich einfache Weise erklären. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
11.05.2007, 08:53 Uhr gni Posts: 1106 Nutzer |
Zitat:HOOKFUNC ist ein Typedef eines Funktionszeigers. Zitat:Wenn man den richtigen Typ nimmt, kann man das auch erwarten. Der Compiler hat Dir ja gesagt, was er erwartet. Zitat:Weil 2.95.x nicht so genau hingeschaut hat? HOOKFUNC ist prinzipiell richtig. Allerdings gibt es unterschiedliche Defintionen von h_[Sub]Entry, mal mit und mal ohne Parameter. Und noch was: <slist> gibt es sehr wohl auch bei GCC3! [ - Antworten - Zitieren - Direktlink - ] |
11.05.2007, 13:48 Uhr Holger Posts: 8116 Nutzer |
Zitat:Richtig. Aber die Struktureinträge von Hook sind nicht als HOOKFUNC deklariert. (Auch nicht als ULONG, sondern als Funktion, die ULONG zurückliefert, ich weiß). Zitat:Was wiederum die Frage aufwirft, warum sie nicht als HOOKFUNC deklariert wurde, dann würden sie zwangsläufig auch im Typ übereinstimmen. (Wenn schon der Autor der Headerfiles es nicht schafft, zwei sechs Zeilen voneinander stehende Definitionen in Einklang zu bringen...) mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
11.05.2007, 22:39 Uhr gni Posts: 1106 Nutzer |
Zitat:FWIW, kein Fehler mit allen von mir getesten GCC Versionen (2.95.x, 3.3.6, 3.4.6, 4.0.0, 4.1.0) [ - Antworten - Zitieren - Direktlink - ] |
-1- 2 3 | [ - Beitrag schreiben - ] |
amiga-news.de Forum > Programmierung > C++ von GCC 2.95.3 nach GCC 3.3 portieren | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |