Zitat:

---

Original von gni:

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

---

GCC meckert andere Sachen an als andere Compiler. Wenn man Strukurzeiger als Funktionsargument verwenden möchte, dann muß der Compiler die Struktur bereits gesehen haben. Ansonsten gibts Mecker, da das vom ANSI/ISO Standard so gefordert wird. (Das Programm läuft dennoch und macht auch was man erwartet, aber es gibt wohl Fälle wo das nicht so ist.) SAS/C war/ist da etwas relaxter.

---

Damit hängts meistens weniger zusammen. Mehr mit dem Tohuwabohu in den Includes. Wennst ne Standard-StormC4-Installation frisch von der CD zum compilieren benutzt, kanns Dir passieren, daß der GCC wegen z.B. Printf() (die AOS-Funktion!) mit "parse error" meckert, obwohl Du <proto/dos.h> eingebunden hast. Das kommt _nicht_ daher, weil er die Strukturen nicht gesehen hat, sondern daher, daß das Einsprung-Macro ganz einfach falsch ist

Im übrigen tendieren diese Macros dazu, den Namespace zu überschwemmen, daher kommt auch der Fehler mit #include <clib/dos_protos.h>.

Regel ist: Aufruf der OS-Funktionen via Stubs aus der Compiler-Bibliothek: #include <clib/...>

Aufruf der OS-Funktionen via #pragma oder Macro: #include <proto/..>

Tip an Mad Dog: Setz mal in den StormC4-Compiler-Optionen ein zusätzliches #define ein: NO_INLINE_LIBCALLS (keine OS-Einsprünge via inline-Macros)

Das dürfte den Fehler beseitigen und sollte bei ner "normalen" GCC-Installation auch funktionieren.

Grüße

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Im übrigen tendieren diese Macros dazu, den Namespace zu überschwemmen, daher kommt auch der Fehler mit #include <clib/dos_protos.h>.

---

Zitat:

---

Regel ist: Aufruf der OS-Funktionen via Stubs aus der Compiler-Bibliothek: #include <clib/...>

Aufruf der OS-Funktionen via #pragma oder Macro: #include <proto/..>

---

Zitat:

---

Tip an Mad Dog: Setz mal in den StormC4-Compiler-Optionen ein zusätzliches #define ein: NO_INLINE_LIBCALLS (keine OS-Einsprünge via inline-Macros)

Das dürfte den Fehler beseitigen und sollte bei ner "normalen" GCC-Installation auch funktionieren.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

/*   Sirpinski-Fraktal
 *
 */

#include <exec/types.h>
#include <exec/exec.h>
#include <intuition/intuition.h>
#include <graphics/gfx.h>
#include <dos/dos.h>
#include <stdlib.h>

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

/*  Makro zur Erzeugung einer Zufallszahl
 *  im Bereich min..max
 */
#define random(min,max) ((rand() % (int)((max+1.0)-min))+min)

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

struct Window  *Fenster;        // Zeiger auf Window-Struktur
struct Library *IntuitionBase;  // Zeiger auf IntuitionBase-Struktur
struct Library *GfxBase;        // Zeiger auf Library-Struktur
struct RastPort *rp;            // Zeiger auf RastPort-Struktur

// Funktionsprototypen
void DrawSierpinski(void);

int main(void)
{
  // Intuition Library öffnen
  IntuitionBase = OpenLibrary("intuition.library",36L);

  if (IntuitionBase != NULL)
  {
    // Graphics Library öffnen
    GfxBase = OpenLibrary("graphics.library",0L);

    // 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, "Sierpinski",         // Fenstertitel
                             WA_ScreenTitle, "Sierpinski",   // Screen-Titel
                             WA_CloseGadget, TRUE,           // Close-Gadget
                             WA_DragBar, TRUE,               // Ziehleiste
                             WA_DepthGadget, TRUE,           // Depth-Gadget
                             WA_GimmeZeroZero, TRUE,         // Ursprung 0/0
                             WA_IDCMP, IDCMP_CLOSEWINDOW,
                             WA_Activate, TRUE,              // Fenster aktivieren
                             TAG_DONE);

    if (Fenster != NULL)
    {

      rp = Fenster->RPort;  // rp zeigt auf RastPort des Fensters

       SetRast(rp, 1L);      // Fensterinhalt löschen

      SetAPen(rp, 2L);      // Farbe setzen

      DrawSierpinski();     // Fraktal zeichnen

      // Auf Close-Gadget warten
      Wait(1L << Fenster->UserPort->mp_SigBit);

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

  } // end if

  // Libraries schließen
  if (GfxBase != NULL) CloseLibrary(GfxBase);
  if (IntuitionBase != NULL) CloseLibrary(IntuitionBase);

  return 0;

}

// Funktion zum Zeichnen des Sirpinski-Fraktals
void DrawSierpinski(void)
{
   int iterate;
   SHORT x1, y1, x2, y2;

   x1 = x2 = WIDTH/2;
   y1 = y2 = 0;

   // Schleife zum Iterieren und Zeichnen der Pixel

    for(iterate = 0; iterate < 10000; iterate++)
    {
    // Zufallswerte erzeugen/

     switch (random(0,2))
      {

      case 0:  x1 = (x2 + WIDTH/2) / 2;
                  y1 = y2 / 2;
         break;

         case 1:  x1 = x2 / 2;
                  y1 = (y2 + HEIGHT) / 2;
         break;

         case 2:  x1 = (x2 + WIDTH) / 2;
                  y1 = (y2 + HEIGHT) / 2;
         break;

      }

      // Amiga Graphik-Primitive
      WritePixel (rp,x1, y1);

      x2 = x1;
      y2 = y1;

    }

}

---

Dabei habe ich folgendes festgestellt:

1.) Der gcc mag nur Zeiger auf Library-Structs, die genauso heißen wie der Datentyp des Structs selbst, also z.B. struct Library *IntuitionBase; StormC hingegen schluckt auch sowas wie struct Library *IntBase; . Dabei finde ich es von Stil her schöner, wenn der Zeiger nicht unbedingt den gleichen Bezeichner hat, wie der Typ des Structs.

2.) Das geschilderte Problem mit dem Syntax Error kommt, daher, daß es der gcc einem übel nimmt, wenn man bei einem Typecast den Datentyp nicht in Klammern setzt. StormC ist es egal. Deshalb hat mein Makro random() auch nicht funktioniert.

3.) Der gcc gibt Warnings bezüglich der Header-Datei <clib/graphics_protos.h> aus. (bin etwas ratlos - flasche Includes?)

--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Mad_Dog:

code:

---

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

---

---

Zitat:

---

code:

---

struct Library *IntuitionBase;  // Zeiger auf IntuitionBase-Struktur
struct Library *GfxBase;        // Zeiger auf Library-Struktur

---

---

Zitat:

---

1.) Der gcc mag nur Zeiger auf Library-Structs, die genauso heißen wie der Datentyp des Structs selbst, also z.B. struct Library *IntuitionBase; StormC hingegen schluckt auch sowas wie struct Library *IntBase; . Dabei finde ich es von Stil her schöner, wenn der Zeiger nicht unbedingt den gleichen Bezeichner hat, wie der Typ des Structs.

---

Zitat:

---

2.) Das geschilderte Problem mit dem Syntax Error kommt, daher, daß es der gcc einem übel nimmt, wenn man bei einem Typecast den Datentyp nicht in Klammern setzt. StormC ist es egal. Deshalb hat mein Makro random() auch nicht funktioniert.

---

Zitat:

---

3.) Der gcc gibt Warnings bezüglich der Header-Datei <clib/graphics_protos.h> aus. :dance3: (bin etwas ratlos - flasche Includes?)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

code:

---

