Unreachable code- Meldung. Warum?

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.

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.

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.

GPC

Gregor schrieb:

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.

Ah jetzt, ja das ist so, man gibt dem Compiler das als Flag mit, wenn man eben Debug-Ausgaben haben will, oder nicht. Wenn man das nur in minimalem Umfang betreibt, dann kann man auch schon mal in den Header ein #define DEBUG reinschreiben und es dann wieder auskommentieren.

Optimizer schrieb:

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

Kannst du deine Aussage ein wenig differenzieren? Ich habe nämlich eine sehr hohe Meinung von der GCC. Das er mir die unreachable-Code Warning nicht gleich anzeigt, ist ärgerlich, aber für mich kein Grund den kompletten g++ zu verteufeln.

TriPhoenix schrieb:

$ 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

Hm, gewusst wie , hätte die manpage genauer lesen sollen...

MfG

GPC

GPC schrieb:

Kannst du deine Aussage ein wenig differenzieren? Ich habe nämlich eine sehr hohe Meinung von der GCC. Das er mir die unreachable-Code Warning nicht gleich anzeigt, ist ärgerlich, aber für mich kein Grund den kompletten g++ zu verteufeln.

Ich habe schon recht viele, völlig unnötige Debugging-Sessions gehabt wegen Dingen, die der Compiler einfach hätte warnen können und die der VC++ auch garantiert mit Standardeinstellungen bemängelt. Ich habe nicht mehr alle Beispiele im Kopf aber es waren triviale Sachen wie Selbstzuweisung, Ausdrücke ohne Zuweisung wie ein alleinstehendes a << 2; und das genannte Beispiel. Trotz -Wall und -pendantic. Wieviele switches muss ich denn noch angeben, damit er billigste Sachen findet?

Dann compiliert er stinklangsam.

Außerdem habe ich mal eine etwas kopmlexere Datenstruktur mit Templates gebaut und hatte auf einen Schlag 48 völlig unverständliche Fehlermeldungen. Ich bin zwar kein C++ Guru aber für gewöhnlich kann ich mit Fehlermeldungen was anfangen. Jede einzelne der 48 Meldungen war aber nicht mal in der Nähe der wahren Ursache. Also bin ich heimgegangen und hab den Code mit dem VC++ compiliert, 1 Fehler wurde gemeldet, der es auch wirklich war.

Nein, insgesamt habe ich keine hohe Meinung vom g++, er hat mir wirklich schon viel Ärger gemacht, bzw. nicht erspart. Ein ordentlicher Compiler ist für mich zum Beispiel der VC++ 2005.

GPC

Optimizer schrieb:

Ich habe schon recht viele, völlig unnötige Debugging-Sessions gehabt wegen Dingen, die der Compiler einfach hätte warnen können und die der VC++ auch garantiert mit Standardeinstellungen bemängelt. Ich habe nicht mehr alle Beispiele im Kopf aber es waren triviale Sachen wie Selbstzuweisung,

Zählt für mich nur halbwegs, denn von einem halbwegs guten C++ Entwickler erwarte ich, dass er die Selbstzuweisung für benutzdefinierte Typen im Zuweisungs-op abfängt. Außerdem gibt's ein Flag dafür.

Im Übrigen läuft g++ Standardeinstellung bei mir nicht unter:

g++ -o main main.cpp

. Da gehört schon ein wenig mehr dazu.

Ausdrücke ohne Zuweisung wie ein alleinstehendes a << 2; und das genannte Beispiel. Trotz -Wall und -pendantic. Wieviele switches muss ich denn noch angeben, damit er billigste Sachen findet?

Ich arbeite mit den autotools, da sind diese Warnings an (jedenfalls bei mir). Kein Problem für mich. Sicher blöd, sie nicht mit einem "-Wenable-all"-like Konstrukt alle auf einen Schlag aktivieren zu können.

Dann compiliert er stinklangsam.

Was ist stinklangsam bei dir? Im Vergleich zum VC++? Kann ich nichts zu sagen, ich hab den VC++ nicht, aber der g++ macht auf meinem Linux-System ne gute Figur. Finde ich.

Außerdem habe ich mal eine etwas kopmlexere Datenstruktur mit Templates gebaut und hatte auf einen Schlag 48 völlig unverständliche Fehlermeldungen.

Ok, die Fehlermeldungen sind z.T. wirklich schwierig nachzuvollziehen.

Nein, insgesamt habe ich keine hohe Meinung vom g++, er hat mir wirklich schon viel Ärger gemacht, bzw. nicht erspart. Ein ordentlicher Compiler ist für mich zum Beispiel der VC++ 2005.

Na dann lassen wir's darauf beruhen, ich kenne den VC++ zu wenig, um eine Meinung über ihn zu haben.

EDITS: Rechtschreibfehler korrigiert

MfG

GPC

Roman007 schrieb:

Hallo,
könnt ihr mal dem Anfänger helfen?
Ich habe folgenden Code:
try 
	{
	 Socket socket = new Socket(host, port);
	 DataInputStream is = new DataInputStream(socket.getInputStream());
     String temp;

         while (true) // lese wiederholt InputStream
              { 
                 temp = is.readLine();					
		         StringTokenizer st = new StringTokenizer(echo);	
					
		         int T1_X = Integer.parseInt(st.nextToken());
                 //u.s.w.
              }
             
            is.close();
            socket.close();
         } // try end

      catch
         // u.s.w.
warum meldet Kompiler o.g. Fehler (in der Zeile is.close(), und socket.close())
steht es in der whlie schleife, kein Fehler, aber nach einmaligen Durchlauf, sind is, und socket geschlossen, und das will ich nicht.

Noch was. Die close von Streams sollten immer in finally Blöcke. Is besser.

MarkusS

meggge schrieb:

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

Ganz bestimmt nicht! Beim Iterieren über ein Array ist eine gewöhnliche for-Schleife wesentlich schneller als eine Endlosschleife die auf eine IndexOutOfBoundsException wartet. Das Werfen und Fangen der Exception ist viel zu teuer!

meggge schrieb:

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

Ob das nun für alle Posts von Gregor gilt kann ich nicht beurteilen