[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Dietmar:

Zitat:

---

Ich kann absolut nicht nachvollziehen, was Du hiermit sagen willst.

---

Er will damit sagen, dass jeder angehende Programmierer die Developer-CD braucht und dass auf dieser CD ein bestimmter Compiler halt nur einen Mausklick entfernt ist. Da er den C-Kurs schreibt, ist das letzlich seine Entscheidung, unbegründet ist sie jedenfalls nicht. Wenn wir noch lange herumnörgeln, verliert er noch die Lust, also Vorsicht

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:
Und die Pragmas muß halt jeder selbst in der Anleitung zu seinem Compiler nachschauen, falls er sie wirklich braucht.

---

Zitat:

---

Schau Dir zum Vergleich mal die Beispiele der NDKs an. Die sind teilweise so uralt, daß sie nichteinmal mehr mit einem halbwegs aktuellen Compiler richtig funktionieren, weil sich seit 1.3 halt schon einiges in den Includes verändert hat. Viele sind der NDK-Beispiele sind nichteinmal ANSI-komform (void main(void) usw.)

---

Zitat:

---

Trotzdem kann man aus den (teilweise veralteten) Beispielsources der NDKs noch was lernen. Aber der eigentliche Hauptgrund, der für den Kauf dieser CD spricht sind die RKRM's und Autodocs.

---

Zitat:

---

@Holger:
Dann kannst Du in der Zwischenzeit ja schonmal anfangen eine neue, vorbildliche IDE zu programmieren.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Tessien:
Falls das Community-Projekt "IDE" noch nicht gestorben ist... ich würde mitmachen.

---

Zitat:

---

Allerdings nur begrenzt, da meine Erfahrung in Oberflächenprogrammierung nahe Null liegen und ich bereits ein eigenes Nebenbei-Projekt pflege.

---

Zitat:

---

Meine Sorge ist eher, daß der Vorschlag von Holger kommt. Ich habe ihn wegen seiner Postings bisher nur als Sprücheklopfer mit zuviel Selbstvertrauen kennengelernt. Um ein solches Projekt auf die Beine zu stellen, braucht es doch eher andere Fähigkeiten. Gibt es denn sonst noch jemand, der da mitmachen würde?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von Tessien:
Falls das Community-Projekt "IDE" noch nicht gestorben ist... ich würde mitmachen.

---

Bislang hat es noch nichtmal angefangen.

---

Zitat:

---

Siehs mal so: am Sinn des Vorschlags als solchen gibt es nichts zu rütteln, und wenn Du in Zukunft auch nach dem Inhalt und nicht der Quelle gehst, wird das auch funktionieren.
Aber an weiteren Interessenten bin ich natürlich auch interessiert, zwei sind nicht genug.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Falls das Community-Projekt "IDE" noch nicht gestorben ist... ich würde mitmachen. Allerdings nur begrenzt, da meine Erfahrung in Oberflächenprogrammierung nahe Null liegen und ich bereits ein eigenes Nebenbei-Projekt pflege. Ich würde den Teil übernehmen, den ich an Visual C am meisten schätze: Intellisense

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Dietmar:
Falls das Community-Projekt doch gestorben ist: Intellisense könnte man auch in GoldED nachrüsten und den Editor als Ausgangspunkt für eine IDE nehmen. Eine Schnittstelle für Plug-Ins gibt es schon ...

---

Zitat:

---

Allerdings habe ich noch nie Zeit und Motivation gehabt, richtiges Intellisense zu machen, das z.B. Struktur-Mitglieder vorschlägt. Dazu müsste man eine Datenbank im Hintergrund haben, die ständig alle geänderten Dateien eines Projektes durchsucht und einen Baum mit globalen und lokalen Objekten und ihrer Struktur aufbaut. Schwierig ist vor allem der C++-Parser: wenn der User /* oder { eintippt, dann verändert sich schlagartig die Struktur grosser Sourcecode-Abschitte. Man müsste einen Parser schreiben, der C++ versteht und zerlegt UND mit Sourceode in einem Zwischenzustand zurechtkommt (nicht syntaktisch/semantisch korrekt) UND rasend schnell ist UND auf Nachrichten der Art "Zeile 100 wurde geändert" zurechtkommt, um auf dieser Basis seine Datenbank zu aktualisieren.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Dietmar:
Etwas von Deinen Ideen ist sowieso schon drin, z.B. Typ-Info für die Parameter einer OS-Funktion, die man gerade eingetippt hat. Allerdings habe ich noch nie Zeit und Motivation gehabt, richtiges Intellisense zu machen, das z.B. Struktur-Mitglieder vorschlägt. Dazu müsste man eine Datenbank im Hintergrund haben, die ständig alle geänderten Dateien eines Projektes durchsucht und einen Baum mit globalen und lokalen Objekten und ihrer Struktur aufbaut. Schwierig ist vor allem der C++-Parser: wenn der User /* oder { eintippt, dann verändert sich schlagartig die Struktur grosser Sourcecode-Abschitte. Man müsste einen Parser schreiben, der C++ versteht und zerlegt UND mit Sourceode in einem Zwischenzustand zurechtkommt (nicht syntaktisch/semantisch korrekt) UND rasend schnell ist UND auf Nachrichten der Art "Zeile 100 wurde geändert" zurechtkommt, um auf dieser Basis seine Datenbank zu aktualisieren.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von Mad_Dog:
Und die Pragmas muß halt jeder selbst in der Anleitung zu seinem Compiler nachschauen, falls er sie wirklich braucht.

---

Na großartig. Bist Du Dir sicher, dass das Ergebnis ein Anfängerkurs wird?

---

Zitat:

---

Zitat:

---

Schau Dir zum Vergleich mal die Beispiele der NDKs an. Die sind teilweise so uralt, daß sie nichteinmal mehr mit einem halbwegs aktuellen Compiler richtig funktionieren, weil sich seit 1.3 halt schon einiges in den Includes verändert hat. Viele sind der NDK-Beispiele sind nichteinmal ANSI-komform (void main(void) usw.)

---

Und Du willst unter diesen Umständen einen Kurs auf einem Compiler aufbauen, der heute ebenfalls schon veraltet ist?

---

Zitat:

---

Zitat:

---

Trotzdem kann man aus den (teilweise veralteten) Beispielsources der NDKs noch was lernen. Aber der eigentliche Hauptgrund, der für den Kauf dieser CD spricht sind die RKRM's und Autodocs.

---

Und die Texte, die den in den Beispielsourcen enthaltenen Code auch gleich als veraltet beschreiben.
Nein, der Hauptgrund dürfte wohl sein, dass es derzeit nichts anderes gibt.

---

Zitat:

---

Zitat:

---

@Holger:
Dann kannst Du in der Zwischenzeit ja schonmal anfangen eine neue, vorbildliche IDE zu programmieren.

---

Mit bislang einem weiteren Interessenten wird das wohl nix.
Abgesehen davon ist das Wort vorbildlich in diesem Zusammenhang unsinnig, so etwas gibt es nicht. Es gibt eher einen noch zusammenzutragenden Katalog von Forderungen, den wir an eine solche IDE stellen. Das wird aber auch nichts, wenn wir schon über die grundsätzliche Notwendigkeit streiten müssen.

---

Wenn Du mal anfangen würdest, eine Spezifikation Deiner "IDE NG" zu machen, würden sich bestimmt einige Leute dafür interessieren.
Mein Tip: Notorische Nörgler und Ignoranten einfach ignorieren.
Leg einfach mal los, mach ein Konzept usw. . Sicherlich werden dann wieder einige sagen "das funktioniert doch nie", aber mich persönlich motivieren solche Aussagen dann noch mehr. Am Ende staunen die Pessimisten dann oft am meisten, wenn sie sehen, was alles geht.
--

http://www.norman-interactive.com


[ Dieser Beitrag wurde von Mad_Dog am 24.02.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

All die "UND"s im obigen Text sind zwar logisch, aber ich wäre für den Anfang zufrieden mit einem Parser, der C++ versteht und sonst nix

---

Zitat:

---

Was brauche ich denn, wenn ich PlugIns für GoldEd entwickeln will? Und falls irgend jemand von Euch Ideen hat, wie das Problem anzugehen ist, bitte ich um Vorschläge.

---

[ - Antworten - Zitieren - Direktlink - ]

Zurück zum C-Kurs:

Habe jetzt im 1. Kapitel noch eine Lektion über Aussagelogische Operatoren eingefügt (hatte ich doch glatt vergessen ).

Als nächstes sind dann wohl structs (ja Solar mit C ) dran.

Ich überlege mir noch, ob es für Anfänger sinnvoll ist, auch Listen und Bäume zu besprechen. Ich würde mal sagen: Ja. Denn in der AmigaOS API (und nicht nur in der) werden solche Datenstrukturen ständig verwendet. Und wer sowas nicht kennt, fängt dann an zu pfuschen, sobald es um Fenster usw. geht.

--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:
Ich überlege mir noch, ob es für Anfänger sinnvoll ist, auch Listen und Bäume zu besprechen. Ich würde mal sagen: Ja. Denn in der AmigaOS API (und nicht nur in der) werden solche Datenstrukturen ständig verwendet. Und wer sowas nicht kennt, fängt dann an zu pfuschen, sobald es um Fenster usw. geht.

---

Selbst wenn es nicht im Zusammenhang mit dem AmigaOS auftreten würde, ist es sinnvoll, diese Konzepte zu besprechen. Es schadet nichts, wenn der C-Kurs auch ein Programmier-Kurs wird.
Schliesslich mangelt es dem Amiga an Software, nicht an C-Programmierern

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

[ - Antworten - Zitieren - Direktlink - ]

Ich hab jetzt mal zwei Lektionen über Zeiger und Adressen und Zeiger auf Strukturen reingesetzt. Ist garnicht so leicht, diese Konzepte anfängergerecht herüberzubringen... Wie gefällt Euch meine Roboter-Analogie?

Listen und Bäume werde ich auf jeden Fall noch bringen.

--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Ich habe hier gerade gesehen, daß einige Leute darüber nachgrübeln, eine IDE zu schreiben (Oder daß mal jemand eine schreiben müßte.). Und daß von Grund auf anfangen aufwendig ist.

Guckstu hier:
AmIDE

Der gute DaMato freut sich sicher, wenn da noch ein paar Leute einsteigen und sich endlich mal wieder was um sein Baby tut. Lizenz ist GPL, haut rein.

(Ich habe schon selber überlegt, bin aber im Augenblick ein wenig bei Eclipse hängengeblieben und wollte da evtl. was mit Crosscompiling zusammenpfriemeln )

OBW

[ - Antworten - Zitieren - Direktlink - ]

Ich verfolge denn C-Kurs und bei denn Strukts kam es bei mir zu einem "Aha"-Erlebniss.

Jetzt möchte ich aber meine alten Basic-Projekte nicht sterben lassen bzw. ist es fast unmöglich sie in C zu neu zu schreiben.

Deswegen folgende Frage:
Wenn ein Programm ein Strukt zurückliefert das z.b. wie folgt aufgebaut ist, wie kann ich dann mit Basic drauf zugreifen?

struct test
{
struct bla
struct bla2
...
}

struct bla
{
ULONG info
...
}

...

Wie kann ich dann am besten auf die Daten zurückgreifen? Ich nehme mal folgendes an:

Anfangbla=peekl(test)
Anfangbla2=peekl(test+4)
Info=peekl(Anfangbla)

Kommt das so in etwa hin?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

@Ralf27:

Freut mich, daß Du zu einem Aha-Erlebnis gekommen bist.
Wenn Du Dich ein wenig weiter in C reinarbeitest, wirst Du mit Sicherheit auch Deine alten Basic-Programme nach C umschreiben können. Merke: Die Idee, die hinter einem Programm steht, steht im Vordergrund, nicht die Implementierung in einer bestimmten Programmiersprache oder API. Als z.B. mal ein Student des Bauwesens zu mir kam, damit ich ihm beim Lernen auf seine Informatik-Prüfung helfe, haben wir zusammen die "Kochsche Schneeflocke", die ich zuvor in C mit OpenGL bzw. Intuition gemacht habe, nach Visual Basic portiert um das Thema "Rekursion" zu vertiefen.

Wie man auf Strukturen in MaxonBasic zugreift, kann ich Dir nicht sagen, da ich es nicht kenne. Aber Du hast das bestimmt schonmal gemacht, wenn Du die AmigaOS API programmiert hast (z.B. Intuition).

Wie Du anhand des Kurses siehst, geht das in C recht einfach. In BASIC mußt Du eventuell die Adresse der einzelnen Komponenten der Structs berechnen oder so... kein Plan.

Zum Thema "Zeiger" baue ich vielleicht noch ein paar Bilder zum besseren Verständnis ein... in der Zwischenzeit hilft Dir vielleicht meine "Roboter-Analogie"
--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

Also, zum einen ist Basic nicht komplizierter als C.

Die Frage ist nur wie ein Struct im Speicher abgelegt ist. Das ist eigentlich alles.

Aber eins muß ich C zugute halten was MBasic nicht hat:
Typen von einem Byte Größe. Das ist gerade bei einer Graphics-Funktion sehr wichtig und das fehlt mir bei MBasic(könnte ich zwar auch in Basic umschreiben, aber das wird dann langsamer als schneller).
Insofern würde ich gerne ein Beispielprogramm von Basic in C konvertieren das nicht gerade lang ist, aber zum testen...

Hey, ihr macht mir aber C recht schmackhaft!

[ Dieser Beitrag wurde von Ralf27 am 30.03.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Also, zum einen ist Basic nicht komplizierter als C.

---

Zitat:

---

Die Frage ist nur wie ein Struct im Speicher abgelegt ist. Das ist eigentlich alles.

---

Das braucht einen C-Programmierer nicht zu interessieren.
Das einzige, was ab und zu mal interessant ist, ist die Größe in Byte eines sochen Structs. Die bekommt man aber ganz einfach mit dem sizieof-Operator.

Zitat:

---

Insofern würde ich gerne ein Beispielprogramm von Basic in C konvertieren das nicht gerade lang ist, aber zum testen...

Hey, ihr macht mir aber C recht schmackhaft!

---

Yo! Dann hau mal rein.


--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Die Frage ist nur wie ein Struct im Speicher abgelegt ist. Das ist eigentlich alles.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

/*  Listing 7.2
 *  Das erste Fenster
 */

#include <exec/types.h>
#include <exec/exec.h>
#include <intuition/intuition.h>

#include <clib/exec_protos.h>
#include <clib/intuition_protos.h>

// Symbolische Konstanten
#define WIDTH 300   // Breite des Fensters
#define HEIGHT 300  // Höhe des Fensters

struct Window *Fenster;                // Zeiger auf Window-Struktur
struct IntuitionBase *IntuitionBase;   // Zeiger auf IntuitionBase-Struktur

int main(void)
{

  // Intuition Library öffnen
  IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",0L);

  if (IntuitionBase != NULL)
  {

    // Fenster mittels Tags öffnen
    Fenster = OpenWindowTags(NULL,
                             WA_Left, 100,       // Abstand vom linken Rand
                             WA_Top, 100,        // Abstand vom oberen Rand
                             WA_Width, WIDTH,    // Breite
                             WA_Height, HEIGHT,  // Höhe
                             WA_Title, "Mein erstes Fenster", // Fenstertitel
                             WA_CloseGadget, TRUE,            // Close-Gadget
                             WA_DragBar, TRUE,                // Ziehleiste
                             WA_DepthGadget, TRUE,            // Depth-Gadget
                             WA_IDCMP, IDCMP_CLOSEWINDOW,
                             WA_Activate, TRUE,               // Fenster aktivieren
                             TAG_DONE);

    if (Fenster != NULL)
    {
      // Auf Close-Gadget warten
      Wait(1L << Fenster->UserPort->mp_SigBit);

      CloseWindow(Fenster);   // Fenster schließen
    } // end if

  } // end if

  // Librarie schließen
  if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase);

  return 0;

}

