DEUTSCHE VERSION |
|
Links | | | Forums | | | Comments | | | Report news |
Chat | | | Polls | | | Newsticker | | | Archive |
amiga-news.de Forum > Programmierung > C++ von GCC 2.95.3 nach GCC 3.3 portieren | [ - Search - New posts - Register - Login - ] |
-1- 2 3 | [ - Post reply - ] |
2007-05-01, 21:40 h Reth Posts: 1858 User |
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 [ - Answer - Quote - Direct link - ] |
2007-05-02, 16:45 h ZeroG Posts: 1487 User |
@Reth: 3.3 scheint viel pingeliger zu sein wenns ums Vorzeichen geht (zuweisungen signed -> unsigned, bzw. andersrum). Welche Fehlermeldungen kriegst du denn? [ - Answer - Quote - Direct link - ] |
2007-05-02, 17:14 h thomas Posts: 7718 User |
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/ [ - Answer - Quote - Direct link - ] |
2007-05-02, 20:28 h Reth Posts: 1858 User |
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 [ - Answer - Quote - Direct link - ] |
2007-05-02, 22:20 h thomas Posts: 7718 User |
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/ [ - Answer - Quote - Direct link - ] |
2007-05-03, 12:17 h gni Posts: 1106 User |
Zitat:Die Frage bezieht sich nicht auf ppc-amigaos sondern auf m68k-amigaos. [ - Answer - Quote - Direct link - ] |
2007-05-03, 12:19 h gni Posts: 1106 User |
Zitat:Ich würde eher auf den Namespace tippen... [ - Answer - Quote - Direct link - ] |
2007-05-03, 14:47 h mausle Posts: 92 User |
Zitat: Das würde ich auch sagen. Probiers doch mal mit #include <string> ... ...std::string... ciao [ - Answer - Quote - Direct link - ] |
2007-05-03, 21:24 h Reth Posts: 1858 User |
@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 [ - Answer - Quote - Direct link - ] |
2007-05-04, 08:37 h gni Posts: 1106 User |
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; } [ - Answer - Quote - Direct link - ] |
2007-05-04, 22:14 h Reth Posts: 1858 User |
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. ] [ - Answer - Quote - Direct link - ] |
2007-05-05, 20:13 h gni Posts: 1106 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-05, 21:21 h Reth Posts: 1858 User |
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 [ - Answer - Quote - Direct link - ] |
2007-05-07, 08:56 h gni Posts: 1106 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-07, 22:57 h Reth Posts: 1858 User |
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 [ - Answer - Quote - Direct link - ] |
2007-05-08, 09:40 h gni Posts: 1106 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-08, 10:28 h Reth Posts: 1858 User |
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. ] [ - Answer - Quote - Direct link - ] |
2007-05-08, 12:28 h gni Posts: 1106 User |
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. ] [ - Answer - Quote - Direct link - ] |
2007-05-08, 13:54 h Holger Posts: 8116 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-08, 22:05 h Reth Posts: 1858 User |
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 [ - Answer - Quote - Direct link - ] |
2007-05-09, 08:50 h gni Posts: 1106 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-09, 09:20 h Reth Posts: 1858 User |
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 [ - Answer - Quote - Direct link - ] |
2007-05-09, 12:51 h gni Posts: 1106 User |
Zitat:Ja, so meine ich das. [ - Answer - Quote - Direct link - ] |
2007-05-09, 22:13 h Reth Posts: 1858 User |
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. ] [ - Answer - Quote - Direct link - ] |
2007-05-10, 10:52 h Holger Posts: 8116 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-10, 21:03 h Reth Posts: 1858 User |
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 [ - Answer - Quote - Direct link - ] |
2007-05-10, 22:32 h Holger Posts: 8116 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-11, 08:53 h gni Posts: 1106 User |
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! [ - Answer - Quote - Direct link - ] |
2007-05-11, 13:48 h Holger Posts: 8116 User |
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. [ - Answer - Quote - Direct link - ] |
2007-05-11, 22:39 h gni Posts: 1106 User |
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) [ - Answer - Quote - Direct link - ] |
-1- 2 3 | [ - Post reply - ] |
amiga-news.de Forum > Programmierung > C++ von GCC 2.95.3 nach GCC 3.3 portieren | [ - Search - New posts - Register - Login - ] |
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |