Unreachable code- Meldung. Warum?

[anmerkung]

GPC schrieb:

Kenner des Problems schrieb:

Mit C++ wär das nicht passiert.

Stimmt, du hättest das Problem erst beim Testen entdeckt...

Troll

[Sgt. Nukem]

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

[Roman007]

danke für die Hilfe,
ist mir nicht aufgefallen,dass der Fehler wegen der Schleife kommt.
Ich dachte, hat was mit dem InputStream zu tun, weil der Compiler an der Stelle anhält
Es war nur ein versuch, so etwas zu programmieren.
Eigentlich will ich ein Applet programmieren, der vom Server (in c++ geschrieben) die Simulationsdaten kontinuerlich empfängt.

Hat jemand passenden Code für einem Client, der nach dem Verbindungsaufbau in der Schleife die Daten empfängt, und sich terminiert, wenn Applet geschlossen wird?

Grüße

[Gregor]

anmerkung schrieb:

GPC schrieb:

Kenner des Problems schrieb:

Mit C++ wär das nicht passiert.

Stimmt, du hättest das Problem erst beim Testen entdeckt...

Troll

Warum Troll? Ich habe es gerade mit dem g++ ausprobiert. Der kompiliert ein Codestück wie das folgende ganz ohne irgendwelche Warnungen oder so:

#include <iostream>

int main()
{
   while (true){}
   std::cout << "Hallo" << std::endl;
}

Das äquivalente Codestück unter Java kompiliert nicht. Gibt es einen Grund dafür, warum der g++ das so einfach annimmt? Vermutlich kann man da irgendwie das "Warnlevel" anheben, oder? Wie heißt denn da der entsprechende Schalter für den Compiler?

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

Also ich weiß ja nicht, welchen Compiler du nutzt, aber bei mir kompiliert das entsprechende Codestück mit while(false) auch nicht:

public class Unreachable
{
   static void main(String[] args)
   {
      while(false)
      {
         System.out.println("Hallo!");
      }
   }
}

Da gibt es folgenden Fehler:

gregor@linux:~/JavaProjects/Test/UnreachableTest> /usr/java/jdk1.6.0/bin/javac Unreachable.java
Unreachable.java:6: unreachable statement
      {
      ^
1 error

Das ist allerdings auch ein Java 6.0-Snapshot javac. Vielleicht wurde das in früheren Compilern nicht als Fehler gefunden.

[Sgt. Nukem]

Meine Grinsebacke übersehen...

Gregor schrieb:

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

Also ich weiß ja nicht, welchen Compiler du nutzt, aber bei mir kompiliert das entsprechende Codestück mit while(false) auch nicht:

public class Unreachable
{
   static void main(String[] args)
   {
      while(false)
      {
         System.out.println("Hallo!");
      }
   }
}

Da gibt es folgenden Fehler:

gregor@linux:~/JavaProjects/Test/UnreachableTest> /usr/java/jdk1.6.0/bin/javac Unreachable.java
Unreachable.java:6: [b]unreachable statement[/b]

Sgt. Nukem schrieb:

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

[GPC]

anmerkung schrieb:

GPC schrieb:

Kenner des Problems schrieb:

Mit C++ wär das nicht passiert.

Stimmt, du hättest das Problem erst beim Testen entdeckt...

Troll

Ja klar, Laufzeitfehler sind mir auch enorm lieber als Compilerfehler/warnungen. Die sind viel eindeutiger, und auch nicht so schlimm, wenn sie bei der Präsentation des Programms auf einmal auftreten lol

Warum sollte ich mich um sowas kümmern? Der Compiler hat mehr Zeit als ich.

Vermutlich kann man da irgendwie das "Warnlevel" anheben, oder? Wie heißt denn da der entsprechende Schalter für den Compiler?

Nö, kann man afaik nicht, du kannst alles möglich warnen lassen, aber das anscheinend nicht, jedenfalls hat die manpage nichts in diese Richtung hergegeben.

Ich hab mal

#include <iostream>

int main() {
  while (1);

  std::cout<<"SCRRRREEAM!!\n";

  return 0;
}

via

bash-3.00$ g++ -W -Wall -O2 -Os -o main main.cpp
bash-3.00$ ./main

bash-3.00$

kompiliert und ausgeführt. Na ja, er hat jedenfalls nichts bemängelt.

MfG

GPC

[Gregor]

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen? Oder gibt es andere Gründe, warum nicht erreichbarer Code unter C++ durchaus normal ist?

[GPC]

Gregor schrieb:

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen?

Ich versteh zwar die Frage nicht, aber der bevorzugte Schalter zum Debuggen ist beim g++ der

-g

, der kommt dann bei der Release-Version weg, die Warnlevel bleiben(die Optimierung oben kann man sich beim Debuggen ja auch schenken). Ich jedenfalls hab die Warnlevel immer drin, und noch ein paar mehr, wenn mir der Compiler schon die Unterstützung bietet, nehme ich sie auch gerne in Anspruch.

Oder gibt es andere Gründe, warum nicht erreichbarer Code unter C++ durchaus normal ist?

Mir fällt kein vernünftiger ein. Aber vllt. kickt der Compiler das als "wegoptimierbarer" Code gleich in die Tonne

MfG

GPC

[Gregor]

GPC schrieb:

Gregor schrieb:

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen?

Ich versteh zwar die Frage nicht, [...]

Naja, das bezog sich darauf, dass man ja manchmal gewisse Ausgaben beim Debuggen haben möchte. Da hat man dann vielleicht schonmal ein Konstrukt der folgenden Art:

if(DEBUG) ausgabe;

Wobei DEBUG dann vielleicht eine boolsche Konstante ist bzw. über den Präprozessor definiert ist oder so.

Wenn man so ein "DEBUG" über den Präprozessor definiert, dann hat man da für den Compiler durchaus ein "if(false) ausgabe;" stehen und somit unerreichbaren Code. Aber vielleicht macht man das unter C++ ja auch ganz anders: Komplett über den Präprozessor zum Beispiel.

[Gast]

Gregor schrieb:

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen? Oder gibt es andere Gründe, warum nicht erreichbarer Code unter C++ durchaus normal ist?

In C++ ist es oft üblich, in einer while( true ) Schleife durch ein Array zu iterieren und beim letzten Element dann durch die Exception bei der Indexprüfung abzubrechen, was das Verhalten dieses Compilers erklärt. Der Code darunter ist nur scheinbar nicht erreichbar.

Naja ernsthaft, der g++ ist halt einfach schlecht. Ich hab auch mal sowas gehabt:

if( abs(a > 5)   &&   abs(b > 5) ) ...

Beim VC++ hättest du in beiden Fällen sofort ne Warnung.

[TriPhoenix]

$ g++ -Wunreachable-code test.cpp
test.cpp: In function `int main()':
test.cpp:6: warning: will never be executed
test.cpp:6: warning: will never be executed
test.cpp:6: warning: will never be executed
test.cpp:6: warning: will never be executed

Klappt wunderbar, wenn man nur den richtigen Schalter benutzt

[Gast]

Heißt -Wall jetzt neuerdings nicht mehr "alle Warnungen"?

[Gregor]

Optimizer schrieb:

In C++ ist es oft üblich, in einer while( true ) Schleife durch ein Array zu iterieren und beim letzten Element dann durch die Exception bei der Indexprüfung abzubrechen, was das Verhalten dieses Compilers erklärt. Der Code darunter ist nur scheinbar nicht erreichbar.

Dieses "Design-Pattern" hast du dir doch jetzt aus meinem Javacode geklaut. ...der übrigens fehlerfrei kompiliert, obwohl es da ein "while(true)" ohne "break;" drin gibt. :p hmmm... glaub ich zumindest. Ich weiß gar nicht, ob ich das überhaupt ausprobiert habe.

[Gast]

Ehrlich gesagt glaube ich nicht, dass er fehlerfrei compiliert. Ich würde vermuten, dass der Compiler nur checked Exceptions bei der Kontrolfluss-Analyse berücksichtigt.

[Gregor]

Optimizer schrieb:

Ehrlich gesagt glaube ich nicht, dass er fehlerfrei compiliert. Ich würde vermuten, dass der Compiler nur checked Exceptions bei der Kontrolfluss-Analyse berücksichtigt.

Da:

gregor@linux:~/JavaProjects/Test> cat AntiPattern.java
public class AntiPattern
{
   public static void main(String[] args)
   {
      int [] array = new int[100000];
      int a = 0;
      try
      {
         int i = 0;
         while(true) //Hier spar ich mir ganz viele Bereichsprüfungen.
         {
            array[i] = i;
            a += array[i];
            ++i;
         }
      }
      catch (ArrayIndexOutOfBoundsException e)
      {
         // Das hier ist die Abbruchbedingung für die Schleife.
      }
      System.out.println(a);
   }
}
gregor@linux:~/JavaProjects/Test> /usr/java/jdk1.6.0/bin/javac AntiPattern.java
gregor@linux:~/JavaProjects/Test> /usr/java/jdk1.6.0/bin/java AntiPattern
704982704

[meggge]

Warum AntiPattern? Dieses Pattern steigert doch die Pärformans?

[Gregor]

meggge schrieb:

Dieses Pattern steigert doch die Pärformans?

Glaub mal nicht alles, was ich hier erzähle. Im Zweifelsfall solltest du das selbst überprüfen.

[meggge]

ich hab schon viele deiner beiträge gelesen und jetzt kommt raus das alles nur verarsche war!?

[TriPhoenix]

Optimizer schrieb:

Heißt -Wall jetzt neuerdings nicht mehr "alle Warnungen"?

Neuerdings? Schon ne ganze weile. Über die Manpage geblickt ist -Wall nicht ganz die Hälfte aller Warnungen, sondern das was auf jeden Fall gewarnt werden sollte. Dazu kann man sich dann auf jeden fall noch -W bzw. -Wextra packen. Alle weiteren Warnungen sind wohl nur semiproblematisch und führen des öfteren zu false positives, da muss jeder wissen, was er will.

-Wall
           All of the above -W options combined.  This enables all the warnings about constructions that some users consider questionable,
           and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros.  This also enables some lan-
           guage-specific warnings described in C++ Dialect Options and Objective-C Dialect Options.

[Gast]

Das der unreachable code scheinbar nicht so wichtig ist, bestätigt nur meine Auffassung, dass es guter Stil ist, eine Schleife per IndexOutOfBounds- oder NullPointer-Exception zu verlassen.

@Gregor: Ich find's ja übrigens interessant, dass der Code ohne try-catch nicht mehr compiliert. Ich hätte eher erwartet, dass eventuelle throw-Statements in der Schleife ausschlaggebend sind, ob eine Schleife als endlos angesehen wird. Lustigerweise compiliert das:

class FooBarException extends RuntimeException { }

class Test {
	public static void main(String[] args) {
		int[] array = new int[100000];
		int a = 0;
		try {
			int i = 0;
			while( true )
			{
				array[i] = i;
				a += array[i];
			}
		}
		catch( FooBarException e ) { }
		System.out.println(a);
	}
}

obwohl definitiv kein Ende der Schleife abzusehen ist. Naja, aber amsonsten finde ich die Sprachspezifikation dazu schon ganz gut gelungen. Auch wenn eine Warnung es vielleicht auch getan hätte.