[Progra] Methoden beenden

[O.D.]

Das ist Absicht, da Programmierer gerne if(true) und while(false) benutzen.

Ok, dann nehm ich alles zurück und behaupte das Gegenteil.

[thana]

Oh man ...
ich hatte gedacht Java sein ein klein wenig schlauer als das.

Wieso zur Hölle sollte der Compiler das denn evaluieren?
*kopfschüttel*

[MaoDelinSc]

Und wieso sollte man überhaupt etwas von der Form

{
Anweisung
return;
weitere Anweisung
}

machen? Die weitere Anweisung ist doch eh überflüssig, da diese niemals ausgeführt wird...

Stattdessen also

{
Anweisung
if (true) return;
weitere Anweisung
}

zu schreiben, mag der Compiler vll kapieren, aber es ist doch sinnlos, oder nicht? Die weitere Anweisung wird ja eh niemals erreicht, von daher kann man sie ja auch einfach weglassen oO

Und wenn's zu Testzwecken ist, kann man ja auch // davorsetzen, geht eh viel schneller als ein if (true) return; dazwischenzuschreiben...

[C-Otto]

Ein while(false) hat den Vorteil, dass im eingeschlossenen Block auch Kommentare stehen koennen. Genestete Kommentare sind sonst problematisch.

[O.D.]

Ein while(false) hat den Vorteil, dass im eingeschlossenen Block auch Kommentare stehen koennen. Genestete Kommentare sind sonst problematisch.

Jap. Außer in D, da gibt es schachtelbare Kommentare:

Code: Alles auswählen

ich bin code
/+
ich bin ein kommentar
/+
ich auch
+/
und ich auch
+/
ich bin wieder code

Und ich bin D Fan

P.S.: Frohes Fest.

[Coolcat]

Genestete Kommentare sind sonst problematisch.

Dann nimmt man halt einen Editor der damit umgehen kann. Beispielsweise KWrite kann das, einfach ein paar Zeilen markieren und Strg+D bzw. Shift+Strg+D drücken.

Ansonsten wird es erst richtig schön wenn man bedingte Kommentare in Java benutzt. In C++ kann man ja einfach sowas wie #ifdef DEBUG .... #endif schreiben, in Java muss man halt explizit vorher einen Präprozessor laufen lassen... Ich benutzte das beispielsweise um JUnit Code ein- oder eben nicht einzubinden. So läuft in der Release-Version kein unnötiger Ballast mit.

Sieht hässlich aus und ist auch so beabsichtigt:

Code: Alles auswählen

/* GNU M4 macro processor statement: DO NOT CHANGE THIS COMMENT!
   M4_SHOWCODE(`M4_JUNIT',`SHOW') */
import org.blablubb.JUnitRunner;

//...

JUnitRunner.run();      
/* M4_ENDCODE */

Mein Skript für den M4 sieht so aus:

Code: Alles auswählen

m4_define(`M4_SHOWCODE',`m4_ifdef(`$1',`m4_ifelse(`$2',`SHOW',``M4_SHOWCODE(`$1',`SHOW')'',``M4_SHOWCODE(`$1',`SHOW') */'')',`m4_ifelse(`$2',`SHOW',``M4_SHOWCODE(`$1',`HIDE')'
m4_dnl',``M4_SHOWCODE(`$1',`HIDE') '')')')
m4_define(`M4_HIDECODE',`m4_ifdef(`$1',`m4_ifelse(`$2',`SHOW',``M4_HIDECODE(`$1',`HIDE')'
m4_dnl',``M4_HIDECODE(`$1',`HIDE') '')',`m4_ifelse(`$2',`SHOW',``M4_HIDECODE(`$1',`SHOW')'',``M4_HIDECODE(`$1',`SHOW') */'')')')

M4 hat ne richtig widerliche Sprache...aber den Präprozessor hatte ich halt gerade zur Hand. Das ganze macht nichts anderes als das */ in der zweiten Code Zeile zu entfernen bzw. wieder einzufügen.

zum Ausführen nimmt man ein kleines Bash-Skript:

Code: Alles auswählen

m4 -P -F $SCRIPTSDIR/macro.m4f $SCRIPTSDIR/macro.m4
m4 -P -R $SCRIPTSDIR/macro.m4f -DM4_JUNIT <$sourcefile >$sourcefile.tmp
mv -f $sourcefile.tmp $sourcefile

[user]

Ist zwar schon länger her, dass ich das benutzen musste, aber ich glaube mich zu erinnern, dass die Compiler auch bei

Code: Alles auswählen

if (true) return;


Gemeckert hat. Was dafür damals(TM) funktioniert hat war

Code: Alles auswählen

if (1 != 0) return;


Vermutlich bekommt das Java-Codeoptimizer da 'ne Exception weil sie nicht genug Heapmemory hat.