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

amiga-news.de Forum > Programmierung > Probleme mit new Operator bei g++ [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 [ - Beitrag schreiben - ]

17.08.2006, 08:38 Uhr

gni
Posts: 1106
Nutzer
Zitat:
asrael229:
Die CLib2 Umgebung hatte doch tatsaechlich Einfluss auf die C++ Umgebung. Seit ich wieder auf ixemul umgestellt habe, kompilierts ohne Schwierigkeiten.

Der Compiler mag die size_t Definition von clib2 nicht. Da wird "unsigned int" verwendet, der Compiler erwartet aber "unsigned long". Wenn Du das in den Includes "korrigierst", dann funktioniert das Übersetzen.

[ - Antworten - Zitieren - Direktlink - ]

17.08.2006, 08:58 Uhr

asrael229
Posts: 37
Nutzer
Zitat:
Original von gni:
Der Compiler mag die size_t Definition von clib2 nicht. Da wird "unsigned int" verwendet, der Compiler erwartet aber "unsigned long". Wenn Du das in den Includes "korrigierst", dann funktioniert das Übersetzen.


Wo muesste ich das aendern?


Manfred

[ - Antworten - Zitieren - Direktlink - ]

17.08.2006, 10:11 Uhr

Solar
Posts: 3674
Nutzer
grep, size_t, typedef...

[ - Antworten - Zitieren - Direktlink - ]

17.08.2006, 15:04 Uhr

asrael229
Posts: 37
Nutzer
Zitat:
Original von gni:
Der Compiler mag die size_t Definition von clib2 nicht. Da wird "unsigned int" verwendet, der Compiler erwartet aber "unsigned long". Wenn Du das in den Includes "korrigierst", dann funktioniert das Übersetzen.


Ok,nach dem aendern funktioniert zwar die Geschichte mit dem new. Aber es gibt an anderen Stellen Schwierigkeiten.
Muss ich mir mal naeher anschauen. Wuerde sich schon lohnen, wenn man keine ixemul braeuchte. Waere aber auch kein Beinbruch.

Auf welchem System hast Du denn den Cross-Compiler?
Hab mal versucht von adtools die Binutils auf Darwin zu uebersetzen, schlaegt aber leider fehl, sodass ich mir hier keinen Cross-Compiler bauen kann. Haette noch ein PPC-Linux aber was mit i386 hab ich garnix.
Hmm, koennte mir auf QEMU ein Linux installieren. Aber da duerfte das Auf meinem 68040 schneller sein. ;)


Gruesse,
Manfred


[ Dieser Beitrag wurde von asrael229 am 17.08.2006 um 15:05 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.08.2006, 17:28 Uhr

gni
Posts: 1106
Nutzer
Zitat:
asrael229:
Ok,nach dem aendern [von size_t] funktioniert zwar die Geschichte mit dem new. Aber es gibt an anderen Stellen Schwierigkeiten.

Dann mußt Du Dich wohl damit abfinden, das die clib2 nicht mit GG GCC-Ports zusammenspielen will.
Zitat:
Auf welchem System hast Du denn den Cross-Compiler?
FreeBSD
Zitat:
Hab mal versucht von adtools die Binutils auf Darwin zu uebersetzen, schlaegt aber leider fehl, sodass ich mir hier keinen Cross-Compiler bauen kann.
Woran scheitert es?
Zitat:
Haette noch ein PPC-Linux aber was mit i386 hab ich garnix.
Prozessor und OS sind egal, hauptsache UN*X :-)

[ - Antworten - Zitieren - Direktlink - ]

17.08.2006, 21:58 Uhr

woop
Posts: 67
Nutzer
Zitat:
Original von asrael229:
Zitat:
Original von Mad_Dog:
@asrael229:

Hab's mal schnell überflogen...

code:
SWKey *VerseKey::clone() const
{
	return new VerseKey(*this);
}


Das ist aber eine Methode und kein Konstruktor!
Der Rückgabewert ist ein Zeiger auf eine Klasse Namens SWKey, new liefert hier aber einen Zeiger auf eine Instanz der Klasse Versekey.
Folglich müsste es so heißen:


Ja, aber hier muesste ja normalerweise (ohne es ausprobobiert zu haben) dieser Konstruktor ausgerufen werden:
code:
VerseKey::VerseKey(VerseKey const &k) : SWKey(k)
{
   ...
}



Manfred



Nein, eigentlich nicht, der passende Konstruktor müsste
code:
VerseKey::VerseKey(const VerseKey &k) : SWKey(k)
{
   ...
}

heißen. VerseKey const &k bezeichnet eine konstante Referenz, also eine Referenz die immer auf dasselbe Objekt zeigt und da das Referenzen sowieso tun, ist das const hier überflüssig.

code:
SWKey *VerseKey::clone() const

darf dagegen diesen Konstruktor nicht mit *this aufrufen, weil this in dieser Member Funktion konstant ist (wegen dem const am Ende)

woop

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 06:42 Uhr

Solar
Posts: 3674
Nutzer
Zitat:
Original von woop:

VerseKey const &k bezeichnet eine konstante Referenz, also eine Referenz die immer auf dasselbe Objekt zeigt...


Reingefallen!

Bei Typen darf const vor oder nach dem Typnamen stehen, bei Pointern muß const nach dem Pointer kommen.

Die "klassische" Schreibweise "const int..." ist also syntaktisch die "schlechtere", weil man zwar "const" immer nach dem Konstanten setzen kann, aber nicht immer vor dem Konstanten.

const int * -> Pointer auf konstantes int.
int * const -> Konstanter Pointer auf int.
int const * -> Pointer auf konstantes int (!).
int const * const -> Konstanter Pointer auf konstantes int.

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 08:22 Uhr

woop
Posts: 67
Nutzer
Zitat:
Original von Solar:

Bei Typen darf const vor oder nach dem Typnamen stehen, bei Pointern muß const nach dem Pointer kommen.


Oops, da hast du natürlich recht...

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 08:59 Uhr

asrael229
Posts: 37
Nutzer
Ich weiss schon, warum ich C++ nicht mag. :-)


Beste Gruesse,
Manfred

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 09:09 Uhr

Solar
Posts: 3674
Nutzer
C und C++ sind eigentlich ziemlich gute Programmiersprachen, wenn man sich nur abgewöhnt, uralt-Dialekte, -Strukturen und -Compiler zu verwenden. Leider sind solche Unmengen an Code eben in diesem Uralt-Stil geschrieben, das "sauberer" Quellcode immer noch eine Seltenheit ist.

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 09:22 Uhr

asrael229
Posts: 37
Nutzer
Hmm. Gegen C hab ich garnichts. Schon sehr viel damit gemacht. Auch Objective-C finde ich richtig super. Mit C++ komm ich nicht klar.
Wahrscheinlich auch weil ich damit noch wenig gemacht habe...


Manfred

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 10:05 Uhr

asrael229
Posts: 37
Nutzer
Zitat:
Original von gni:
Woran scheitert es?

Mit einem permission denied:
Making all in po
make[3]: Nothing to be done for 'all'.
/bin/sh ../../binutils/ld/ylwrap 'test -f '../../binutils/ld/ldgram.y' || echo '../../binutils/ld/''../../binutils/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d
../../binutils/ld/ylwrap: line 86: /Volumes/Mirandol/_inProgress/adtools/binutils-build/ld/../../binutils/ld/ldgram.y: Permission denied
make[3]: *** [ldgram.c] Error 1


Ich habe ein separates build Verzeichnis benutzt, wird aber auch glaube ich so vorgeschlagen von GNU.

Zitat:
Original von gni:
Prozessor und OS sind egal, hauptsache UN*X :-)

Hmm, ist nicht so ganz egal. PPC wird von allen BSD (NetBSD, OpenBSD und FreeBSD) nicht komplett unterstuetzt und es fehlen einige Features wie z.B. Firewire Unterstuetzung und anderes. Schade.
PPC-Linux dagegen laeuft sehr gut aber auch hier gibt es gegenueber i386 caveats.


