Ich habe eine Klasse CameraControl zur Steuerung über das VISCA-Protokoll (Sony). Hier gibt es den connect() für die RS232 und dann ein init() zum Voreinstellen.

class CameraControl
{
    bool connect (void);
    bool init (void);
    bool found(void);
}

Meine Anwendung kümmert sich dann darum, dass beides nacheinander durchgeführt wird.

class Application
{
  public:
    CameraControl m_Camera;
    bool connectCamera (void);
}

bool Application::connectCamera (void)
{
    if ( !m_Camera.connect() )
        return false;
   return m_Camera.init();
}

Die Klasse CameraControl liefert mit der Methode found() zurück, ob die Initialisierug erfolgreich war, und ob eine passende Kamera gefunden wurde. Da mich zur Zeit nicht interessiert, warum connectCamara() versagt hat, habe ich den Rückgabewert nicht ausgewertet. Ich habe stattdessen found() benutzt (dass m_Camera public ist, war nicht geplant, sondern nur ein Akt des Frusts).

main ()
{
     App.connectCamera();
    if ( App.m_Camera.found() )
   {
        // ...
   }
}

So, und nun kommt es. Durch den reinen Aufruf von connectCamera() meint der Optimizer nun, er dürfte connectCamera() allein durch den Aufruf von m_Camera.connect() ersetzen. Das geht soweit, dass ein Breakpoint auf m_Camera.connect() in connectCamera() völlig ignoriert wird.

Ich habe dann connectCamera() so umgestellt, dass die Rückgabewerte in eine Variable geschrieben werden und diese dann am Ende zurückgegeben wird. Das bringt aber auch nicht das gewünschte Ergebnis.

Die einzige Lösung ist das Abschalten des Optimizers.

Woran kann das liegen?

Habt Ihr ähnliche Erfahrungen?

Ich kann doch nicht allen Code (auf Fremd-Libs) durchsehen, nur um Funktionsaufrufe zu finden, deren Rückgabewert nicht benutzt wird und diese dann prüfen...

(wenn du im Release-Modus bist, solltest du vielleicht auf clog-Debugging umsteigen (an kritischen Stellen des Programms "bin da"-Ausgaben nach clog oder in ein Logfile schreiben))

CStoll schrieb:

Der Optimizer kann Funktionen inline expandieren, auch wenn du das nicht explizit gefordert hast. Und deine Methode ist offenbar klein genug, um das zu machen.

Das ist schon klar, und das ist ja auch so gewünscht. Nur sollte es das dann komplett tun, und nicht die Hälfte weglassen. Das ist ja das Dumme.

CStoll schrieb:

Aber im Debug-Modus sollte er sowieso ausgeschaltet sein.

Theoretisch ja, aber solchen Fehlern kommt man ohne Debugger nur schwer auf die Spur.

CStoll schrieb:

(wenn du im Release-Modus bist, solltest du vielleicht auf clog-Debugging umsteigen

Was ist clog? Ich benutze zur Zeit _RPTF* um Ausgaben im Debugger zu haben. Allerdings kommen die nicht alle. Nur im Single-Step werden alle gezeigt, ohne Breakpoint gehen viele einfach verloren...

Auch so ein komisches Verhalten....

Danke für die schnelle Antwort.

CStoll schrieb:

Der Optimizer kann Funktionen inline expandieren, auch wenn du das nicht explizit gefordert hast. Und deine Methode ist offenbar klein genug, um das zu machen.

Das ist schon klar, und das ist ja auch so gewünscht. Nur sollte es das dann komplett tun, und nicht die Hälfte weglassen. Das ist ja das Dumme.

Schonmal daran gedacht, daß der connect()-Aufruf schiefgegangen sein könnte und er deshalb mit dem 'return false;' die Funktion vorzeitig verlassen hat?

CStoll schrieb:

(wenn du im Release-Modus bist, solltest du vielleicht auf clog-Debugging umsteigen

Was ist clog?

clog ist ein Bruder von cout und kann z.B. für Kontrollausgaben (unabhängig von eventuellen Ausgabeumleitungen) genutzt werden.

Ich benutze zur Zeit _RPTF* um Ausgaben im Debugger zu haben. Allerdings kommen die nicht alle. Nur im Single-Step werden alle gezeigt, ohne Breakpoint gehen viele einfach verloren...

Auch so ein komisches Verhalten....

Hmm, laut MSDN sind diese MAkros aber nur im Debug-Modus verfügbar.

PS: Vielleicht solltest du ja sowas wie eine Semi-Debug-Konfiguration erstellen - die vollen Optimierungen der Release-Version, aber eingeschaltete Debug-Informationen.

Schonmal daran gedacht, daß der connect()-Aufruf schiefgegangen sein könnte und er deshalb mit dem 'return false;' die Funktion vorzeitig verlassen hat?

Yepp. Ist es aber nicht. Ich bin im single-step durch und da war alles in Ordnung.

CStoll schrieb:

clog ist ein Bruder von cout und kann z.B. für Kontrollausgaben (unabhängig von eventuellen Ausgabeumleitungen) genutzt werden.

Oh. Da muss ich mal nachlesen. Ich habe mir aber schon log4cpp bereit gelegt.

CStoll schrieb:

Hmm, laut MSDN sind diese MAkros aber nur im Debug-Modus verfügbar.

Nur wenn _NDEBUG definiert ist. Das ist ja in meinem Fall.

CStoll schrieb:

PS: Vielleicht solltest du ja sowas wie eine Semi-Debug-Konfiguration erstellen - die vollen Optimierungen der Release-Version, aber eingeschaltete Debug-Informationen.

Danke für den Tipp, aber das Debugging ist ja nicht mein eigentliches Problem, sondern die "Fehler" (?) des Optimizers. Hast Du da noch eine Idee?

Bist du sicher, daß das nicht einfach Fehler des Debuggers waren? Oder hat das Programm tatsächlich die init() übersprungen?

Die Funktion wurde definitiv nicht nicht ausgeführt. Das ist ja das schlimme.

Davon abgesehen würde es mich doch sehr wundern wenn du wirklich über einen optimizer Bug gestolpert wärst. Vielleicht kannst du mal ein komplettes Beispiel posten, den kleinsten Code halt mit dem du den vermutlichen Fehler reproduzieren/demonstrieren kannst.

Verwendest Du denn den Release Mode?
Wenn Du im Debug-Modus arbeitest findet keine Optimierung statt. Schon gar kein Funktion unrolling.

1. Wenn Du sicher bist es ist der Optimizer, dann müsste durch ein

#pragma optimize( "", off )
.
// kritischer Code
.
#pragma optimize( "", on )

der Code funktionieren.

Gravierende Optimizr Bugs sind für VC2005 nicht bekannt.

2. Erzeuge in Assembler Listingmit Comments. Wenn Die Funktion nicht aufgerufen wird, dann ist Sie auch im Assembler Code nicht verzeichnet.
Ich glaube dies jedoch nicht...

Installier dir erstmal SP1, macht überhaupt keinen Sinn mit einem Compiler zu arbeiten der 1) einige bekannte Bugs hat und für den es 2) eben schon ein Update gibt.

Ich habe mir SP1 schon runtergeladen, nur sollen danach einige Pakete (wie Qt) nicht mehr funktionieren. Deswegen habe ich damit noch gewartet. Wie kritisch ist SP1? Hast Du da Erfahrungen? Sollte ich alle Pakete (libs) die ich bisher verwende neu bauen?

hustbaer schrieb:

Davon abgesehen würde es mich doch sehr wundern wenn du wirklich über einen optimizer Bug gestolpert wärst. Vielleicht kannst du mal ein komplettes Beispiel posten, den kleinsten Code halt mit dem du den vermutlichen Fehler reproduzieren/demonstrieren kannst.

Die "wegoptimierte" Funktion ist wirklich so einfach. Die anderen beiden Funktionen beinhalten "eine Hand voll" Aufrufe. Ich habe momentan zu wenig Zeit um ein Codesnippsel zu extrahieren, dass eventuell den Fehler zeigt. Ich bleibe aber drann und probiere es wahrscheinlich nächste Woche wieder.

@joede: Der Konstrukt ist zu einfach, dass hier der Optimizer Fehler macht.

Verwendest Du denn den Release Mode?
Wenn Du im Debug-Modus arbeitest findet keine Optimierung statt. Schon gar kein Funktion unrolling.

Ich habe im Debug-Mode den Optimizer ebenfalls angeschaltet. Dann springt der Debugger zwar ein bischen im Code rum, aber ich sehe wenigstens, was er durchläuft.

Martin Richter schrieb:

1. Wenn Du sicher bist es ist der Optimizer, dann müsste durch ein

#pragma optimize( "", off )
// kritischer Code
#pragma optimize( "", on )

der Code funktionieren.

Danke für den Tipp. Das ist gut zu wissen. Allerdings ist die Ursache dann noch nicht gefunden. Und das beunruhigt mich dann doch.

Martin Richter schrieb:

Gravierende Optimizr Bugs sind für VC2005 nicht bekannt.

2. Erzeuge in Assembler Listingmit Comments. Wenn Die Funktion nicht aufgerufen wird, dann ist Sie auch im Assembler Code nicht verzeichnet.
Ich glaube dies jedoch nicht...

Ich habe Breakpoints sowohl auf/in connectCamera() als auch in .init() gesetzt. Beide wurden nicht aktiv! Außerdem wurden die Sequenzen in .ini() nicht über die RS232 versendet. Das ist IMO Zeichen genug, umdavon auszugehen, dass sie ignoriert wurden.

Kannst Du mir auf die Schnelle sagen, mit welcher Einstellung ich den Assembler-Output aktiviere? Dann kann ich ja nochmal gezielt nachsehen.