Eigene OOP-Sprache

[Xin]

GPC schrieb:

Xin schrieb:

Hier mal ein Beispiel, wo C nicht eindeutig ist:

if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4

Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.

Ich würde noch weiter gehen und sagen, du beginnst mit /* nen Kommentar und kriegst deshalb n Haufen Probleme

Nimm den Leuten doch nicht den Spaß, ich habe extra dahinter geschrieben, was passieren sollte, damit nicht gleich die Warnlampen angehen, wenn man /* liest. */

[GPC]

hrhrhr, alter Halunke

[Kenner es Forums]

das topic ist im falschen forum und bittet um verschiebung

[groovemaster]

Programmiererer schrieb:

Also eine Idee wäre es von mir schon mal die ganzen variablentypen wegzulassen, dass es php ähnlich wird.

Ganz schlechte Idee. Damit nimmst du der Sprache einen Teil des anwendbaren Spektrums und machst daraus eine limitierte Sprache. Das würde sich wohl kein (zumindest C++) Programmierer wünschen. Aber du hast Recht, wenn es um Typ Automatisierung geht. Da gibt es durchaus noch Spielraum für Verbesserungen und solche werden im nächsten C++ Standard wohl auch kommen.

thordk schrieb:

ich sehe eigentlich keinen trifftigen grund, der gegen schwache typisierung spricht.

Ich schon. Dann würden wohl noch mehr Dummies C++ programmieren, ohne auch nur die leiseste Ahnung von Softwareentwicklung zu haben. Die Welt würde zugrunde gehen und das Armageddon kommen. Gute Nacht!

thordk schrieb:

c++ ist steinzeit.

Naja, höchstens Antike, wenn wir mal die Entstehungszeit betrachten.

thordk schrieb:

um jeden scheiss muss man sich selbst kümmern, nicht mal der müll wird einem vor die tür gebracht!

Und warum ist das die Schuld von C++, wenn du nicht vernünftig damit umgehen kannst?
In C++ musst du sicherlich mehr machen, als in einigen anderen Sprachen. Allerdings ist vieles davon einfach eine Frage der Routine.

volkard schrieb:

thordk schrieb:

es erschwert natürlich die analyse und ist fehleranfällig. aber mal ehrlich, wieviele speicherlecks und potentielle segmentation fault quellen hat das durchschnittliche c++ programm?

keine.

Aber auch nur deine Programme. Die Realität sieht leider anders aus. Grundsätzlich hast du aber Recht, ein C++ Programm muss keine Speicherlecks oder Segfaults haben.
Deinen Wunsch mit den Compilezeitfunktionen habe ich mir übrigens auch schon manchmal gewünscht. Eigentlich müsste die Sprache es lediglich ermöglichen, dass man Compilezeitkonstanten als Parameter und Rückgabewert definieren kann. const reicht dafür ja nicht aus.

Grundsätzlich glaube ich nicht, dass ein Nachfolger von C++ Sinn machen würde (tut ja eigentlich auch D schon nicht wirklich). Warum? Nun, der eine definiert es zu low-level, der andere zu high-level. Letztendlich ist keiner damit wirklich zufrieden. Ist ja jetzt auch schon nicht anders. Warum gibt es denn so viele Programmiersprachen? Weil jeder andere Anforderungen hat, und jeder glaubt, seine Sprache könnte das am besten. Deshalb gibt es auch nicht _die_ eierlegende Wollmilchsau bei den Programmiersprachen. Und wie Xin schon sagte, was die Zukunft bringt, können wir sowieso nicht voraussagen. Also bleibt uns nur, mit dem zu leben was wir haben (im Grunde gibt es ja auch alles). Und wer das am besten kann, anstatt jedes belanglose Detail im Einzelnen niederzumachen (nein, ich nenne keine Namen ), hat einfach die grössten Chancen, was auf die Reihe zu bekommen. Der Rest fällt früher oder später einfach durchs Sieb.

Zudem würde ich diese Diskussion nur für sinnvoll halten, wenn man sie in zwei Bereiche teilt. Die einen definieren ihre OOP Sprache für low-level, die anderen für High-level. Beides gleichzeitig ist in einfacher Form einfach nicht möglich.

Wenn ich einen Nachfolger von C++ dennoch entwickeln würde, dann wäre das wohl C++ ... mit vielen Verbesserungen im Detail (Kontrollstrukturen, dynamische Speicherreservierung, Literale, builtin Container, etc.pp) und Erweiterungen (zB hat aspektorientierte Programmierung einige gute Ideen). Den Kern würde ich trotzdem beibehalten, wie OO, strikte und statische Typisierung, kein GC (höchstens optional), native Binaries, usw.

[Dr. Prof]

Xin schrieb:

Hier mal ein Beispiel, wo C nicht eindeutig ist:

int a = 8, b = 2;
int *p = &b;                           // Zeiger p zeigt auf Variable b

if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4
else            printf( "Nopes\n" );

Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.

Wer sauber formatiert codet länger (anstatt fehler zu beheben)

[Helium]

groovemaster schrieb:

Wenn ich einen Nachfolger von C++ dennoch entwickeln würde, dann wäre das wohl C++ ... mit vielen Verbesserungen im Detail (Kontrollstrukturen, dynamische Speicherreservierung, Literale, builtin Container, etc.pp) und Erweiterungen (zB hat aspektorientierte Programmierung einige gute Ideen). Den Kern würde ich trotzdem beibehalten, wie OO, strikte und statische Typisierung, kein GC (höchstens optional), native Binaries, usw.

Zitier bitte mal kurz, wo vorgeschrieben sein soll? (ich beziehe mich auf das fett markierte).

[groovemaster]

Wozu? Ausserdem habe ich solch eine Sprache ja nirgendwo spezifiziert, also kann ich dir auch schlecht Textstellen zitieren.

[Helium]

Du hast geschreiben, dass wenn du einen C++-Nachfolger erfinden würdest du den Kern beibehalten würdest. Da nichts anderes genannt wurde, war der Kern von C++ gemeint. Dann hast du das aufgezählt, was für dich den Kern von C++ ausmacht und darunter befand sich unter anderem "native Binaries". Für dich sind native Binarys also ein Teil des Kerns von C++. Da ich das nicht wusste, bzw. sogar für falsch halte, wollte ich, dass du mir sagst, wie du darauf kommst, dass es ein Teil des Kerns von C++ ist.

So, noch ausführlicher kann ich das jetzt aber nicht mehr ausführen. Sollte es immer noch Missverständnisse geben, gebe ich auf.

[groovemaster]

OK, dann akzeptiere ich deine Aufgabe. Ausser du kannst uns nachweisen, dass C++ eine rein interpreterbasierte Sprache ist.

Aber mal Spass beiseite. Verwechsel mal das, was ich unter "Kern" meinte, nicht mit dem was im Standard geschrieben steht. Damit war das komplette Spektrum von C++ gemeint. Eben nicht nur die reine Sprachspezifikation, sondern auch die Merkmale von C++. Wenn es dem OP nur um das Erste geht, dann vergiss den Punkt einfach. Aber ich würde mir dennoch Gedanken darum machen, wie der Quellcode letztendlich auch ausgeführt werden kann. Und da muss es in erster Linie Build Tools geben, die den Quellcode in Maschinensprache (oder andere "native" Sprachen, wie zB C) übersetzen können. Wenn du dir darüber hinaus einen Interpreter selber basteln willst, dann kannst du das gerne machen. Das darf aber keine Voraussetzung für die Lauffähigkeit der Anwendungen sein.

[Xin]

Dr. Prof schrieb:

Xin schrieb:

Hier mal ein Beispiel, wo C nicht eindeutig ist:

int a = 8, b = 2;
int *p = &b;                           // Zeiger p zeigt auf Variable b

if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4
else            printf( "Nopes\n" );

Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.

Wer sauber formatiert codet länger (anstatt fehler zu beheben)

Dem stimme ich zu, aber das Programm ist sauber formatiert und kann trotzdem nicht kompiliert werden.

[Dr. Prof]

Xin schrieb:

Dr. Prof schrieb:

Xin schrieb:

Hier mal ein Beispiel, wo C nicht eindeutig ist:

int a = 8, b = 2;
int *p = &b;                           // Zeiger p zeigt auf Variable b

if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4
else            printf( "Nopes\n" );

Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.