Gruesse,
Manfred

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 10:16 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
C und C++ sind eigentlich ziemlich gute Programmiersprachen, wenn man sich nur abgewöhnt, uralt-Dialekte, -Strukturen und -Compiler zu verwenden.

Strukturen in C sind also veraltet? Wußte ich bisher nicht...

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 10:29 Uhr

gni
Posts: 1106
Nutzer
Zitat:
asrael229:
Making all in po
make[3]: Nothing to be done for 'all'.
/bin/sh ../../binutils/ld/ylwrap 'test -f '../../binutils/ld/ldgram.y' || echo '../../binutils/ld/''../../binutils/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d
../../binutils/ld/ylwrap: line 86: /Volumes/Mirandol/_inProgress/adtools/binutils-build/ld/../../binutils/ld/ldgram.y: Permission denied
make[3]: *** [ldgram.c] Error 1

Was nach dem "||" kommt, sieht komisch aus (das einzelne "). Was immer da auch passiert bzw. passieren sollte. Woher genau hast Du die Quellen? Ist das ein CVS Checkout? Was passiert in Zeile 86 von ylwrap?
Zitat:
Ich habe ein separates build Verzeichnis benutzt, wird aber auch glaube ich so vorgeschlagen von GNU.
Ja und das ist auch besser so.
Zitat:
PPC wird von allen BSD (NetBSD, OpenBSD und FreeBSD) nicht komplett unterstuetzt und es fehlen einige Features wie z.B. Firewire Unterstuetzung und anderes. Schade.
Für Cross-Compiler tut das nichts zur Sache. Hauptsache der Compiler funktioniert. Ist natürlich bedauerlich das die HW nicht richtig genutzt werden kann. Ich habe zwar mal mit dem Gedanken an FreeBSD auf mac Mini (PPC) gespielt, es aber nicht gemacht. Und jetzt gibt es kein PPC minis mehr bei Apple zu kaufen :-(

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 10:46 Uhr

asrael229
Posts: 37
Nutzer
Zitat:
Original von gni:
Was nach dem "||" kommt, sieht komisch aus (das einzelne "). Was immer da auch passiert bzw. passieren sollte. Woher genau hast Du die Quellen? Ist das ein CVS Checkout? Was passiert in Zeile 86 von ylwrap?

Ja, das war ein svn checkout vom trunk. Ich hab aber auch die versionen unter release probiert.

Zitat:
Original von gni:
Für Cross-Compiler tut das nichts zur Sache. Hauptsache der Compiler funktioniert. Ist natürlich bedauerlich das die HW nicht richtig genutzt werden kann. Ich habe zwar mal mit dem Gedanken an FreeBSD auf mac Mini (PPC) gespielt, es aber nicht gemacht. Und jetzt gibt es kein PPC minis mehr bei Apple zu kaufen :-(

Ja, sollte fuer den Cross-Compiler wurscht sein. Wobei ich auf meinem Debian PPC Linux ein aehnliches Problem mit den Binutils habe.
In der Zeile 86 steht:
code:
$prog ${1+"$@"} "$input"


Wenn ich aber meine externe FW Festplatte zum Backupen nicht dranhaengen kann ist das weniger schoen. Auch haben alle BSDs unter Mac es noch fertig gebracht einen vernueftigen Bootloader einzusetzen. yaboot koennte doch wahrscheinlich leicht portiert werden.
Ich denke Grundsaetzlich wird die i386 Welt von vielen Sourcen besser unterstuetzt. Auch die Compiler erzeugen IMO besser bzw. schnelleren Code unter i386. Fuer UAE gibts z.B. nen JIT Compiler. Ohne den wird gerade mal ein 68040 auf meinem 1,7 GHz PowerBook emuliert.


Beste Gruesse,
Manfred

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 10:48 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von asrael229:
Zitat:
Original von gni:
Woran scheitert es?

Mit einem permission denied:
Making all in po
make[3]: Nothing to be done for 'all'.
/bin/sh ../../binutils/ld/ylwrap 'test -f '../../binutils/ld/ldgram.y' || echo '../../binutils/ld/''../../binutils/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d
../../binutils/ld/ylwrap: line 86: /Volumes/Mirandol/_inProgress/adtools/binutils-build/ld/../../binutils/ld/ldgram.y: Permission denied
make[3]: *** [ldgram.c] Error 1


Sieht mir so aus, als ob da yacc-Dateien verwendet werden (die .y)...
Hast Du yacc bzw. bison (welches hier verwendet wird) installiert?
Das sind beides Compiler Compiler. Und Flex (ist ein Scanner-Generator) solltest Du nach Möglichkeit auch haben.


--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 10:52 Uhr

asrael229
Posts: 37
Nutzer
Zitat:
Original von Mad_Dog:
Sieht mir so aus, als ob da yacc-Dateien verwendet werden (die .y)...
Hast Du yacc bzw. bison (welches hier verwendet wird) installiert?
Das sind beides Compiler Compiler. Und Flex (ist ein Scanner-Generator) solltest Du nach Möglichkeit auch haben.

Ja, das ist bei den Developer Tools von Apple alles dabei.


Beste Gruesse,
Manfred

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 10:53 Uhr

Solar
Posts: 3674
Nutzer
Zitat:
Original von gni:
Zitat:
Solar:
C und C++ sind eigentlich ziemlich gute Programmiersprachen, wenn man sich nur abgewöhnt, uralt-Dialekte, -Strukturen und -Compiler zu verwenden.

Strukturen in C sind also veraltet? Wußte ich bisher nicht...

Wus?

Ach so...

Ich meinte Codestrukturen, nicht struct irgendwas. :lach:

Ich meine den anscheinend nie aussterbenden Kram wie inkonsistentes Setzen von const, nichtsetzen von const, int statt size_t als Array-Index, lokale Helper-Funktionen extern statt static, alle Variablen am Anfang der Funktion deklarieren, Schleifenzähler außerhalb der Schleife deklarieren, <stdint.h> ignorieren (m.E. der praktischste Header in C99), wildeste Makro-Magie kreuz und quer durch den Code wo's eine inline-Funktion auch getan hätte, pro Quellcodedatei zwei Dutzend Compilerwarnungen fröhlich ignorieren, ...

Man kann jede Programmiersprache verhunzen. Man kann aber in vielen Programmiersprachen auch sehr effizient arbeiten.

Speziell C++ hat da den "Nachteil", beides bis ins Extrem möglich zu machen. Ich hab' schon C++-Code gesehen, den könnte man sich rahmen und an die Wand hängen, so elegant war der. Im Alltag kriege ich allerdings eher Weinkrämpfe, wenn ich mal wieder ein
code:
bool hasNext()

lese...

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 12:44 Uhr

gni
Posts: 1106
Nutzer
Zitat:
asrael229:
das war ein svn checkout vom trunk.

Trunk ist ok. AFAIK ist nur da was aktuelles und funktionierendes für m68k zu finden.
Zitat:
Wobei ich auf meinem Debian PPC Linux ein aehnliches Problem mit den Binutils habe.
In der Zeile 86 steht:
code:
$prog ${1+"$@"} "$input"


Ich würde jetzt mal vermuten, das $prog leer ist und dann versucht das Skript das erste Argument auszuführen. Du könntest ja probeweise ein paar echos davor einbauen, um zu schauen wie die Variablen belegt sind.
Zitat:
Auch haben alle BSDs unter Mac es noch fertig gebracht einen vernueftigen Bootloader einzusetzen. yaboot koennte doch wahrscheinlich leicht portiert werden.
AFAIK kann die OF eines Macs nur von HFS und cd9660 booten.
Zitat:
Ich denke Grundsaetzlich wird die i386 Welt von vielen Sourcen besser unterstuetzt.
Mag sein, das einige Programme eher low-level stuff für x86 haben, aber für reine C/C++ Programme ist die CPU/OS irrelevant.
Zitat:
Auch die Compiler erzeugen IMO besser bzw. schnelleren Code unter i386.
Ich kann weder die Codegüte von x86 noch PPC beurteilen ;)

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 12:53 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
alle Variablen am Anfang der Funktion deklarieren

Das ist Geschmacksache.
Zitat:
Schleifenzähler außerhalb der Schleife deklarieren
Reden wir von C?
Zitat:
<stdint.h> ignorieren (m.E. der praktischste Header in C99)
Genau _C99_. Es reicht halt nicht, wenn der Compiler das unterstützt. Die Header/Bibliotheken müssen das auch unterstützen. Für AmigaOS/m68k ist das nur bei der clib2 der Fall, die aber anscheinend nicht so recht mit den GG GCCs will.
Zitat:
wildeste Makro-Magie kreuz und quer durch den Code wo's eine inline-Funktion auch getan hätte
C?
Zitat:
pro Quellcodedatei zwei Dutzend Compilerwarnungen fröhlich ignorieren
Standardmäßig nehmen C Compiler halt mehr hin. Und oft werden Warnoptionen eines Compilers nicht benutzt, wobei man sich über die Warnungen gelegentlich trefflich streiten kann. Und der nächste Compiler/nächste Version des Compilers meint etwas andeses beanstanden zu müssen.
Zitat:
Im Alltag kriege ich allerdings eher Weinkrämpfe, wenn ich mal wieder ein
code:
bool hasNext()

lese...
Ist das Java? ;)

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 13:11 Uhr

Solar
Posts: 3674
Nutzer
@ gni:

Stand der Programmiersprache C ist nun einmal C99, und das seit sieben Jahren (ach was ;) ). C99 kann Schleifenzähler lokal zur Schleife behandeln, kennt <stdint.h> und inline-Funktionen. Mir ist ziemlich Wurst, welcher Compiler oder welche CLib das auf dem Amiga unterstützt - das ist ein Problem der Platform, nicht der Sprache.

Und wer nicht mindestens -Wall aktiviert, gehört eh nicht an einen C-Compiler, IMNSHO. ;)