struct Library *IntuitionBase;  // Zeiger auf IntuitionBase-Struktur
struct Library *GfxBase;        // Zeiger auf Library-Struktur

---

---

Wie hier. "Richtig" ist "struct IntuionBase *" bzw "struct GfxBase *".
"struct Library *" geht halt nicht, wenn man die proto/ Header die "richtigen" Typen verwenden.

---

code:

---

...

struct IntuitionBase *IntuitionBase;  // Zeiger auf IntuitionBase-Struktur
struct GfxBase *GfxBase;        // Zeiger auf GfxBase-Struktur

...

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

  if (IntuitionBase != NULL)
  {
    // Graphics Library öffnen
    GfxBase = (struct GfxBase *) OpenLibrary("graphics.library",0L);

...


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

...

---

[ - Antworten - Zitieren - Direktlink - ]

Übrigens: Es muß Sierpinski heißen.
--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:
Frag mal Solar bezüglich seinen Erfahrungen mit Storm und seinen SFStools.

---

Öhm... ich glaube Du verwechselst mich mit jemandem. SFS habe ich nie genutzt, geschweige den compiliert.

[ - Antworten - Zitieren - Direktlink - ]

Jedenfalls hab ich die Codes auf der Website der C-Kurses jetzt entsprechend geändert. Falls es noch Unstimmigkeiten geben sollte: Bitte Schreien!
--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

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

---

Unterschreib ich nicht :-P

---

Asche über mein Haupt! Bin ich entschuldigt, wenn ich sage, daß ich eigentlich immer die proto-Header verwende und völlig vergessen hatte, wofür die clib-Header eigentlich sind?

*schäm und in die Ecke stell*

OBW

[ - Antworten - Zitieren - Direktlink - ]

code:

---

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

---

code:

---

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

---

code:

---

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

---

code:

---

extern struct IntuitionBase * IntuitionBase;

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:
Trotzdem kommt mir das ganze Rumgecaste noch reichlich sinnlos vor.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:

Zitat:

---

Original von Mad_Dog:
Trotzdem kommt mir das ganze Rumgecaste noch reichlich sinnlos vor.

---

Mach Dir nichts draus. Es liegt schlicht und ergreifend daran, daß die struct IntuitionBase ein (winzig kleine) Erweiterung zur struct Library darstellt.

---

code:

---

struct Library *IntuitionBase;

---

Und dann müsste ich nicht so sinnlos rumcasten. Aber einige von Euch schreien dann hell auf, obwohl es in den meisten NDK-Beispielen auch so gemacht ist...
--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Palgucker:
@ Mad_Dog

Habe heute nochmal an Deinen alten Sierpinski-Code zur Übung 'rumgebastelt, und musste erstaunt feststellen, das bei mir nur eine einzige Änderung von Nöten war, die über Gedeih oder Verderb entschied.
Und zwar änderte ich nur
#define random(min,max) ((rand() % int((max+1.0)-min))+min)
in
#define random(min,max) ((rand() % (int)((max+1.0)-min))+min)

---

code:

---

#define random(min,max) ((rand() % ((max+1)-min))+min)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Solar:

Zitat:

---

Original von gni:
Frag mal Solar bezüglich seinen Erfahrungen mit Storm und seinen SFStools.

---

Öhm... ich glaube Du verwechselst mich mit jemandem.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Mad_Dog:
Seltsamerweise ist das in einigen Beispielen der NDKs auch mit struct Library *IntuitionBase; gelöst. Jedenfalls kann man sich so die lästigen Typecasts sparen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:
Na sowas, Helios != Solar.

---

true.

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Mad_Dog:
Trotzdem kommt mir das ganze Rumgecaste noch reichlich sinnlos vor.

---

Zitat:

---

Dann muß ich einen Typecast machen, bevor ich den Zeiger zuweise, weil OpenLibrary einen Zeiger auf eine Struktur vom Typ Library zurückgibt:

code:

---

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

---

---

Zitat:

---

Beim Schließen muß ich nochmal Casten, da CloseLibrary als Eingabeparameter ebenfalls einen Zeiger auf eine Struktur vom Typ Library erwartet:

code:

---

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

---

---

code:

---

&IntuitionBase->LibNode

---

Zitat:

---

Ich halte also einen Zeiger auf IntuitionBase, obwohl ich eigentlich einen Zeiger auf Library brauche. Ziemlich strange.

---

Zitat:

---

Und daß der Zeiger tatsächlich IntuitionBase heißen muß, liegt an der Definition des globalen Zeigers IntuitionBase in <proto/intuition.h> :

code:

---

extern struct IntuitionBase * IntuitionBase;

---

---

Zitat:

---

Für meinen Geschmack ein Bischen viel Kuddelmuddel. Mir scheint, der gcc will auf Biegen und Brechen Lattice C kompatibel bleiben.

---

Zitat:

---

Ich persönlich fand meinen ursprünglichen Code irgendwie schlüssiger...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Palgucker:
Wohlgemerkt, die anderen Aufrufe von
struct Library *IntBase; bis ...
if (IntBase != NULL) CloseLibrary(IntBase);
wurden nicht geändert.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Es steht nirgends, das das NDK ohne Fehler ist Die Type-Probleme entstehen erst, wenn man die proto/ Header verwendet. Ursprünglich waren die NDK Beispiele nur für SAS/C und verwendeten clib+pragmas ohne "extern base" (wurde da nicht benötigt).

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

Palgucker:
Wohlgemerkt, die anderen Aufrufe von
struct Library *IntBase; bis ...
if (IntBase != NULL) CloseLibrary(IntBase);
wurden nicht geändert.

---

"IntBase" ist dem Compiler völlig egal.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Mad_Dog:

Zitat:

---

gni:
Es steht nirgends, das das NDK ohne Fehler ist ;) Die Type-Probleme entstehen erst, wenn man die proto/ Header verwendet. Ursprünglich waren die NDK Beispiele nur für SAS/C und verwendeten clib+pragmas ohne "extern base" (wurde da nicht benötigt).