---

Bin etwas ratlos... was ist jetzt "richtig(er)"?
Jedenfalls kann man sich die Typecasts sparen, wenn man den Zeiger als struct Library statt struct IntuitionBase deklariert.

Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind???

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt.

--

http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 31.03.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:

Bin etwas ratlos... was ist jetzt "richtig(er)"?
Jedenfalls kann man sich die Typecasts sparen, wenn man den Zeiger als struct Library statt struct IntuitionBase deklariert.

Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind???

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt.

---

Also, wenn Du die intuition.library als Library benutzen willst, dann reicht struct Library. Aber wahrscheinlich wollen alle möglichen Klamotten auf mehr oder weniger interne Strukturen der Intuitionbase zugreifen (s.a. intuition/intuitionbase.h) und abgesehen von der struct Library (die ja direkt am Anfang steht, deswegen ist direktes casten einfach möglich) auf den Rest zugreifen.

IntuitionBase ist halt nicht nur struct Library. Genau wie DosBase auch struct DosLibrary ist.

BTW hat dein Code (noch? ) einen Fehler, OpenLibrary() solltest Du nicht mit 0L, sondern mit 36L machen, sonst bekommst Du auf Kickstart < 2.0 einen üblen Absturz, da Du OpenWindowTags() benutzt, was es damals noch nicht gegeben hat.

<clib/dos_protos.h> sollte man nie includen. Eigentlich sollte man <proto/dos.h> nehmen, welches abhängig vom Compiler dann die richtigen Includes reinsaugt. Leider sind die <proto/*.h>-Dateien vom NDK IIRC nur für SAS/C ausgelegt, man muß also mit fd2pragma selber den Rest nachbauen. Dafür hat man dann aber Includes, die mit allen Compilern gehen, also egal welcher Compiler, <proto/xxx.h> für die xxx.library. Und ja, das ist nervig, ich habe das letztens für den gcc gemacht, um AWeb endlich wieder ans Übersetzen zu bekommen.

StormC hat sich vielleicht Mühe gegeben, SAS-kompatibel zu sein.

HTH, OBW

[ - Antworten - Zitieren - Direktlink - ]

@ Mad_Dog

quote:

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt

Dieses Schlamassel finde ich garnicht mal so scheinbar. Mir sind schon einige Quelltexte untergekommen, die mit StormC3.0 sauber kompiliert wurden, während andere Kompiler "die Hände über'm Kopf zusammenschlugen", und abbrachen.
Als Anfänger bekommt man solche Sachen auch nicht einfach mal schnell geradegebogen.
Dein Beispiel mit dem "ersten Fenster" lässt sich ja - trotz rummosern - wenigstens noch kompilieren. Anderst Dein Beispiel zum zeichnen des Sierpinski-Dreiecks in Kapitel 8.
Mit StormC3.0 - no problem. Aber weder vbbc noch gcc3.3 konnte ich übereden, daraus ein Programm zu stricken. Mein letzter Versuch sah wie folgt aus:

gcc Ram:Sierpinski-Dreieck.c -o Ram:Sierpinski-Dreieck -s -lc
Ram:Sierpinski-Dreieck.c: In function 'DrawSierpinski':
Ram:Sierpinski-Dreieck.c:102: error: parse error before "int"
Ram:Sierpinski-Dreieck.c:102: error: parse error before ')' token
Ram:Sierpinski-Dreieck.c: At top level:
Ram:Sierpinski-Dreieck.c:128: error: parse error before '}' token

Und immer ist es hier die Zeile 102 >>switch (random(0,2)) <<.
Na, jedenfalls stehe ich in diesen Punkt mal wieder auf dem Schlauch.

mfg Palgucker

P.s. Könnte man gcc nicht wenigstens in der Amigaversion die Option -brutal oder -nofear verpassen?

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Palgucker:
@ Mad_Dog

quote:

Jedenfalls habe ich das (scheinbare) Schlamassel mit StormC nie bemerkt

Dieses Schlamassel finde ich garnicht mal so scheinbar. Mir sind schon einige Quelltexte untergekommen, die mit StormC3.0 sauber kompiliert wurden, während andere Kompiler "die Hände über'm Kopf zusammenschlugen", und abbrachen.
Als Anfänger bekommt man solche Sachen auch nicht einfach mal schnell geradegebogen.

---

Zitat:

---

gcc Ram:Sierpinski-Dreieck.c -o Ram:Sierpinski-Dreieck -s -lc
Ram:Sierpinski-Dreieck.c: In function 'DrawSierpinski':
Ram:Sierpinski-Dreieck.c:102: error: parse error before "int"
Ram:Sierpinski-Dreieck.c:102: error: parse error before ')' token
Ram:Sierpinski-Dreieck.c: At top level:
Ram:Sierpinski-Dreieck.c:128: error: parse error before '}' token

Und immer ist es hier die Zeile 102 >>switch (random(0,2)) <<.
Na, jedenfalls stehe ich in diesen Punkt mal wieder auf dem Schlauch.

mfg Palgucker

P.s. Könnte man gcc nicht wenigstens in der Amigaversion die Option -brutal oder -nofear verpassen?

---

>>switch (random(0,2)) <<

Das das _ohne_ Semikolon da steht, ist doch hoffentlich nur ein Copy&Paste-Versehen? Hoffentlich, weil "parse error" meist ein Hinweis auf ein vergessenes Semikolon oder eine fehlende Klammer ist. Dank der "genaueren" Fehlermeldungen des GCC ("parse error" finde ich enorm spezifisch kommts sehr häufig vor, daß man in ner völlig korrekten Zeile nach dem Fehler sucht und den logischerweise nicht findet, weil da nun mal gar kein Fehler ist. Ich habe mir den Source jetzt nicht ansehen können, daher kann ich nicht sagen, was der Fehler ist. Aber schau doch mal in der näheren Umgebung der Zeile 102, womöglich stößt Du da auf den Fehler.

Grüße

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:

Bin etwas ratlos... was ist jetzt "richtig(er)"?
Jedenfalls kann man sich die Typecasts sparen, wenn man den Zeiger als struct Library statt struct IntuitionBase deklariert.

Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind???

---

Also, _korrekter_ ist die aktuelle Fassung. IntuitionBase ist in den Includes vom Typ "struct IntuitionBase *", also sollte man das auch so deklarieren. Das bei OpenLibrary() und CloseLibrary() ein Cast nötig wird, ist zwar lästig, aber auch nicht so dramatisch.

Zum Thema <clib/...>: So ganz Recht hat der Vorredner zu dem Thema nicht. <clib/dos_protos.h> sollte man immer dann einbinden, wenn man _nicht_ mittels #pragma oder (beim GCC) Macros für die OS-Funktionseinsprünge arbeitet, sondern die Stub-Funktionen der amiga.lib oder storm.lib (oder wie die Compiler-Lib auch immer heißt) verwendet.

Das der GCC bei Dir meckert, mag damit zusammenhängen, daß Du (unwissentlich) die inline/-Macros für die OS-Einsprünge benutzt. Solange Du das machst, nimmst besser <proto/...> statt <clib/...>. Meistens meckert der GCC nicht, aber manchmal dann doch

Grüße

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

obw:
IntuitionBase ist halt nicht nur struct Library. Genau wie DosBase auch struct DosLibrary ist.

---

Zitat:

---

<clib/dos_protos.h> sollte man nie includen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Mad_Dog:
Seltsamerweise motzt der gcc auch herum, falls man <clib/dos_protos.h> includiert. Mir scheint, daß einige der Includes der NDKs noch von/für ältere Compiler sind??? :dance3:

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Palgucker:
Anderst Dein Beispiel zum zeichnen des Sierpinski-Dreiecks in Kapitel 8. Mit StormC3.0 - no problem. Aber weder vbbc noch gcc3.3 konnte ich übereden, daraus ein Programm zu stricken. Mein letzter Versuch sah wie folgt aus:

gcc Ram:Sierpinski-Dreieck.c -o Ram:Sierpinski-Dreieck -s -lc
Ram:Sierpinski-Dreieck.c: In function 'DrawSierpinski':
Ram:Sierpinski-Dreieck.c:102: error: parse error before "int"
Ram:Sierpinski-Dreieck.c:102: error: parse error before ')' token
Ram:Sierpinski-Dreieck.c: At top level:
Ram:Sierpinski-Dreieck.c:128: error: parse error before '}' token

Und immer ist es hier die Zeile 102 >>switch (random(0,2)) <<.
Na, jedenfalls stehe ich in diesen Punkt mal wieder auf dem Schlauch.

---

Zitat:

---

P.s. Könnte man gcc nicht wenigstens in der Amigaversion die Option -brutal oder -nofear verpassen? ;)

---

[ - Antworten - Zitieren - Direktlink - ]