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 << 35 36 37 38 39 -40- 41 42 43 44 45 >> Letzte Ergebnisse der Suche: 1858 Treffer (30 pro Seite)
Reth   Nutzer

29.05.2007, 12:33 Uhr

[ - Direktlink - ] 		Thema: YAM2.4 auf 2.5 - Welche Konfig-Dateien übenehmen?
Brett: Amiga, AmigaOS 4

Hallo Thomas,

danke für die Antwort!

Zitat:
Original von thomas:

Ich weiß nicht genau, was du meinst. Ich habe einfach nur das Programm ausgetauscht und somit alle Konfig-Dateien übernommen. Hat problemlos geklappt, auch der Fallback auf 2.4.

Nach einem Standalone-Start von 2.5 fand ich im YAM-Verzeichnis nicht so viele .xyz-Dateien wie im 2.4er, dachte daher, dass ich nicht alle diese Dateien (die mit Punkt beginnen) übernehmen muss.

Zitat:
Natürlich macht man bei sowas vorher einen komplettes Backup des YAM-Verzeichnis.

Hab bei mir beide Installationen getrennt, muss daher "nur" die Mailordner sichern.

Zitat:
Viel schwieriger war das Zusammensuchen der notwendigen MUI-Klassen. Auf der YAM-Homepage werden nicht alle genannt und YAM meckert beim Start immer nur eine an, anstatt alle aufzulisten, die es nicht öffnen kann. Deshalb hangelt man sich immer von einem Fehler zum nächsten.

Hi, so hab ich die Klassen auch zusammenbekommen.
Würd mich mal interessieren, ob bzw. wie ich das TextEditor-Teil mit IBrowse verwenden kann. Hab das Gefühl, dass das Eingabefeld, welches ich hier gerade mit IBrowse für die Antwort nehme kein TextEditor.mcc ist.
Aber das ist ein anderes Thema.

Ciao
 
Reth   Nutzer

29.05.2007, 10:55 Uhr

[ - Direktlink - ] 		Thema: YAM2.4 auf 2.5 - Welche Konfig-Dateien übenehmen?
Brett: Amiga, AmigaOS 4

Hallo allerseits,

habe mir mal für AOS4 YAM2.5 installiert und wollte nun wissen, welche der Konfig-Dateien (.xyz) ich aus der 2.4er Version übernehmen kann?

Vielen Dank schon mal!

Ciao
 
Reth   Nutzer

24.05.2007, 21:09 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Vielen Dank für eure Tips!

Hier mal ein Compileraufrufbsp. der Aufruf zum Linken (makefile macht wohl weniger Sinn, ist eh eins von GoldED, das dann nicht die Compilerparameter direkt enthält!).
Was bei mir auch noch der Fall ist: Nicht alle Klassen des Projektes sind im makefile drinne und es klappte unter 2.95.3 dennoch immer!
Z.B. fehlt die statische Klasse FrameFactory komplett, liegts evtl. daran?

Das mit dem fehlenden Main hab ich inzwischen lokalisiert! Ist noch ein fehlender Teil der Umstrukturierung, es gibt wirklich noch kein main()!

Eine weitere Frage nochmal: Wie erkenne ich denn nun aus den Linkerfehlern, was ihm fehlt!?

Compilerbsp.:

g++ -noixemul -c -o o/gcc-classic/GadgetMessageReceiverC.o GadgetMessageReceiverC.cc


Linken:

