Compiler Warnungen bei Code-Optimierung

JeGr

Hallo,
bei meinem Projekt kamen gerade ziemlich viele Warnung beim Compilieren.
Bei jedem Objekt, das ich mit "NULL" initialisiert habe, kam die Warnung, dass diese Objekt nie verwendet werden würde.

z.B.

...
  delete Ausgabe;
  Ausgabe = NULL;

Dann ist mir aufgefallen, dass ich in den Projekt-Optionen unter Compiler bei Code-OPtimierung den Eintrag "Geschwindigkeit" ausgewählt habe.
Wenn ich nun dort wieder den Eintrag "keine" auswähle, dann erscheinen diese Warnungen nicht mehr.

Vielleicht kann mir jemand erklären, welche Unterschiede es macht, ob man die Code-Optimierung aktiviert oder nicht.
Ich meine Warnungen sind ja nicht so schlimm, besonders solche, wie diese, die ich bekommen habe. Aber verwundert bin ich deshalb schon.

WebFritzi

Du bekommst sicher eine Warnung wie: "Ausgabe is assigned a value which is never used", was ja auch stimmt.

JeGr

Ja, genau so eine Meldung bekomme ich.
Aber ich weise doch nur den Null-Pointer nach dem Zerstören des Objektes zu.
Und wie gesagt, wenn ich keine Code-Optimierung wähle, dann erscheinen auch keine Warnungen, nur wenn ich die Code-Optimierung ("Geschwindigkeit") aktiviere, dann hagelt es die besagten Warnungen.
Ich hatte auch eine Warnung bei folgrnder Zeile:

int Zaehler = 0; //hier die Warnung
...
Zaehler = Irgend ein anderer Wert

Und dies, obwohl ich vielleicht 5 Zeilen später der Variablen einen anderen Wert zuweise und diesen auch verwende!

Wie schon erwähnt, ich wollte eigentlich wissen, ob die Code-Optimierung Vorteile hat und ob man dann diese Warnungen getrost ignorieren kann, oder ob die Optimierung nicht groß ins Gewicht fällt und man sie daher auch abschalten kann?

1ntrud0r

naja bei variablen ist es nicht wie bei registern die werden immer mit 0 initalisiert ( wenn du nix angibst ) .

[ Dieser Beitrag wurde am 16.01.2003 um 08:35 Uhr von 1ntrud0r editiert. ]

@JeGr, dein Vorgehen ist offensichtlich korrekt. Initialisierst du einen deleteten Pointer nicht mit NULL, bringt erneutes Löschen eine Fehlermeldung. Dieses Vorgehen ist auch in verschiedenen Erklärungen und Hilfen als der richtige Weg beschrieben worden. Richtiges Verhalten hat keine Meldung zu produzieren, wenngleich die Aussage der Meldung stimmt. IMHO hat hier das Warnsystem optimiert zu werden, sonst nichts.

Ich wollte aus dieser Begebenheit keinerlei weitere Rückschlüsse ziehen. Es hat IMHO rein gar nichts mit der Qualität und Wirkungsweise einer Einstellung zu tun. Wirkung der Einstellung und das Warnsystem laufen unabhängig voveinander.

Kann zu deiner eigentlich Frage leider nichts sagen, hab hier noch keine Erfahrung gesammelt. Aber vielleicht kann dir das bereits etwas helfen?

JeGr

Ja, das hilft mir schon weiter.
Fand's nur komisch, dass bei der Code-Optimierung eben diese Warnungen aufgetreten sind.
Das Programm lief ja immer noch - jedoch halt mit dem Schönheitsfehler, dass das Kompilat eben diese Warnungen enthielt.
Ich lasse jetzt einfach die Code-Optimierung weg und damit hat sich's für maich dann auch erledigt...

junix

Du kannst in der Registerkarte "Compiler" der Projektoptionen einzelne Warnungen ein und ausschalten.

-junix

**<edit>**Da diese Warnung nicht vor mögichen Fehlern die auftreten können warnt sondern einfach davor, dass du den wert den du mal zugewiesen hast nie ausliest bevor du ihn ein weiteres mal beschreibst, ist es hier richtig, die Warnung abzuschalten.