Zitat:
Zitat:
Im Alltag kriege ich allerdings eher Weinkrämpfe, wenn ich mal wieder ein
code:
bool hasNext()

lese...
Ist das Java? ;)

Java in C++ verpackt. Schau' Dir mal den Source von AStyle v1.15.3 an, Du kriegst einen Schreikrampf... I-)

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 13:17 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von gni:
Zitat:
Solar:
alle Variablen am Anfang der Funktion deklarieren

Das ist Geschmacksache.
Nicht wirklich.
Zitat:
Zitat:
Schleifenzähler außerhalb der Schleife deklarieren
Reden wir von C?
C99
Zitat:
Zitat:
<stdint.h> ignorieren (m.E. der praktischste Header in C99)
Genau _C99_. Es reicht halt nicht, wenn der Compiler das unterstützt. Die Header/Bibliotheken müssen das auch unterstützen. Für AmigaOS/m68k ist das nur bei der clib2 der Fall, die aber anscheinend nicht so recht mit den GG GCCs will.
Hää?
Natürlich unterstützt ein erst mit C99 definierter Header auch C99. Was das mit den Kompatiblitätsproblemen zu tun hat, die eine nicht zu dem Compiler gehörende Bibliothek hat, die niemand in seinen Compiler patchen muss, will mit nicht in den Kopf.
Außerdem waren die Probleme völlig anderer Natur.
vbcc und gcc unterstützen C99, andere auf dem Amiga verfügbare Compiler werden eh nicht mehr weiterentwickelt, so what?
Zitat:
Zitat:
wildeste Makro-Magie kreuz und quer durch den Code wo's eine inline-Funktion auch getan hätte
C?
was sonst?
Zitat:
Zitat:
Im Alltag kriege ich allerdings eher Weinkrämpfe, wenn ich mal wieder ein
code:
bool hasNext()