g++ o/gcc-classic/ScreenModeRequestC.o o/gcc-classic/ScreenModeHookC.o o/gcc-classic/ResourceC.o o/gcc-classic/GadgetC.o o/gcc-classic/ImageButtonC.o o/gcc-classic/PointC.o o/gcc-classic/HexManagerC.o o/gcc-classic/PlayerC.o o/gcc-classic/PlayerManagerC.o o/gcc-classic/HexagonC.o o/gcc-classic/FrameC.o o/gcc-classic/EdgeC.o o/gcc-classic/BuildingC.o o/gcc-classic/AnimObjectManagerC.o o/gcc-classic/AnimObjectC.o o/gcc-classic/AnimationC.o o/gcc-classic/MenuSeperatorC.o o/gcc-classic/MenusC.o o/gcc-classic/MenuC.o o/gcc-classic/MenuItemC.o o/gcc-classic/MenuEntryC.o o/gcc-classic/ScreenC.o o/gcc-classic/RastPortC.o o/gcc-classic/WindowC.o o/gcc-classic/WizardGroundsC.o o/gcc-classic/ActivityC.o o/gcc-classic/QuitActivityC.o o/gcc-classic/IntuiTickActivityC.o o/gcc-classic/ClickHandlerC.o o/gcc-classic/TowerGadgetActivityC.o o/gcc-classic/ApplicationC.o o/gcc-classic/GUIApplicationC.o o/gcc-classic/MessageC.o o/gcc-classic/IntuiMessageC.o o/gcc-classic/IntuiMessageReceiverC.o o/gcc-classic/MenuMessageReceiverC.o o/gcc-classic/GadgetMessageReceiverC.o -noixemul -o bin/gcc-classic/WizardWars

Ciao
 
Reth   Nutzer

24.05.2007, 09:35 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

@Solar:

Danke für die Tips!

Werde versuchen heute Abend mal mein makefile zu posten.

Gibt es denn irgendwo aussagekräftige Beschreibungen zu diesen Linkerfehlern?

Ciao
 
Reth   Nutzer

24.05.2007, 00:09 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

So nun kam das Unvermeidliche:

Nachdem alles angepasst wurde, so dass der GCC 3.3 durchkompiliert, kommen nun die Linkerfehler (mit denen ich noch nie was anfangen konnte! Gibts dazu irgendwo ne hilfreiche Doku oder so?):

code:
/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libnix/ncrt0.o(.text+0x60): undefined reference to 'main'
o/gcc-classic/AnimObjectManagerC.o(.text+0x16): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE'
o/gcc-classic/AnimObjectManagerC.o(.text+0x28): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE'
o/gcc-classic/AnimObjectManagerC.o(.text+0x118): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE'
o/gcc-classic/AnimObjectManagerC.o(.text+0x12c): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE'
o/gcc-classic/AnimObjectManagerC.o(.text+0x13e): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE'
o/gcc-classic/AnimObjectManagerC.o(.text+0x22e): more undefined references to '_ZN18AnimObjectManagerC10allObjectsE' follow
o/gcc-classic/WizardGroundsC.o(.text+0xe62): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap'
o/gcc-classic/WizardGroundsC.o(.text+0xe94): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap'
o/gcc-classic/WizardGroundsC.o(.text+0xec6): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap'
o/gcc-classic/WizardGroundsC.o(.text+0xef8): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap'
o/gcc-classic/WizardGroundsC.o(.text+0xf2a): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap'
o/gcc-classic/WizardGroundsC.o(.text+0xf5a): more undefined references to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap' follow
o/gcc-classic/WizardGroundsC.o(.text+0x1256): undefined reference to '_ZN13FrameFactoryC9getFramesEi'
o/gcc-classic/WizardGroundsC.o(.text+0x1282): undefined reference to '_ZN13FrameFactoryC9getFramesEi'
o/gcc-classic/WizardGroundsC.o(.text+0x17ec): undefined reference to '_ZN13FrameFactoryC9getFramesEi'
o/gcc-classic/WizardGroundsC.o(.text+0x1844): undefined reference to '_ZN13FrameFactoryC9getFramesEi'
o/gcc-classic/WizardGroundsC.o(.text+0x189e): undefined reference to '_ZN13FrameFactoryC9getFramesEi'
o/gcc-classic/WizardGroundsC.o(.text+0x18f8): more undefined references to '_ZN13FrameFactoryC9getFramesEi' follow
/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libstdc++.a(basic_file.o)(.text+0x286): undefined reference to 'getc'
/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libstdc++.a(basic_file.o)(.text+0x242): undefined reference to 'fdopen'
collect2: ld returned 1 exit status

AnimObjectManger und FrameFactory sind statische Klassen von mir, die anderen Fehler sind wohl auf irgendwelche Includes zurückzuführen.