Allerdings hast du recht. Warnungen sollte man grundsätzlich immer ernst nehmen. Diese hier bildet alledings eine Ausnahme...</edit>

[ Dieser Beitrag wurde am 16.01.2003 um 10:12 Uhr von junix editiert. ]

Wenn für diese Situation gar eine Option besteht, wär das IMHO sogar ein Denkfehler. Eine initialisierte Variable existiert zu dem Zweck, auch benutzt zu werden. Einen Kontext auf NULL zu setzen bedeutet, daß der danach gar nicht mehr benutzt werden soll. Es ergibt keinen Sinn, diesen Fall in ein Überwachungssystem aufzunehmen. Es zu tun ist offensichtlich ein Fehler. Aber hier fehlt sicher nur die entsprechende Prüfroutine. Zwei völlig verschiedene Dinge werden gleich behandelt. Man kann niemals die Option setzen, die wirklich sinn macht.

Ist natürlich deine Entscheidung, aber wenn ich optimieren und endbuilden will, würde mich diese Situation nicht davon abhalten. Entweder ich will es jetzt einfach mal optimiert sehen, oder es ist erst mal fertig. Da frag ich nicht mahr nach einer Warnung, die auf einem Warnsystem-Mangel beruht. (Davor würde sie mich aber nerven. Der Meldebereich will ich in fehlerfreien Situationen gar nicht sehen. - Hab ihn schließlich oft genug als Spiegel meiner Unwissenheit ertragen müssen. :p ).

Shade Of Mine

Original erstellt von junix:
**
Allerdings hast du recht. Warnungen sollte man grundsätzlich immer ernst nehmen. Diese hier bildet alledings eine Ausnahme...**

Einspruch.

delete p;
p=0;
delete p;

ist semantisch falsch und hat somit als Fehler zu gelten.
ein zweifaches löschen eines zeigers ist einfach böse...

wenn man das p=0; weglaesst, dann bemerkt man so einen fehler und alles ist gut.

somit wird auch die warnung wegfallen

Graphics::TBitmap *pBitmap = new Graphics::TBitmap();
//Code
delete pBitmap;
pBitmap = NULL;

/Irgendwelche Arbeiten durch den User,
irgendwann erneuter Functionsaufruf./

Graphics::TBitmap *pBitmap = new Graphics::TBitmap();
//Code
delete pBitmap;
pBitmap = NULL;

Die doppelte Löschung kann ich nur vermeiden, indem ich alle Kontexte erst beim beenden der App delete.

Die unvermeidliche Konsequenz: Was immer der user aufruft, es wird permanent über die Leufzeit hinweg im Speicher gehalten. Doch mit Speicher gilt es sparsam umzugehen. Egal wie groß er ist, er ist begrenzt. Irgendwann ist also ein Notfall zu erwarten, der nur durch eine Zwangsmaßnahme behoben werden kann.

Will nicht "olle Petze" :p sein, aber "MusicMatch" zeigt sich hier als solcher Fall (wenngleich sicher auf einem anderen Hintergrund). Die abgespielten Songs werden weiterhin im Speicher gehalten. Ich muß die üblen Nachteile hinnehmen, die App irgendwann beenden oder zB. via FreeMeX immer wieder Speicher freigeben. - oder auf eine andere Anwendung zugreifen, was ich auch gemacht hab.

Bei Spielen wird die Sache geradezu fatal. Schon nach ganz kurzer Spielzeit wird die Performance total in den Keller gehen, das gesamte System setzt sich sehr schnell fest.

Also muß man zur Laufzeit Speicher freigeben. Der Programmierer muß absehen, wann das zu geschehen hat. Und nach meinen Infos ist hierfür vorgesorgt. Es ist legitim, einen deleteten Kontext auf NULL zu setzen. Einen NULL-Zeiger darf man löschen, ohne eine exeption auszulösen.

Stimmt diese Aussage oder ist sie falsch? Ich will es nicht behaupten sondern es als bekanntes Argument einbringen.