amiga-news 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: 1808
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: 1485
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: 7661
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: 1808
Nutzer
Zitat:
Original von ZeroG:
@Reth:
3.3 scheint viel pingeliger zu sein wenns ums Vorzeichen geht (zuweisungen signed -> unsigned, bzw. andersrum). Welche Fehlermeldungen kriegst du denn?


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: 7661
Nutzer
Zitat:
Parse error before ')' token

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:
thomas:
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

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:
thomas:
Zitat:
Parse error before ')' token
Das sieht für mich so aus, als wenn da schlicht die Header-Datei fehlt, in der string definiert ist.
Ich würde eher auf den Namespace tippen...

[ - Antworten - Zitieren - Direktlink - ]

03.05.2007, 14:47 Uhr

mausle
Posts: 92
Nutzer
Zitat:
Original von gni:
Zitat:
thomas:
Zitat:
Parse error before ')' token
Das sieht für mich so aus, als wenn da schlicht die Header-Datei fehlt, in der string definiert ist.
Ich würde eher auf den Namespace tippen...

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: 1808
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:
Reth:
Mit Namespaces war/bin ich noch nicht so firm, da das bisher beim 2.95.3 wohl kein Problem war!

Dan solltest Du dich damit vertraut machen. GCC2 hat einige Dinge laxer gehandhabt als die Nachfolgeversionen.
Zitat:
C++ code:
#include <string>
...
void setTitle(const string title = "") { displayTitle = title; }

Gab keine Probleme beim comilieren!
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.

[ - Antworten - Zitieren - Direktlink - ]

04.05.2007, 22:14 Uhr

Reth
Posts: 1808
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:
Reth:
Der GCC 3.3 findet die slist nicht, der 2.95.3 allerdings schon!

Vermutlich deswegen: The slist class, and the slist header, are an SGI extension; they are not part of the C++ standard.
Zitat:
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!
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:
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!
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: 1808
Nutzer
Zitat:
Original von gni:
Vermutlich deswegen: The slist class, and the slist header, are an SGI extension; they are not part of the C++ standard.


Hm, schade. Gibt es einen adäquaten Ersatz in der STL?

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.

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:
Reth:
Zitat:
Da Du sowohl 2.95.x als auch 3.x installiert hast, sind logischerweise beide Verzeichnisse vorhanden.
Nun nicht ganz, da beide Compiler bei GoldED einen komplett eigenen Verzeichnisbaum haben.
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:
In dem des 2.95.3 liegen u.a. die g++-3 und in dem des 3.3er die g++-3 und c++!
Bitte etwas ausführlicher.

[ - Antworten - Zitieren - Direktlink - ]

07.05.2007, 22:57 Uhr

Reth
Posts: 1808
Nutzer
Hi nochmal,

Zitat:
Original von gni:
Zitat:
Reth:
Nun nicht ganz, da beide Compiler bei GoldED einen komplett eigenen Verzeichnisbaum haben.

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:
In dem des 2.95.3 liegen u.a. die g++-3 und in dem des 3.3er die g++-3 und c++!
Bitte etwas ausführlicher.

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:
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

Assigns:
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:
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

Assigns:
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:
Reth:
[Verzeichnis von 2.95.3 und 3.3]

Bei den Listings der Verzeichnisse ist nirgends g++-3 zu finden. Bist Du sicher, das das wirklich auch bei 3.3 vorhanden ist?
Zitat:
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.
Wenn Dich das wirklich interessiert, dann mußt Du auf der GCC Entwickler-ML nachfragen ;-)
Zitat:
Kann ich denn die slist mit den vorhandenen Includes innerhalb des 3.3 dennoch nutzen?
Das weis ich nicht, vermutlich aber eher nicht. Nimm "list" und gut.

[ - Antworten - Zitieren - Direktlink - ]

08.05.2007, 10:28 Uhr

Reth
Posts: 1808
Nutzer
Zitat:
Original von gni:
Bei den Listings der Verzeichnisse ist nirgends g++-3 zu finden. Bist Du sicher, das das wirklich auch bei 3.3 vorhanden ist?