allObjects sind im AnimObjectManger als private deklariert:
C++ code:
static std::map<const int, std::vector<AnimObjectC *> > allObjects;
createAddFrame sieht im FrameManger wie folgt aus:
C++ code:
static void createAddFrame(const int type, int width, int height, PLANEPTR data, PLANEPTR mask=NULL, const struct BitMap * const friendBitMap=NULL);

Bei Bedarf kann ich auch noch mehr Code posten (z.B. verwendende Stellen, die Implementierungen an sich und was noch gewünscht ist)!

Kann mir hier bitte jmd. weiterhelfen, da ich aus den Fehlermeldungen absolut nicht schlau werde!

Vielen Dank schon einmal!

Ciao
 
Reth   Nutzer

23.05.2007, 22:39 Uhr

[ - Direktlink - ] 		Thema: MorphOS PowerUp startet nicht auf A4k (schwarzer Bildschirm)
Brett: MorphOS

@aPEX:

Hi,

konnte Dir mein damaliger Thread hier auch nicht helfen?

http://www.pegasosforum.de/viewtopic.php?t=2557&postdays=0&postorder=asc&start=0

Die auf Morphzone hab ich leider nicht rausgesucht!
Hab auch die MOS-Installation leider nicht mehr.

Ciao
 
Reth   Nutzer

17.05.2007, 21:35 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Ok, der Namespace für slist ist: __gnu_cxx

Hab im Include geschaut und den ersten einfach probiert!
 
Reth   Nutzer

16.05.2007, 22:10 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Original von gni:
Versuchs mal mit <slist.h> oder dann mit <ext/slist>.

Also <slist.h> liefert ne deprecated Warnung, <ext/slist> tut, also fast, denn nun bekomm ich die Meldung:

error: 'slist' is used as a type, but is not defined as a type

wenn ich Variablen als slist-Typen deklariere wie z.B.:
C++ code:
slist<struct TagItem> tagItems;

Wie bekomm ich denn den Namespace raus, der hier verwendet werden muss?
std ists ja nicht, ist es ext?

Ciao
 
Reth   Nutzer

16.05.2007, 12:53 Uhr

[ - Direktlink - ] 		Thema: Was ist ein AmigaOne im Detail?
Brett: Amiga, AmigaOS 4

Mal meine Antwort zum Thread-Thema:

Etwas, das niemand hat! :D
 
Reth   Nutzer

16.05.2007, 09:48 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Hallo gni!

Zitat:
Original von gni:
Versuchs mal mit <slist.h> oder dann mit <ext/slist>. Wenn Du Deinen Code mit beiden Compilerversionen übersetzen willst, kommst Du vermutlich um Fallunterscheidungen mittels "__GNUG__ > 2" wohl nicht rum.
Danke! Wollte aber eh auf dem 3.3er bleiben, wenn ichs mal migriert habe!
Liegt der andere Include-Ort von slist daran, dass es nicht in den Standard übernommen wurde?

Zitat:
Die Frage hätte Dir -H beantwortet. Kurz gesagt, das ist vermutlich ein Seiteneffekt, da <string> zum Einbinden von <cstring> führt. Ob das immer so sein muß, weis ich nicht. Wenn Du nur die die Prototypen für die C-Stringfunktionen benötigst, dann solltest Du wie Holger treffend anmerkte <cstring> einbinden.

Brauche in dieser Klasse Funktionen aus beiden Includes, werde daher wohl auch beide einbinden, also <string> und <cstring>, um sicher zu gehen, dass es überall klappt.

Ciao
 
Reth   Nutzer

15.05.2007, 21:13 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

@gni:
Zitat:
Original von gni:
Und noch was: <slist> gibt es sehr wohl auch bei GCC3!
Bei:
C++ code:
#include <slist>
Bekomme ich aber gesagt:
code:
slist: No such file or directory



@Holger:
Zitat:
Original von Holger:
Bzw., wie es für C++ empfohlen wird, #include <cstring>

Hm bei mir hat hier wohl ein:
C++ code:
#include <string>
gelangt!?

Ciao
 
Reth   Nutzer

