BLOCK:
{
// do stuff
if( someCondition )
{
break BLOCK;
}
// more code
}
// wee, BLOCK exited prematurely!
könnte es denn sonst kompilieren?
Es wird praktisch nirgends verwendet. Habe nie im Leben ein Stück "echten" code gesehen, wo sowas angewandt wurde. Da das verhalten ähnlich verwirrend wie bei GOTO ist, sollte man dieses konstrukt vermeiden bzw. 20 mal überlegen, bevor man es einsetzt (an dieser Stelle sollte maki auftauchen, und sagen, dass man da nichts zu überlegen braucht, und dass diese labels absolut verboten gehören 😉 , es gab schon 2-3 megalange philosophische Threads zu diesem Thema, fazit: "lass es lieber")
Wenn es nicht so vorgesehen wäre, würde es ja nicht gehen 😉
ich glaube nicht an die unfehlbarkeit von compiler implementierungen 😉
bei java glaube ich dran. So abgefahren ist die Syntax ja nicht, es wär schon längst jemanden was aufgefallen... :bahnhof:
Plötzlich nicht mehr... was? Der IBM Compiler arbeitet korrekt, oder kannst du ein Gegenbeispiel nennen?
ehrlich gesagt ist da eclipse das einzige beispiel, das ich nennen kann. und dabei speziell die mit java 1.5 eingeführten enums. die eclipse jungs haben offensichtlich die initialisierungsreihenfolge bei enums anders gelöst, als sun, weshalb die jdk compiler "eclipse" code u.U. nicht mehr mochten.
ok, also das MUSS ich jetzt noch erwähnen: MSVC 6.
Da du einem Sun Compiler kein Compilat fütterst, sondern Quelltext, macht das so keinen Sinn. Da musst du jetzt aber schon ein sehr konkretes Beispiel auf den Tisch pflanzen, das ich dir abnehme, das der IBM Compiler ein Programm akzeptiert, das der Sun Compiler nicht akzeptiert, sofern Compliance Level, Java Version, Compiler Flags,... identisch waren.
public enum Foo
{
BLARGH( 0 );
private static List<Integer> values;
private Foo( int value )
{
if( values == null )
{
values = new ArrayList<Integer>();
}
values.add( Integer.valueOf( value ) );
}
}