lese...
Ist das Java? ;)

Nein, Java hat einen Datentyp boolean, bool gibt's da nicht.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 14:28 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
Stand der Programmiersprache C ist nun einmal C99, und das seit sieben Jahren (ach was ;) ). C99 kann Schleifenzähler lokal zur Schleife behandeln, kennt <stdint.h> und inline-Funktionen.

Das mag ja alles sein, nur hat sich C99 noch nicht als Standard durchgesetzt... Damit ist C99 zwar nett aber "nutzlos".
Zitat:
Mir ist ziemlich Wurst, welcher Compiler oder welche CLib das auf dem Amiga unterstützt - das ist ein Problem der Platform, nicht der Sprache.
Du mußt Compiler und Laufzeit schon trennen. Ein Compiler der C99 kann, muß das nicht als Defaultmode nutzen und die Laufzeit muß schon garnicht C99 ready sein.

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 14:38 Uhr

gni
Posts: 1106
Nutzer
[quote]Holger:
Zitat:
Natürlich unterstützt ein erst mit C99 definierter Header auch C99. Was das mit den Kompatiblitätsproblemen zu tun hat, die eine nicht zu dem Compiler gehörende Bibliothek hat, die niemand in seinen Compiler patchen muss, will mit nicht in den Kopf.
Gehört stdint.h zum Compiler oder zu den Headern der clib? Das ist schon ein Unterschied.
Zitat:
Außerdem waren die Probleme völlig anderer Natur.
Welche clib für GCC unter AmigaOS/68k bietet C99 Unterstützung? AFAIK bisher nur die clib2. Und genau die macht Probleme mit den GG GCCs wie dieser Thread ja gezeigt hat.

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 14:43 Uhr