Wer sauber formatiert codet länger (anstatt fehler zu beheben)

Dem stimme ich zu, aber das Programm ist sauber formatiert und kann trotzdem nicht kompiliert werden.

Ist es nicht, sauber formatiert ist:

int a = 8;
int b = 2;
int* p = &b;                           // Zeiger p zeigt auf Variable b

if( a / *p == 4 ) 
   printf( "Yepp\n" );    
else  
   printf( "Nopes\n" );

[Dr. Prof]

Und in echtem Code, sollte man noch die If- und Else-Zweige Klammern.

[Swordfish]

int a = 8;
int b = 2;
int* p = &b;                           // Zeiger p zeigt auf Variable b

if( a / *p == 4 )
   printf( "Yepp\n" );    
else  
   printf( "Nopes\n" );

ist es nicht:

int     a =  8;
int     b =  2;
int*    p = &b;

if( a / *p == 4 ) {
    printf( "Yepp\n" );    
} else {
    printf( "Nopes\n" );
}

@Mods: Könnte mal jemand diesen unsinnigen Thread schließen

[Dr. Prof]

Swordfish schrieb:

int a = 8;
int b = 2;
int* p = &b;                           // Zeiger p zeigt auf Variable b

if( a / *p == 4 )
   printf( "Yepp\n" );    
else  
   printf( "Nopes\n" );

ist es nicht:

int     a =  8;
int     b =  2;
int*    p = &b;

if( a / *p == 4 ) {
    printf( "Yepp\n" );    
} else {
    printf( "Nopes\n" );
}

@Mods: Könnte mal jemand diesen unsinnigen Thread schließen

Dr. Prof schrieb:

Und in echtem Code, sollte man noch die If- und Else-Zweige Klammern.

[Xin]

Wohlwissend, dass ein Reply hier sinnlos ist... ich probier's trotzdem mal für diejenigen, die den Unsinn hier noch lesen.

Was "sauber formatiert" bedeutet ist eine Auslegungssache. Hier gibt es Unmengen an Richtlinien - an die man sich richten kann - nicht muss, es gibt aber kein Gesetz und es gibt keine Festlegung.
Auch gilt das Bild-Zeitungs-Prinzip nicht: Wenn's häufig genug geschrieben wird, wird es wahr. Wer das glaubt, möge ich fragen, warum auch neuere Sprachen wie Java oder C# die Klammerung nicht verlangen - vielleicht lasen die Entwickler andere Blätter.

Es gibt kein Gesetz, das besagt, dass Zweige mit einem Statement geklammert werden müssen. Es gibt Leute (mich eingeschlossen), die auf Klammerung weitestgehend verzichten möchten, solange die Aussage eindeutig ist.
Ich klammere möglichst wenig, aber ich klammere auch dann, wenn es für die Aussage an den Compiler überflüssig ist, aber den Code lesbarer macht.
Die Formatierung, die ich in dem Beispiel benutzt habe, benutze ich ebenso in "richtigem" Code.

Der Hinweis, Klammern grundsätzlich zu nutzen, geht in der Regel an Anfänger, die nicht automatisch Klammern setzen, wenn sie in einen ungeklammerten Anweisungsblock mit nur einer Anweisung einen Befehl einsetzen.

Folgendes

if( true )
  do_this();
  do_that();

do_something_else()

ist ein Fehler, der einem erfahrenen (C/C++)-Entwickler nicht passieren kann (auch das ist kein Gesetz... ich weiß).
Mir ist auch bewußt, dass das Risiko für Python-Prgrammierer hier höher ausfällt. Wenn ein Python-Programmierer grundsätzlich klammert, um einen Fehler durch Gewöhnung auszuschließen, dann finde ich das vollkommen in Ordnung. Denn die Klammern machen den Quelltext auch nicht falscher. Es ist also allgemein vollkommen in Ordnung zu klammern.
Es wird dadurch nicht sauberer oder richtiger oder in irgendeiner Weise besser - der Quellcode hat lediglich mehr Klammern.

