Compiler Optimierung deine Erfahrungen

Robbiani

Ja das habe ich ganz vergessen.

Ich arbeite mit RAD-Studion 10.2. Das Problem trifft sowohl bei 32 wie bei 64 Bit auf.

Gruss Renato

Da wird dir so jetzt keiner helfen können. Du musst den Fehler genauer einkreisen. Danach können wir über Compiler-Bugs spekulieren.

Robbiani

Ich habe den Fehler bereits gefunden. Daher brauche ich keine Hilfe.

Ich wollte nur eine Diskussion Starten um eure Erfahrungen mit dem Compiler-Optimierung zu erfahren. Das ist alles.

Gruss Renato

Th69

Dann korrigiere mal den Schreibfehler im Titel... (und zusätzlich einen etwas eingängigeren Titel wählen).

Mechanics

Naja, ausgehend von deiner bisherigen Beschreibung, hast du einfach zu wenig Ahnung und dein Programm ist fehlerhaft. Das hat mit Optimierungen soweit nichts zu tun, ohne Optimierungen ist die Wahrscheinlichkeit in deinem Fall einfach etwas höher, dass es zufälligerweise durchläuft. Das gibts auch andersrum, wenn das Programm im Release scheinbar ohne Probleme funktioniert, und im Debug dann crasht.

Ansonsten sind Compiler Bugs extrem unwahrscheinlich, aber nicht unmöglich. Wir sind bei VS schon über mehrere Compilerbugs gestolpert, vor allem mit VS 2015.

dot

Robbiani schrieb:

Ich wollte nur eine Diskussion Starten um eure Erfahrungen mit dem Compiler-Optimierung zu erfahren.

Meiner Erfahrung nach optimieren moderne Compiler ziemlich gut.

DocShoe

Robbiani schrieb:

Ich habe den Fehler bereits gefunden. Daher brauche ich keine Hilfe.

Ich wollte nur eine Diskussion Starten um eure Erfahrungen mit dem Compiler-Optimierung zu erfahren. Das ist alles.

Gruss Renato

Kannst du den Codeausschnitt bitte posten? Oder wenigstens beschreiben, was zu dem Fehler geführt hat? Das gibt anderen Benutzern die Möglichkeit, ihren Code auf den gleichen Fehler zu prüfen.

Im Debug Modus lief alles ok. Im Release Modus konnte ich das Projekt ohne Fehler Linken und Compilieren. Aber als ich das Programm ausführte führte dies immer zu einem "Access violation". Was ist das los!!?

Wo passiert denn die Access Violation? Ist der Code an der Stelle WIRKLICH 100% verifiziert in Ordnung oder du nur denkst das sollte so sein

Nun habe ich rausgefunden, dass wenn ich die Compiler Optimierung, was standard auf schnellstmöglichen Quelltext erzeugen steht, entferne läuft das Projekt auch wieder unter Release. Bis ich das gefunden habe!

die verschiedenen Varianten erzeugen anderen Code und haben auch andere Verhaltensweise z.B. per-default-Null Initialisierung von Variablen im bestimmten Scopes usw.

Es ist sehr wahrscheinlich das der Fehler in dem Source zu finden ist und bisher eben nicht aufgetaucht ist - daher sind auch Multi-Kompiler/Platform Builts sehr hilfreich

Es ist klar das Kompiler auch Fehler haben - aber man muss klar differenzieren zwischen Kompilier-, Code-Generier-Fehler - die letzteren sind böse und gefährlich und davon gibt es nicht ganz so viele

Dein "Fix" ist eher ein karschieren des Problems

leider ist der In-Debug-gehts-in-Release-nicht-Fehler so ein sehr typischer Anfänger(oder es wurde zu spät im Release getestet)-Fehler - unabhängig von deiner Erfahrung ist das so der Standard-Mystisch-Fehler

deswegen sind hier einige nicht von dem Kompilerfehler überzeugt und wollen mehr über die Access Violation Stelle wissen

Ich hab auch schon genug mit Software zu tun gehabt die nur als Debug-Built funktioniert hat und alle sich sicher waren das es ein Kompilerfehler ist - schlussendlich waren es immer haufen von nicht initialisierten Variablen - speziell Pointer die dann Random oder definiertte Abstürze verursacht haben

Der 1. Denkfehler ist immer: Weils im Debug läuft ist alles OK

Burkhi

Man sollte sich grundsätzlich angewöhnen, Zeigervariablen bereits beim Anlegen immer mit 0 zu intialisieren und am besten auch noch auf 0 setzen, wenn man den Speicher, auf den diese verweist, wieder freigibt.

int *a = 0;

a = new int;

*a = 4711;

delete a;
a=0;

DocShoe

Ohne Code ist das doch alles nur Spekulation...