Solar
Posts: 3674
Nutzer
Zitat:
Original von gni:
Zitat:
Solar:
Stand der Programmiersprache C ist nun einmal C99, und das seit sieben Jahren (ach was ;) ). C99 kann Schleifenzähler lokal zur Schleife behandeln, kennt <stdint.h> und inline-Funktionen.

Das mag ja alles sein, nur hat sich C99 noch nicht als Standard durchgesetzt... Damit ist C99 zwar nett aber "nutzlos".
[/quote]

Ab wann betrachtest Du einen Standard als "sich durchgesetzt"? Die Unterstützung in GCC ist schon ziemlich weit...

Oder hat sich ein Standard in Deinen Augen erst "durchgesetzt", wenn er zur Default-Einstellung wird? Dann hat sich noch nicht einmal C89 (!) "durchgesetzt", weil so gut wie jeder Compiler den Standard mit seinen eigenen Erweiterungen garniert...

Zitat:
Zitat:
Mir ist ziemlich Wurst, welcher Compiler oder welche CLib das auf dem Amiga unterstützt - das ist ein Problem der Platform, nicht der Sprache.
Du mußt Compiler und Laufzeit schon trennen. Ein Compiler der C99 kann, muß das nicht als Defaultmode nutzen und die Laufzeit muß schon garnicht C99 ready sein.

Mir geht's darum, das z.B. lokale Schleifenzähler inzwischen Bestandteil der Sprache C ist. Wenn Compiler und/oder Bibliotheken und/oder Programmierer das nicht unterstützen / berücksichtigen, ist das deren Problem, nicht das der Sprache.

gni, niemand (ich zumindest nicht) will Dir oder der clib2 am Zeug flicken. Aber es ist doch wohl Fakt, das viele Probleme, mit denen ein Entwickler auf AmigaOS sich heute rumschlagen muß, ihre Ursache in der allgemein desolaten Plattform haben, und nicht im Unvermögen einer Programmiersprache oder ähnliches.

[ Dieser Beitrag wurde von Solar am 18.08.2006 um 14:47 Uhr geändert. ]