Formatierung sollte nicht starren Linien folgen, sondern die Formatierung sollte so sein, dass der Quelltext und vor allem der Algorithmus leicht lesbar und nach Möglichkeit erkennbar ist, wenn man den Code durchgeht. Ähnlichkeiten und Unterschiede sollten im Code durch die Formatierung hervorgehoben werden. Die Unterschiede sollen einem regelrecht ins Auge springen, damit man weiß, worauf man seine Konzentration zu lenken hat. Es geht nicht darum den Parserbaum optimal im Code darzustellen, sonst würden wir statt Quellcodes Parserbäume schreiben.

if( foo ) bar = new Object( "neues Objekt",       1, "kleine Zahl" );
else      bar = new Object( "neues Objekt", 1000000,  "große Zahl" );

Man kann und sollte Richtlinien aufstellen. Aber keine davon sollte zwingend angewendet werden, wenn sie den Code nicht wirklich leserlicher macht.
Man kann bei der Formatierung auch überlegen, was an dieser Stelle wichtig ist - aber auch das ist kein Gesetz, sonst hätten wir weniger Brute-Force-Programmierer.

[Dr. Prof]

Ich würde dir trotzdem zur Klammerung raten, wie du selbst zugibst können dann Fehler durch mehrere Anweisungen gar nicht erst entstehen. Und die schleichen sich auch beim guten Programmierer mal ein, wenn man total übermüdet vorm PC sitzt.

Außerdem ist dann der Programmfluss eindeutig, denn wer die Klammern weglässt hat bei folgendem ein Problem (fällt euch jetzt natürlich sofort auf, aber da sitzt man auch ne Weile wenn man das in echtem Code sieht (hab ihn etwas gekürzt):

if( msg == WM_ACTIVATE )
	if( LOWORD( wparam ) == WA_INACTIVE )
		if( windowRefs[ wnd ] )
			( windowRefs[ wnd ] )->deactivate();
	else
		if( sWindowRefs[ wnd ] )
			( windowRefs[ wnd ] )->activate();

Dieser Auszug hat mich im Übrigen auch dazu veranlasst in echtem Code strikt die Klammern einzufügen.

[Xin]

Dr. Prof schrieb:

Ich würde dir trotzdem zur Klammerung raten, wie du selbst zugibst können dann Fehler durch mehrere Anweisungen gar nicht erst entstehen. Und die schleichen sich auch beim guten Programmierer mal ein, wenn man total übermüdet vorm PC sitzt.

Das ist eine für mich übliche Arbeitshaltung - leicht zur rechten Seite umkippend weil ich seit 20 Stunden programmiere. Kippt der Bildschirm mehr als 45° nach links, wird's definitiv Zeit für's Bett.
Ich bin kein guter Programmierer, diese Fehler schleichen sich nämlich auch dann bei mir nicht ein.
Ein guter Programmierer kann das im Schlaf. Da habe ich allerdings noch keine Erfahrung mit.

Dr. Prof schrieb:

Außerdem ist dann der Programmfluss eindeutig, denn wer die Klammern weglässt hat bei folgendem ein Problem (fällt euch jetzt natürlich sofort auf, aber da sitzt man auch ne Weile wenn man das in echtem Code sieht (hab ihn etwas gekürzt):

if( msg == WM_ACTIVATE )
	if( LOWORD( wparam ) == WA_INACTIVE )
		if( windowRefs[ wnd ] )
			( windowRefs[ wnd ] )->deactivate();
	else
		if( sWindowRefs[ wnd ] )
			( windowRefs[ wnd ] )->activate();

Dieser Auszug hat mich im Übrigen auch dazu veranlasst in echtem Code strikt die Klammern einzufügen.

Das hier finde ich dann doch etwas arg billig.
1. Wer den falschen Algorithmus schreibt, hat aus Prinzip ein Problem. Es heißt "Bug".
2. Das Beispiel gehört in jede Ausbildung für einen Programmierer, damit er weiß, wo er klammern muss.
Auch diesen Fehler mache ich quasi nicht. (ca. alle 2 Jahre kommt er doch mal vor und kostet mich 5 Minuten. Dafür habe ich in der Restzeit lesbareren Quelltext).

Wer programmieren kann, kennt die Fallgruben - ansonsten kann er nicht programmieren oder befindet sich noch in der Ausbildung.
Ein guter Programmierer weiß, wo ein Sicherheitsgitter erforderlich ist, denn er sollte wissen, wo sie nicht erforderlich sind, um überflüssige Abfragen wegzulassen. Ein guter Ausbilder weiß die Fallgruben zu vermitteln.

Wer ifs verschachtelt weiß, dass er auf korrekte Verschachtelung zu achten hat. Wer nicht weiß, was er tut, sollte keine verantwortungsvollen Tätigkeiten übernehmen.

Das Beispiel ist in zweierlei Hinsicht falsch, da es nicht nur dem widerspricht, was der Autor programmieren möchte (was ja passieren kann, schließlich gibt es Bugs), sondern sowohl meiner Formatierung, als auch Deiner Formartierung. Wer es als guter Programmierer schafft gegen Wissen - denn das Wissen um die Verschachtelung von ifs erwarte ich von einem 'guten' Programmierer - UND gegen die Formatierung zu verstoßen... der muss schon unglaublich gut sein ;->

Nebenher bietet sich der Code an, vereinfacht zu werden, da hier mehr Code steht, als erforderlich ist - was die Lesbarkeit negativ beeinflusst - unter der Annahme, dass sWindowRefs ein Tippfehler ist, sonst würde die anschließende Dereferenzierung nämlich nicht sicher sein, obwohl sie im ersten Fall noch geprüfen wurde.
In diesem Fall enthält Dein Code eine Redundanz, die schnell offensichtlich wird, wenn man sie anders schreibt:

if( msg == WM_ACTIVATE ) if( LOWORD( wparam ) == WA_INACTIVE ) if( windowRefs[ wnd ] ) ( windowRefs[ wnd ] )->deactivate();
                         else                                  if( sWindowRefs[ wnd ] ) ( windowRefs[ wnd ] )->activate();

Hier sieht man a) den Tippfehler sehr schön und b) es stehen zwei if's direkt untereinander. In meiner Formatierung SCHREIT DAS NACH EINEM FEHLER!!! Mit den Tippfehlern schreit sich die Formatierung sogar heiser, den hier verrutscht etwas, was eigentlich gleichförmig untereinander stehen müsste. Also weg mit den Syntax-Fehler und her mit dem Konzept-Fehler:

if( msg == WM_ACTIVATE ) if( LOWORD( wparam ) == WA_INACTIVE ) { if( windowRefs[ wnd ] ) ( windowRefs[ wnd ] )->deactivate(); }
                         else                                  { if( windowRefs[ wnd ] ) ( windowRefs[ wnd ] )->activate();   }
                                                                 ^^^^^^^^^^^^^^^^^^^^^^^                                         // REDUNDANT!!! (== Böse!)

Redundanzen sind im Code eigentlich überflüssig und häufig das Zeichen von Copy'n'Paste-Programmieren. Die haben meist noch ganz andere Probleme als nur Klammern zu übersehen, da Copy'n'Paste ein sehr großes Fehlerpotential hat. Gute Programmierer vermeiden jede Form von Redundanz (und halten sich bei C'n'P deutlich zurück).
Die Klammer um windowRefs[ wnd ] wirkt auf mich ebenfalls verwirrend, weil ein Array-Zugriff ist doch nix besonderes, soweit ich das einschätze.
Also weg damit.

if( msg == WM_ACTIVATE && windowRefs[ wnd ] )
  if( LOWORD( wparam ) == WA_INACTIVE ) windowRefs[ wnd ]->deactivate();
  else                                  windowRefs[ wnd ]->activate();

Mit kommt hier noch in den Sinn, eine lokale Variable für windowRef[ wnd ] zu nutzen, da hier der Array-Zugriff auch doppelt geschieht (und dreimal im Code auftaucht). Aber das regelt der Compiler sicher für Dich.

Weniger Text, kein Problem mit der Verschachtelung, man sieht die Unterschiede deutlicher und der Code ist identisch mit Deiner Vorgabe (bis auf meine Korrektur ).
Wofür der Code überhaupt zuständig ist, springt einem regelrecht ins Auge. Es sticht wörtwörtlich heraus - und zwar rechts.

Solltest Du an die äußere Bedingung ein else ansetzen wollen, musst Du - was Du als guter Programmierer - sicherlich weißt, überlegen, ob Du an die gesammte Bedingung ein "else" ansetzen möchtest, oder nur an einen Teil, so dass Du die Bedingung wieder aufspalten müsstest und ggfs. Klammern.
Aber als guter Programmierer setzt man auch nicht einfach mal ungeprüft irgendwo ein "else" dran - oder?

