Eigene OOP-Sprache

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

[otze]

Dr. Prof schrieb:

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.

sicher? abschnitt 5.2.2.8des standards sagt doch ganz klar, dass die reihenfolge der auswertung von parametern nicht festgelegt ist.

[Xin]

otze schrieb:

Dr. Prof schrieb:

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.

sicher? abschnitt 5.2.2.8des standards sagt doch ganz klar, dass die reihenfolge der auswertung von parametern nicht festgelegt ist.

AAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHH!

<stirnklatsch />

"Herr, wirf Hirn vom Himmel!", pflegte einer mein Religionslehrer immer zu sagen - ich weiß auch nicht, warum mir das grade jetzt einfällt.

Also dann... Abschnitt 5.2.2.8 des Standards:
"The order of evaluation of arguments is unspecified. All side effects of argument expression evaluations take effect before the function is entered. The order of the postfix expression and the argument expression list is unspecified."

Zum Mitschreiben, das Kapitel 5.2.2 behandelt Funktionsaufrufe - - das kann man gerne als Operator ansehen, aber selbst dann liefert der ()-Operator keine Aussage zum &&-Operator!

Was da steht: Wenn Du eine Funktion so aufrufst,

int a = 0;

func( a++, a++, a++ );

heißt das, dass Dir niemand garantiert, was da übergeben wird.

Du kannst

func( 0, 1, 2 );

da stehen haben, oder auch

func( 2, 1, 0 );

und folgendes habe ich auch schon gesehen:

func( 0, 0, 0 );

Aber das hat definitiv nix mit der Reihenfolge von && zu tun - falsches Kapitel! Wenn Du den Standard für Deine Argumentation herziehst, BITTE LIES IHN! Und zwar bei Kapitel 5.14.1.

Dort steht geschrieben "The && operator groups left-to-right. The operands are both implicitly converted to type bool. The result is true if both aperands are true and false otherwise. Unlike &, && garantees left to right evaluation: the second operand ist not evaluated if the first operand is false."

Also ist mein 'Wächter' vom C++-Standard geprüft und zertifiziert und damit absolut sicher - nichts zu rütteln und - zumindest aus sicht des Standards - auch nichts Verwerfliches dran.

Aber hey, wenn Du jetzt noch eine Quelle herzaubern kannst, die den C++-Standard widerlegt, dann zieh ich echt den Hut - schließlich wächst man an seinen Herausforderungen.
Im schlimmsten Fall hast Du grade gelernt, wie && funktioniert und dass Du Argumente besser prüfen solltest. Also alles halb so wild.

[Ben04]

5.2.2.8 schrieb:

The order of evaluation of arguments is unspecified. All side effects of argument expression evaluations take effect before the function is entered. The order of evaluation of the postfix expression and the argument expression list is unspecified.

Da wir hier aber keine Funktion oder Argumente haben wir diese Regel gar nicht angewant.

1.8.19 schrieb:

Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

Interessant ist nun zu wissen, dass

1.8.18 schrieb:

In the evaluation of each of the expressions
a && b
a || b
a ? b : c
a , b
using the builtin meaning of the operators in these expressions (5.14, 5.15, 5.16, 5.18), there is a sequence point after the evaluation of the first expression

Dies heißt, dass a ganz ausgewertet sein muß bevor b ausgewertet werden darf.

5.14.1 schrieb:

The && operator groups lefttoright. The operands are both implicitly converted to type bool (clause 4). The result is true if both operands are true and false otherwise. Unlike &, && guarantees lefttoright evaluation: the second operand is not evaluated if the first operand is false.

Dies heißt, dass wenn a false ist b nicht mehr ausgewertet werden darf und wegen der vorher genannten Regel darf b auch keine Seiteneffekte haben.

Beim fraglichen Code handelt es sich um standardkonformen Code.

[GPC]

Ihr streitet euch jetzt aber nicht ernsthaft darüber, ob C bzw. C++ Short Circuit Evaluation hat, oder?

[Gast123]

volkard schrieb:

alle bereits definierten funktionen auch zur compilezeit ausführen können und schreibenden zugriff auf den parse-baum und die symboltabelle haben.

Sorry fürs thread recycling aber da ich gerade selber an einer eigenen Sprache arbeite wollte ich doch mal fragen wofür das mit dem Zugriff auf den ParserBaum bzw die Symboltabelle gut sein soll.
Persönlich würde mir da nichts vernünftiges einfallen.

MFG
MadMax

[Xin]

Gast123 schrieb:

volkard schrieb:

alle bereits definierten funktionen auch zur compilezeit ausführen können und schreibenden zugriff auf den parse-baum und die symboltabelle haben.

Sorry fürs thread recycling aber da ich gerade selber an einer eigenen Sprache arbeite wollte ich doch mal fragen wofür das mit dem Zugriff auf den ParserBaum bzw die Symboltabelle gut sein soll.
Persönlich würde mir da nichts vernünftiges einfallen.

Bereits definierte Funktionen zur Compilezeit auszuführen gibt es schon, läuft unter Metaprogrammierung (als Templates) oder Optimierung (als Aufgabe des Compilers).

Schreibenden Zugriff auf den Parserbaum, hat zwangsläufig jede kompilierende Programmiersprache, da sie nach dem Syntax-Check dafür verantwortlich ist, den Parserbaum anzulegen.
Um den Syntaxbaum während des Compilierens zu ändern bräuchte man eine mehrschichtige Programmiersprache, ähnlich des Präprozessors (der aber den Compilerbaum nicht ändern kann, wohl aber die Daten, die den Compilerbaum aufbauen) und der eigentlichen zu übersetzenden Sprache C/C++.

Zumindest bei meinem Compiler ist es so, dass der Parserbaum als korrekt garantiert wird - dafür sorgt der syntaktische und semantische Prüfung. Den "User" darin rumpfuschen zu lassen, würde bedeuten, dass der Codegenerator erst den Parserbaum nochmals syntaktisch und semantisch prüfen müsste, da ein nachträglich eingefügtes "break" in den Then-Part einer if-Abfrage dem Codegenerator zu undefinierten Verhalten verführen würde. Hier wäre wohl eher eine Art "inline" zur Kompilierzeit gefragt, was der Präprozessor ja leisten kann.
Irgendwann muss man sich ja festlegen und sagen: "Das ist, was ich kompiliert haben möchte."

Kurz: Der Zugriff auf Symboltabelle und Parserbaum ist "nur erstellend" erlaubt, aber nicht modifizierend, ansonsten würde vermutlich ein interessantes Chaos ausbrechen ;->
Was Du, Volkard oder ich in eigenen Sprachen erstellen, ist natürlich jedem selbst überlassen. Als experimentelle Sprache finden sich vielleicht auch dafür Anwendungen!?

Vielleicht meinte Volkard auch Reflection!?

<neugier>Gibt's zu Deiner Sprache eine Projektseite?</neugier>

[Gast]

Beschreibt Volkard nicht einfach nur prozeduale Makros?