Eigene OOP-Sprache

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

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