Zitat:

---

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

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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

Zitat:

---

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

---

Zitat:

---

Auf welchem System hast Du denn den Cross-Compiler?

---

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.

---

Zitat:

---

Haette noch ein PPC-Linux aber was mit i386 hab ich garnix.

---

[ - Antworten - Zitieren - Direktlink - ]

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

---

code:

---

VerseKey::VerseKey(const VerseKey &k) : SWKey(k)
{
   ...
}

---

code:

---

SWKey *VerseKey::clone() const

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von woop:

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

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Solar:

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

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:
Woran scheitert es?

---

Zitat:

---

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

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

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

---

[ - Antworten - Zitieren - Direktlink - ]

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

---

Zitat:

---

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

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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?

---

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

---

code:

---

$prog ${1+"$@"} "$input"

---

[ - Antworten - Zitieren - Direktlink - ]

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

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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.

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()

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

asrael229:
das war ein svn checkout vom trunk.

---

Zitat:

---

Wobei ich auf meinem Debian PPC Linux ein aehnliches Problem mit den Binutils habe.
In der Zeile 86 steht:

code:

---

$prog ${1+"$@"} "$input"

---

---

Zitat:

---

Auch haben alle BSDs unter Mac es noch fertig gebracht einen vernueftigen Bootloader einzusetzen. yaboot koennte doch wahrscheinlich leicht portiert werden.

---

Zitat:

---

Ich denke Grundsaetzlich wird die i386 Welt von vielen Sourcen besser unterstuetzt.

---

Zitat:

---

Auch die Compiler erzeugen IMO besser bzw. schnelleren Code unter i386.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Solar:
alle Variablen am Anfang der Funktion deklarieren

---

Zitat:

---

Schleifenzähler außerhalb der Schleife deklarieren

---

Zitat:

---

<stdint.h> ignorieren (m.E. der praktischste Header in C99)

---

Zitat:

---

wildeste Makro-Magie kreuz und quer durch den Code wo's eine inline-Funktion auch getan hätte

---

Zitat:

---

pro Quellcodedatei zwei Dutzend Compilerwarnungen fröhlich ignorieren

---

Zitat:

---

Im Alltag kriege ich allerdings eher Weinkrämpfe, wenn ich mal wieder ein

code:

---

bool hasNext()

---

lese...

---

[ - Antworten - Zitieren - Direktlink - ]

@ 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...

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

Solar:
alle Variablen am Anfang der Funktion deklarieren

---

Das ist Geschmacksache.

---

Zitat:

---

Zitat:

---

Schleifenzähler außerhalb der Schleife deklarieren

---

Reden wir von C?

---

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.

---

Zitat:

---

Zitat:

---

wildeste Makro-Magie kreuz und quer durch den Code wo's eine inline-Funktion auch getan hätte

---

C?

---

Zitat:

---

Zitat:

---

Im Alltag kriege ich allerdings eher Weinkrämpfe, wenn ich mal wieder ein

code:

---

bool hasNext()

---

lese...

---

Ist das Java?

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

Zitat:

---

Außerdem waren die Probleme völlig anderer Natur.

---

[ - Antworten - Zitieren - Direktlink - ]

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".

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

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

---

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.

---

C code:

---

#include <stdint.h>
#include <stdio.h>

inline void out(char const * const txt, int8_t const num)
{
  printf("%st%dn", txt, num);
}

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

---

[ - Antworten - Zitieren - Direktlink - ]

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("%st%dn", 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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

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

---

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?

---

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

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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:
Woran scheitert es?

---

[ - Antworten - Zitieren - Direktlink - ]