---

Wobei in die proto-Header laut Kommentar ursprünglich für Lattice C gedacht waren.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

OMad_Dog:

Zitat:

---

gni:

Zitat:

---

Palgucker:
Wohlgemerkt, die anderen Aufrufe von
struct Library *IntBase; bis ...
if (IntBase != NULL) CloseLibrary(IntBase);
wurden nicht geändert.

---

"IntBase" ist dem Compiler völlig egal.

---

Da gab's aber auch so Schlaumeier, die behauptet haben, der Zeiger müsse zwingend *IntuitionBase heißen, weil in proto/intuition.h ein solcher als globaler Zeiger deklariert ist...

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Wieviel weisst Du über die AmigaOS Programmierung und wieviel von C?

---

Das frage ich mich langsam auch. Nein, Spaß bei Seite. Es ging um den Namen der Zeigervariablen.

Zitat:

---

Der Typ der Variable "IntuitionBase" kann unter bestimmten Bedingungen varieren. Hauptsache es ist ein Zeiger und "passt" zu "struct Libary *". APTR ist so ein Typ. Der _Name_ der Basevariable ist in C _nicht_ egal. Der muß zwingend richtig sein oder es passiert was anderes als Du denkst. Das sich ein Programm trotz falscher Librarybasisname richtig verhält, liegt am automatischen Öffnen von verwendeten Bibliotheken (geht meist nur für die Standardbibliotheken).

---

Schon klar. Es heißt ja auch "ein Zeiger auf etwas von einem bestimmten Datentyp".

Falls noch jemand was an meinem C-Kurs auszusetzen hat, dann können wir das gerne hier ausdisskutieren. Konstruktive Kritik ist immer willkommen.


--

http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 06.04.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]