Das liegt daran, dass diese Verzeichnisse in den jeweiligen include-Verzeichnissen liegen (wenn gewünscht kann ich davon auch ein Listing machen).

Zitat:
Zitat:
Kann ich denn die slist mit den vorhandenen Includes innerhalb des 3.3 dennoch nutzen?
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:
Reth:
Das liegt daran, dass diese Verzeichnisse in den jeweiligen include-Verzeichnissen liegen

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: 8059
Nutzer
Zitat:
Original von Reth:
Hab kurz gekuckt! Und: Oh weh! Mir schwant Übles!
Muss den <-Operator überladen, damit ich sort() anwenden kann!

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: 1808
Nutzer
Zitat:
Original von gni:
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.


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:
Reth:
Hm, werds erstmal wegsichern oder umbenennen, nicht, dass der Compiler danach nicht mehr mag!

Wenn Du mit -v übersetzt, dann kannst Du sehen, in welchen Verzeichnissen Includes gesucht werden.
Zitat:
So sieht übrigens der jew. Include-Verzeichnisbaum aus: ...
Gibts da noch mehr falsch Abgelegtes?

Sieht nicht so aus. Du kannst ja mal die Verzeichnisse mit diff vergleichen.

[ - Antworten - Zitieren - Direktlink - ]

09.05.2007, 09:20 Uhr

Reth
Posts: 1808
Nutzer
Zitat:
Original von gni:
Wenn Du mit -v übersetzt, dann kannst Du sehen, in welchen Verzeichnissen Includes gesucht werden.


Danke für den Tip!

Zitat:
Zitat:
So sieht übrigens der jew. Include-Verzeichnisbaum aus: ...
Gibts da noch mehr falsch Abgelegtes?

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:
Reth:
Zitat:
Du kannst ja mal die Verzeichnisse mit diff vergleichen.
Meinst Du die des 2.95.3 mit denen des 3.3
Ja, so meine ich das.

[ - Antworten - Zitieren - Direktlink - ]

09.05.2007, 22:13 Uhr

Reth
Posts: 1808
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:
// filterHook ist vom Typ struct Hook

this->filterHook.h_Entry=reinterpret_cast<HOOKFUNC>(HookEntry);
this->filterHook.h_SubEntry=reinterpret_cast<HOOKFUNC>(SMFilterFunc);

Den Fehler:
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: 8059
Nutzer
Zitat:
Original von Reth:
C++ code:
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 (*)()'


Na ja, h_Entry und h_SubEntry sind ja auch vom Typ LONG und nicht HOOKFUNC.
Zitat:
Wieso wird der Fehler erst jetzt gemeldet und nicht schon bei den ersten 3.3er Compilierversuchen?

Ä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: 1808
Nutzer
Zitat:
Original von Holger:
Na ja, h_Entry und h_SubEntry sind ja auch vom Typ LONG und nicht HOOKFUNC.


Hm, aber auch ein:
C++ code:
this->filterHook.h_Entry = (ULONG)HookEntry;
this->filterHook.h_SubEntry = (ULONG)SMFilterFunc;

bzw.
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: 8059
Nutzer
Zitat:
Original von Reth:
Wieso hat das ganze dann aber zuvor der g++ des 2.95.3 anstandslos compiliert und das Programm wurde auch immer normal ausgeführt!?


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:
Reth:
Zitat:
Holger:
Na ja, h_Entry und h_SubEntry sind ja auch vom Typ LONG und nicht HOOKFUNC.


HOOKFUNC ist ein Typedef eines Funktionszeigers.
Zitat:
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!

Wenn man den richtigen Typ nimmt, kann man das auch erwarten. Der Compiler hat Dir ja gesagt, was er erwartet.
Zitat:
Wieso hat das ganze dann aber zuvor der g++ des 2.95.3 anstandslos compiliert und das Programm wurde auch immer normal ausgeführt!?
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: 8059
Nutzer
Zitat:
Original von gni:
HOOKFUNC ist ein Typedef eines Funktionszeigers.

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:
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.
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:
Reth:
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?
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 © 1997-2019 by amiga-news.de - alle Rechte vorbehalten.
.