14.05.2007, 23:10 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Also hab mal meine Suche auf hooks.h eingegrenzt und bei mir sind die Sachen in der GoldED-Installation überall (inkl. NDK3.9 und SDK4.0, mit Ausnahme des MOS-SDK (welches ich nicht nehme) wie folgt definiert:
C++ code:
struct Hook
{
    struct MinNode h_MinNode;
    ULONG    (*h_Entry)(); /* assembler entry point */
    ULONG    (*h_SubEntry)(); /* often HLL entry point */
    APTR    h_Data; /* owner specific  */
};

/* Useful definition for casting function pointers:
 * hook.h_SubEntry = (HOOKFUNC)AFunction
 */
typedef unsigned long (*HOOKFUNC)();

Der einzige Unterschied bei MOS ist, dass VOID angegeben ist, statt leerer Funktionsparameter!

Die Option -H (Danke gni!) zeigt mir, dass die includes aus .../gg/... genommen werden (die Anzahl der führenden Punkte variiert).
Wenn meine Assigns zu diesem Zeitpunkt nicht lügen, zeigt gg: zu dem Verzeichnis der GCC3.3-Installation mitsamt der Header für das OS3.x.

Ich hätte aber noch 2 weitere Fragen:

Unter 2.95.3 konnte ich mühelos die strlen-Funktion aus C auf ein char* anwenden (ohne was zu includieren). Der 3.3 kennt das nicht.
Muss ich hier irgend nen Standard-C-Header inkludieren, oder kann ich die Funktion gar nicht mehr verwenden und muss das Ganze über C++-Strings handhaben?

Das nächste wäre die Behandlung von Default-Argumenten in Methoden:
In meinen Büchern und im Web hab ich nix gefunden (oder aber ich habs immer übersehen?), das besagt, dass die Default-Argumente nur bei der Deklaration angegeben werden dürfen, nicht aber bei der Definition (hoffe, ich bring hier nicht wieder was durcheinander, will sagen, in den Header-Files der C++-Klassen kann ich Default-Argumente angeben, in den implementierenden Files bekomm ich vom 3.3er auf die Finger, wenn ichs dort genauso mache! Find ich an sich schade, da sich so die Methodensignaturen unterscheiden - für das Auge des Betrachters!)!?
Woran liegt das denn - will sagen, an welcher Klausel des Standards?

Ciao
 
Reth   Nutzer

12.05.2007, 15:41 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Hallo nochmals und vielen Dank für eure Beteiligung!

Zitat:
Original von Holger:
Zitat:
Original von gni:
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)
Was wiederum zu dem Schluss führt, dass es sich um andere includes handelt. Da die Wahrscheinlichkeit, dass die Definition von HOOKFUNC, die nur sechs Zeilen von der Definition von Hook entfernt ist, von selbiger abweicht, sehr gering ist, würde ich mal darauf tippen, dass bei Reth HOOKFUNC irgendwo anders (um)definiert wird. Das müsste dann zwar ein ziemlich verkorkstes setup sein, aber möglich wäre es.

Es gibt ja Versionen von hooks.h, in denen gar kein HOOKFUNC definiert wird. Wenn es dann anderweitig definiert wird, würde ein compiler nicht meckern. Erst bei der inkompatiblen Zuweisen von HOOKFUNC nach h_[Sub]Entry.

Ich weiß schon, warum ich C so liebe :D

mfg

Werde vllt. mal Dietmar Eilert fragen, wo ich genau nachsehen kann, welche Includes der Compiler hier anzieht. Oder kann ich mir das via make-Parameter irgendwie ausgeben lassen?
Schaue bei Gelegenheit auch nochmal in alle installierten OS-Includes (3.x und 4), bzw. lass mir mal alles suchen, wo HOOKFUNC drin vorkommt und berichte dann (kann aber ne Weile dauern)!

Ciao
 
Reth   Nutzer

10.05.2007, 21:03 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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
 
Reth   Nutzer

09.05.2007, 22:13 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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. ]
 
Reth   Nutzer

09.05.2007, 09:20 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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
 
Reth   Nutzer

08.05.2007, 22:05 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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
 
Reth   Nutzer

08.05.2007, 10:28 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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. ]
 