Obwohl mir der letzter(EDIT: gemeint ist der hier drüber stehende, nicht der letzte in diesem Posting) Codeschnipsel am besten gefällt, könnte Dir die Umstellung des Codes nicht gefällen. Ich müsste damit zwar die Redundanz drinlassen, aber man könnte die Sache dann auch damit klären, indem man das if vermeidet, welches das 'else' (bzw. den guten Programmierer verwirrt) und stattdessten per && einen 'Wächter' platzieren - sofern activate() und deactivate() keine void-Funktionen sind - aber das wäre schon wieder ein Griff in die Truhe mit der bösen Magie...

if( msg == WM_ACTIVATE )
  if( LOWORD( wparam ) == WA_INACTIVE ) windowRefs[ wnd ] && windowRefs[ wnd ]->deactivate();
  else                                  windowRefs[ wnd ] && windowRefs[ wnd ]->activate();

Außerdem glaube ich, dass der GNU C++-Compiler da inzwischen verwirrt drauf reagiert, da man einen Operator anwendet, der kein Funktionsaufruf ist, und dessen Ergebnis trotzdem nicht ausgewertet. Die V4 meldet da vermutlich Warnings.

[otze]

if( msg == WM_ACTIVATE )
  if( LOWORD( wparam ) == WA_INACTIVE ) windowRefs[ wnd ] && windowRefs[ wnd ]->deactivate();
  else                                  windowRefs[ wnd ] && windowRefs[ wnd ]->activate();

interessant ist, dass der codeschnipsel den du am besten findest auf undefiniertem verhalten aufbaut.

wenn der erste operand des op&& false ist, heisst dies nicht, dass der zweite ausdruck nicht ausgeführt wird. Dies kann sein, muss aber nicht.

//edit es ist nichtmal sichergestellt, dass der erste operand vor dem zweiten berechnet wird

[Xin]

otze schrieb:

if( msg == WM_ACTIVATE )
  if( LOWORD( wparam ) == WA_INACTIVE ) windowRefs[ wnd ] && windowRefs[ wnd ]->deactivate();
  else                                  windowRefs[ wnd ] && windowRefs[ wnd ]->activate();

interessant ist, dass der codeschnipsel den du am besten findest auf undefiniertem verhalten aufbaut.

Mißverständnis. Der letzte Codeschnipsel an der Stelle, wo ich das schrieb. So ist das gemeint.

otze schrieb:

wenn der erste operand des op&& false ist, heisst dies nicht, dass der zweite ausdruck nicht ausgeführt wird. Dies kann sein, muss aber nicht.

//edit es ist nichtmal sichergestellt, dass der erste operand vor dem zweiten berechnet wird

Deine Quelle?

Ich habe zwar derzeit auch keine Quelle, jedoch bin ich zumindest zu 99,9% überzeugt, derartiges mal gelesen zu haben, dass es schön brav von links
nach rechts ausgeführt wird und - in C - der rechte Operant auch nur, wenn links true ergibt.
In Pascal ist es nämlich nicht so, da wird auch der zweite Operant durchgeführt, was vor 10 Jahren noch in regelmäßigen, weniger interessanten Diskussionen zwischen Pascal-Jüngern und C-Anhängern endete.
Was besser ist, ist dabei erstmal egal - in C war es jedenfalls so, dass aufgehört wurde, sobald die Bedingung nicht mehr wahr werden konnte.

Weiterhin würde es keinen Sinn machen, wenn && in der beliebiger Reihenfolge ausgeführt würde, denn es würde Konstrukte wie

if( a != NULL && a->b != NULL && a->b->c == 4 ) 
  printf( "Yepp" );

zu undefinierten Verhalten erklären. Und bevor ich das glaube, hätte ich doch gerne eine Quelle.

[Dr. Prof]

Der Tippfehler hat sich beim kürzen eingeschlichen.
Wie gesagt im Original ist es etwas anders, habe es nur reduziert auf den wesentlichen Fehler.
Und die Ausführungsreihenfolge von || und && ist festgelegt.