[ Dieser Beitrag wurde von Solar am 18.08.2006 um 14:48 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 16:41 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von gni:
Gehört stdint.h zum Compiler oder zu den Headern der clib? Das ist schon ein Unterschied.

Überhaupt nicht. Für mich besteht ein Compiler aus dem gesamten Paket, das mich in die Lage versetzt, ein Programm in ein lauffähiges Objekt zu übersetzen. Kann es das nicht, fehlt etwas.
Zitat:
Welche clib für GCC unter AmigaOS/68k bietet C99 Unterstützung? AFAIK bisher nur die clib2. Und genau die macht Probleme mit den GG GCCs wie dieser Thread ja gezeigt hat.
Erstens halte ich es für sehr verdreht, zu behaupten, eine Zusatzbibliothek könne etwas, um im gleichen Atemzug zu behaupten, sie könne es eben nicht, zweitens wüßte ich nicht, was Sprachfeatures wie Schleifeninitialisierer mit einer Linkbibliothek zu tun haben sollten, dritten ist es ja nur Deine Ansicht, dass fehlende Header der compiler-Umgebung eine Linklib-spezifische Angelegenheit sein würden, viertens haben die in diesem Thread erwähnten Probleme der clib2 mit C++ und nicht mit C99 zu tun.

Für mich reicht es, wenn z.B. vbcc folgenden code im C99 Modus korrekt übersetzt.
C code:
#include <stdint.h>
#include <stdio.h>

inline void out(char const * const txt, int8_t const num)
{
  printf("%s\t%d\n", txt, num);
}

int main(void)
{
  for(int8_t i=0; i<10; i++)
    out("hello ", i);
  return 0;
}

Man kann sich natürlich auch noch die nächsten Jahrhunderte selbst kastrieren, weil es irgendwo da draußen einen compiler gibt, der irgendetwas nicht kann. Während die compiler-Entwickler, falls denn dieser compiler noch weiterentwickelt wird, auch weiterhin nicht an der Standard-Unterstützung arbeiten, weil ja keiner diese features benutzt...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 18.08.2006 um 16:42 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 17:05 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:

Für mich reicht es, wenn z.B. vbcc folgenden code im C99 Modus korrekt übersetzt.
C code:
#include <stdint.h>
#include <stdio.h>

inline void out(char const * const txt, int8_t const num)
{
  printf("%s\t%d\n", txt, num);
}

int main(void)
{
  for(int8_t i=0; i<10; i++)
    out("hello ", i);
  return 0;
}

Man kann sich natürlich auch noch die nächsten Jahrhunderte selbst kastrieren, weil es irgendwo da draußen einen compiler gibt, der irgendetwas nicht kann. Während die compiler-Entwickler, falls denn dieser compiler noch weiterentwickelt wird, auch weiterhin nicht an der Standard-Unterstützung arbeiten, weil ja keiner diese features benutzt...

Hm, also vbcc übersetzt das ohne zu mosern, gcc auch (C99 Modus). Irgendwie finde ich es verdreht, über solche Klamotten zu diskutieren, so zu tun, als ginge das alles nicht mit den AmigaOS-Compilern, die noch verfügbar sind und immer noch weiterentwickelt werden, und darüber das eigentliche Problem völlig zu übersehen.

GCC ist und bleibt ein echtes Monster, dessen Wartung, Anpassung an "desolate" Plattformen und Verbesserung alles andere als eine simple Aufgabe ist. Wenn dann noch eine (mehr oder weniger) eigene Laufzeitumgebung ins Spiel kommt, wird die Geschichte noch viel unübersichtlicher. Da helfen einem Sprachstandards und neckische Möglichkeiten derselben relativ wenig. Das bleibt Sache der Compiler-Plattform, nicht des Systems, auf dem diese dann laufen soll.

Wenn man dann nur über die "Unzulänglichkeiten" von AmigaOS diskutiert bringt das echt wahnsinnig viel. Wenn man dazu in der Lage ist, möge man sich hinsetzen und die entsprechenden Anpassungen für gcc machen, das bringt wesentlich mehr, oder nicht?

Was mich aber etwas erstaunt: niemand meckert darüber, daß für das Bauen des GCC so viele der hier angesprochenen "Tricksereien" notwendig sind, um die Formalismen, auf denen GCC basiert, an die Realität anzupassen...

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

18.08.2006, 18:51 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Hm, also vbcc übersetzt das ohne zu mosern, gcc auch (C99 Modus).

Darum geht es ja. Es gibt keinen logischen Grund, auf die Features des C99-Standards zu verzichten. Auch wenn noch nicht alle unterstützt werden. Die wesentlichen von Solar genannten Punkte können schon heute <auch auf dem Amiga> verwendet werden.
Zitat:
Wenn man dann nur über die "Unzulänglichkeiten" von AmigaOS diskutiert bringt das echt wahnsinnig viel. Wenn man dazu in der Lage ist, möge man sich hinsetzen und die entsprechenden Anpassungen für gcc machen, das bringt wesentlich mehr, oder nicht?
Wir haben hier nicht über die Unzulänglichkeiten von AmigaOS diskutiert. Und ich verstehe nicht, welche Anpassungen ich für gcc machen sollte, wenn er out-of-the-box das richtige tut. Wenn jemand meint, sich den compiler mit einer zusätzlichen Bibliothek zerpatchen zu müssen, hat er auch das Problem mit den Inkompatiblitäten.
Zitat:
Was mich aber etwas erstaunt: niemand meckert darüber, daß für das Bauen des GCC so viele der hier angesprochenen "Tricksereien" notwendig sind, um die Formalismen, auf denen GCC basiert, an die Realität anzupassen...

Um die ... Formalismen ... an die Realität anzupassen ... :dance3:
könntest Du das bitte in's Deutsche übersetzen?
Worum geht es Dir eigentlich?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

19.08.2006, 00:32 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Hm, also vbcc übersetzt das ohne zu mosern, gcc auch (C99 Modus).

Darum geht es ja. Es gibt keinen logischen Grund, auf die Features des C99-Standards zu verzichten. Auch wenn noch nicht alle unterstützt werden. Die wesentlichen von Solar genannten Punkte können schon heute <auch auf dem Amiga> verwendet werden.

Sorry, ich hab das wohl ein wenig fehlinterpretiert. Zeitweise klang es so, als wäre C99 auf dem Amiga nicht in der vom GCC gewohnten Form möglich (daß der nicht alles brav nach Standard unterstützt ist ja ein anderes Thema).

Das man sich den GCC "kaputtpatchen" kann, steht außer Frage. Das geht allerdings nicht nur mit der clib2, das geht auch schon prima beim Bau eines Crosscompilers. Noch schlimmer, wenn selbiger mit einem Crosscompiler erzeugt wird. Da den Überblick zu behalten ist sicher nicht jedermanns Sache, da es ja eigentlich darum geht, etwas anderes mit dem Werkzeug Compiler zu machen.

Manchmal kommt beim gcc aber das Gefühl auf, daß der reiner Selbstzweck ist bzw. man erst Compilerexperte sein muß, um ein recht simples C-Programm (wahlweise alle unterstützten Sprachen hier einsetzen) damit schreiben zu dürfen.

Die Formalismen-Geschichte: Schau Dir an, wie der GCC funktioniert und wie die ganzen C- Perl- und was was ich noch alles für Dateien aufgebaut sind, die letztendlich einen (hoffentlich) funktionierenden GCC ergeben, dann weißt Du, was ich meine.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

19.08.2006, 19:19 Uhr

asrael229
Posts: 37
Nutzer
Zitat:
Original von gni:
Woran scheitert es?

Cool. Hab jetzt zumindest schonmal die Binutils kompilieren koennen.
Mit dem gcc-3.3 funktionierts anscheinend.
Bei Tiger ist ja standardmaessig der gcc4 aktiviert aber gcc-3.3 wird nachwievor mitinstalliert.

Mal schauen, obs mit gcc auch so reibungslos funktioniert.

Gruesse,
Manfred

[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Probleme mit new Operator bei g++ [ - Suche - Neue Beiträge - Registrieren - Login - ]


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