Compiler bringt Fehlermeldung verkettetet Liste-weshalb?

1

 struct elm {

2

    int i;

3

    double d;

4

    struct elm *next;  //error: two or more data types in decleration specifiers

5

    }

da fehlt ein ;

gurgel schrieb:
> Klassischer Fehler! Etwas verwendet, was fälschlicherweise als
> "Programmiersprache" bezeichnet wird, jedoch zu nichts anderem nutze
> ist, als den "Programmierer" mit Fehlern, abweichenden und nicht
> eindeutigen Implementierungen sowie unwartbarem Code-Wischiwaschi zur
> kompletten Verblödung zu treiben. "C" ist keine Sprache, sondern nur ein
> Krampf im Arsch.

Aha.
Danke für deinen Beitrag, der nur belegt, dass du von Syntaxfehlern und 
wie sie von einem Compiler detektiert werden, nicht den Hauch eines 
Schimmers hast.

in Pascal würde die Fehlermeldung  (sinngemäß)
"da fehlt ein Strichpunkt!" lauten..



also ein Quäntchen Wahrheit steckt schon in gurgels  Aussage ...

edit:
die genau Meldung wäre:

[DCC Fehler] xyz.pas(56): E2029 ';' erwartet, aber 'FUNCTION' gefunden

Ist eben eine andere Syntax.

Dann erklär mal in Pascal jemanden warum bei

   if relation then
     statement1
   else
     statement2;

nach statement1 kein ; kommen darf und sieh dir die Fehlermeldungen an, 
wenn dann doch einer dort ist. Bzw. was das für Auswirkungen auf 
nested-if hat

   if relation1 then
     if relation2 then
       statement1;
   else
     statement2;

Nein: das verschiebt nicht das else zum äusseren if. Das ist ein banaler 
Syntax Fehler. Das else gehört zu gar keinem if mehr. Der ; schliesst 
beide if ab. Und die Fehlermeldung dazu lautet meistens: Else without 
If. Ich hab schon genug Pascal-Anfänger an diesem Problem schier 
verzweifeln sehen.

Edit: Der Punkt ist nicht, ob eine Syntax besser ist als eine andere. 
Der Punkt ist, ob man sein Handwerkszeug, die Programmiersprache 
beherrscht oder nicht. Und wer sie nicht beherrscht sollte sich etwas 
zurückhalten wenn er auf eine Sprache schimpft. Denn letztenendes zeigt 
er damit nur, dass er sie eben nicht beherrscht. Die Fehlermeldung mag 
kryptisch sein (und derartig kryptische Fehlersituationen gibt es in 
jeder Sprache), wenn man aber seine C-Hausaufgaben gemacht hat, dann 
weiß man
* wie es zu einer derartigen Fehlermeldung kommt
* weiß in Zukunft, wonach man suchen muss.

Nicht umsonst haben die üblichen Verdächtigen das Problem in weniger als 
2 Sekunden korrekt diagnostiziert.

@Karl Heinz Buchegger

ich mach (aus diesem und anderen gründen) IMMER ein begin/end

aber NATÜRLICH hat pascal nicht nur vorteile...

Andreas schrieb:
> C Compiler versuchen nun mal krampfhaft, den Rest der Datei hinter einem
> einzelnen Fehler zu interpretieren und schmeißt einen mit
> Fehlermeldungen darüber zu, nur weil irgendwo mal ein ";" fehlt, während
> Pascal das meist sehr genau auf den Punkt bringt und auch noch gezielt
> sagt, woran es hakt.

Nö.
Das ist nicht das Problem.

Das Problem ist, dass C es dir erlaubt an dieser Stelle tatsächlich eine 
Strukturdeklaration zu machen. Bzw. umgekehrt an eine 
Strukturdeklaration gleich Variablen bzw Funktionen mit diesem Datentyp 
zu definieren

struct Point
{
  double X;
  double Y;
} CenterPoint, TrianglePoints[3], MyPoint, *pPoints, PointArray[20];

struct ReturnType
{
  int Code;
  const char* ErrorMessage;
} myFunction( int a, int b, int c );


Das alles ist in C völlig legal. C erlaubt eben viele Dinge und ist 
nichts für Leute, mit denen noch die Tante Lulu gehen muss.
Das C eine kryptische Syntax hat, ist unbestritten. Mit einem einzigen 
falschen Zeichen kannst du aus einem gültigen Programm ein anderes 
gültiges Programm machen, das etwas komplett anderes macht.
Es erlaubt aber auch im Gegenzug elegante Formulierungen, die du so 
nirgends wo anders findest. Und es zeigt auch, dass es wichtig ist, 
seine Sprache von der Pieke auf systematisch zu lernen.

Und letzten Endes liegt es am Programmierer selbst, was er aus den 
Möglichkeiten macht.

>
> Aber ein wahrer C-Programmierer braucht das wohl und ist es auch nicht
> anderes gewohnt.

Für einen wahren C Programmierer ist diese Fehlermeldung überhaupt nicht 
kryptisch sondern 100% auf den Punkt gebracht. Eine Funktion kann nun 
mal keine 2 Datentypen für den Return Wert haben.