[gelöst] Komischer Fehler bei einer Dll in VS 2010

[Stephan]

Hi

Ich hab eine größere Dll erstellt. Das kompilieren verläuft ohne Fehler (Und hab ich schon zig mal neu gemacht). Wenn ich jetzt allerdings mit dem Debugger in eine Klasse der Dll gehe wird in allen Parametern der Klasse ein default-Wert angezeigt, obwohl diese im Konstruktor gesetzt werden (Der wird auch ausgeführt). Wenn ich die Parameter jedoch manuell ausgebe (in Textdatei schreiben), dann stimmen diese alle. Das ist zwar komisch, aber damit kann ich noch leben.

Das problematische kommt noch:
In der Klasse gibt es zwei bool-Parameter (m_bShouldInitialisedSceneFL und m_bShouldInitialised). Und eine Funktion im Header:

Code: Alles auswählen

inline bool _shouldInitialised(void) const	{ return m_bShouldInitialisedSceneFL || m_bShouldInitialised;	}

Wenn ich jetzt in einer anderen Funktion (die ist im cpp File, also in der dll) ausgebe was bei (m_bShouldInitialisedSceneFL || m_bShouldInitialised) rauskommt, so kommt da was anderes raus, als wenn ich shouldInitialised() ausgebe... Und das ist ziemlich blöd...

Der Vollständigkeit noch: Von dieser Klasse in der Dll leitet sich eine andere Klasse auserhalb der Dll ab um die Funktionen zu verwenden.

Hat jemand schonmal so einen Fehler gehabt? Echt komisch der Fehler...

Grüße

[eXile]

Wenn ich jetzt allerdings mit dem Debugger in eine Klasse der Dll gehe wird in allen Parametern der Klasse ein default-Wert angezeigt, obwohl diese im Konstruktor gesetzt werden (Der wird auch ausgeführt). Wenn ich die Parameter jedoch manuell ausgebe (in Textdatei schreiben), dann stimmen diese alle.

Das hatte ich auch einmal, allerdings war das noch in grauer Vorzeit (Visual Studio 2003). Ich habe das damals in eine MSDN Newsgroup gepostet, und es kam sinngemäß (zurückgeschnauzt): Ein Debugger sollte niemals die korrekte Funktionalität, sondern nur das Vorhandensein von Fehlern melden. Dass man ersteres zum Finden letzterer braucht, kam denen nicht in den Sinn ... vielleicht waren sie auch alle zu beschäftigt, ihr .NET zusammenzukloppen. ;) Ich würde diesem Punkt erst einmal noch gelassen entgegentreten.

Liegt die unterschiedliche Ausgabe immer gleichbleibend an einer der beiden Variablen des Ausdrucks? Oder benutzt du irgendwelche globalen Variablen?

[Stephan]

Das mit dem Debugger seh ich auch nicht so streng. Hat mich nur verwundert, da andere Klassen in der Dll korrekt angezeigt werden.

Bei den Variablen ist nichts global.
m_bShouldInitialisedSceneFL = true;
m_bShouldInitialised = false;
_shouldInitialised() lifert false, was falsch ist. Der direkte Vergleich (m_bShouldInitialisedSceneFL || m_bShouldInitialised) liefert hingegen true...

Ich bin da recht ratlos...
Aktuell versuch ich gerade die Dll als lib zu erstellen und dann diese einbinden. Daran sollte ich sehen, ob es an der Erstellung der dll liegt...

[kimmi]

In deinem Output-Fenster: kommen da Fehlermeldungen wegen falscher PDB's? Und hast du Optimierungen im Debug-Build desaktiviert? Bei solchen Fehler kann es auch helfen, die besagten Variablen mal volatile zu machen. Dann darf der Compiler sie nicht versehentlich wegoptimieren.

Gruß Kimmi

[Stephan]

Die fehlenden PDB's beziehen sich alle auf System-Dll's. Sind also unwichtig. Die eigenen PDB's werden alle geladen. Optimierung ist ausgeschaltet. Ob die Variablen volatile sind macht keinen Unterschied.

[Stephan]

Ich hab das Problem jetzt gelöst... War ziemlich banal das ganze...

Also: In der Klasse gibt es eine Variable, welche mit dem Präprozessor eingebunden werden kann. Das Problem war, dass das #define beim Erstellen der dll vorhanden war, die Variable also eingebunden wurde. Beim Erstellen der exe war das #define nicht vorhanden, was eine unterschiedliche Klassengröße ausgemacht hat, was wiederum dem Debugger Probleme gemacht hat... Hierdurch ist auch das Problem mit den unterschiedlichen Ergebnissen der Bool-Logik erklärt. Einmal war die Funktion in der Dll, hat also mit den richtigen Werten gerechnet, das andere mal war die Funktion in der exe (Wegen Inline und Headerkodierung), hat also mit den falschen Werten gerechnet...

Naja. Jetzt funktioniert's...
Danke