Reth   Nutzer

07.05.2007, 22:57 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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
 
Reth   Nutzer

05.05.2007, 21:21 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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
 
Reth   Nutzer

04.05.2007, 22:14 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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. ]
 
Reth   Nutzer

03.05.2007, 21:24 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

@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
 
Reth   Nutzer

02.05.2007, 20:28 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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
 
Reth   Nutzer

01.05.2007, 21:40 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

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
 
Reth   Nutzer

29.04.2007, 21:52 Uhr

[ - Direktlink - ] 		Thema: GoldED AIX und Stack für gcc/g++?
Brett: Amiga, AmigaOS 4

Hallo zusammen,

wie kann ich denn unter GoldED den Stack für den gcc bzw. g++ erhöhen?

Wenn ich in den Compilereinstellungen einen Stack für make eintrage (verwende ja makefiles und das Make-Menü von AIX und GCC), dann bekommt der Compiler unter AOS4 dennoch nur 32kB Stack!?

Dann bekomm ich nen GR (wobei nicht sicher ist, ob der kleine Stack die Ursache ist, aber das will ich ja herausfinden).

Das Ganze passiert nur mit dem 2.95.3 GCC, der 3.3er geht!

Vielen Dank schon mal
Ciao
 
Reth   Nutzer

20.04.2007, 20:52 Uhr

[ - Direktlink - ] 		Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4

So nachdem die Karte aus heiterem Himmel wieder ausgefallen ist (hab weder sie noch den Rechner berührt), hab ich sie nun mal in nen anderen Slot gesteckt und warte auf den nächsten Ausfall!

Ciao
 
Reth   Nutzer

20.04.2007, 17:28 Uhr

[ - Direktlink - ] 		Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4

So hab mal alles gereinigt und PINs gebogen, muss nun abwarten, ob die Karte mal wieder ausfällt!

Ciao
 
Reth   Nutzer

20.04.2007, 12:50 Uhr

[ - Direktlink - ] 		Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4

Zitat:
Original von Jinx:
hat die karte verzinnte oder vergoldete kontakte an der zorro-seite? wenn verzinnt, dann kannst du dir die antwort auf die frage sicher selber geben...

Vergoldete Kontakte, auch mehrfache Reinigung half nix!


@All:

Hab auch schon mal die PINs aufgebogen, half auch nicht (werd ich nochmal machen), weiterhin hab ich schon mal einige Stellen nachgelötet - umsonst.

Tippe entweder auf einen Haarriss oder doch noch ne kalte Lötstelle.

Werde das mit den PINs nochmal probieren wie gesagt und mich dann nochmal melden!

Ciao

[ Dieser Beitrag wurde von Reth am 20.04.2007 um 12:51 Uhr geändert. ]
 
Reth   Nutzer

20.04.2007, 00:47 Uhr

[ - Direktlink - ] 		Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4

Hallo allerseits,

vielleicht kennt jmd. das Problem:

Habe eine Connexion, die eigentlich schön schnell in meinem A400 arbeitet.

Allerdings nicht sehr zuverlässig.

Ich weiss, dass der BNC-Port unzuverlässig ist, den nutze ich aber nicht, sondern den AUI-Port über eine MAU auf RJ45.

Nun ist es so, dass die Karte manchmal aus heiterem Himmel nicht erkannt wird, wenn ich dann allerdings etwas auf den gesteckten Chips oder der Karte selbst herumdrücke geht es meistens.

Allerdings nicht immer!

Kennt jmd. zufällig das Problem und hat eine Lösung dafür?

Vielen Dank schon einmal
Ciao
 
Reth   Nutzer

19.04.2007, 23:02 Uhr

[ - Direktlink - ] 		Thema: S: Cubic IDE
Brett: Kleinanzeigen (keine Auktionen!)

Hallo zusammen,

falls das jmd. zu nem guten Preis zu verkaufen hat, bin ich für Vorschläge offen!

Ciao
 
 
Erste << 35 36 37 38 39 -40- 41 42 43 44 45 >> Letzte Ergebnisse der Suche: 1858 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-2024 by amiga-news.de - alle Rechte vorbehalten.
.