Konstuktor initialiert Werte falsch?

daddy_felix

greece57 schrieb:

Der Fehler tritt aber nicht auf wenn ich das Programm im Releasemodus laufen lasse o.O
Wenn ichs dann die werte per std::cout ausgebe, dann stimmen die

nun, das Verhalten von undefiniertem Verhalten ist und bleibt undefiniert.

MFK

greece57 schrieb:

Der Fehler tritt aber nicht auf wenn ich das Programm im Releasemodus laufen lasse o.O

Ja, das ist das Schöne an undefiniertem Verhalten: Es ist undefiniert. Es kann also auch funktionieren. Aber es kann eben auch sein, dass du eine Programmzeile hinzufügst, und es knallt, auch im Release.

Der Fehler ist damit nicht weg.

CCCCCCCC weist übrigens auf uninitialisierten Stackspeicher hin. Möglicherweise legst du einen Zeiger auf dem Stack an und greifst darauf zu, ohne den Zeiger auf ein Objekt zeigen zu lassen. Im Debug-Modus wird der Stackspeicher mit CC gefüllt, und es gibt einen mehr oder weniger wohldefinierten Absturz. Im Release-Modus zeigt dein Zeiger irgendwo in den Speicher, und was dann passiert, ist eben Zufall.

Schau dir die Stelle genau an, wo's im Debug knallt. Da ist dein Problem.

greece57

Die Stelle wo's im Debug knallt existiert nicht - und wie du richtig bemerkt hast liegt da mein Problem.
Im Releasemodus hingegen existiert sie - und aus dem Grund funktionierts auch.

Die Funktion tut das was sie soll, und sieht auch so aus, dass es Sinn gibt also wieso sollte sie einen Fehler beinhalten?

Wenn es eine Compilerkonfiguration gibt, in der eine Funktion fehlerhaftes Verhalten produziert, ist sie fehlerhaft. Diese Sichtweise solltest du dir schnellstmöglich angewöhnen, sonst bringst du es höchstens zum Webdesigner.

Undefinierter Speicher im Zusammenhang mit der Verwendung eines Singletons -- es ist ohne Codebeispiel, das den Fehler reproduziert (hint, hint) natürlich unmöglich, den Fehler mit Bestimmtheit zu finden, aber ich rate jetzt mal wild:

Passiert dieser ganze Kram, bevor main betreten wird? In diesem Fall könnte es sein, dass du dir ein static initialisation order fiasco gebaut hast. Das läuft dann so:

Globales Objekt A benötigt zur Initialisation globales Objekt B. Globales Objekt B ist zu diesem Zeitpunkt aber noch nicht initialisiert, also macht die Initialisierung des globalen Objektes A Unfug.

Da die Reihenfolge, in der globale Objekte initialisiert werden, nicht bis ins kleinste Detail geregelt ist, können sich verschiedene Compilerkonfigurationen hier voneinander unterscheiden - womöglich wird in der Debug-Version zunächst Objekt B, in der Release-Version aber Objekt A zuerst gebaut. Das kann dann passieren, wenn Objekte A und B sich in verschiedenen Übersetzungseinheiten befinden, sonst garantiert der Standard die Abarbeitung von oben nach unten.

Man muss hier natürlich peinlich auf die Vermeidung von Zirkelbezügen achten, ansonsten lässt sich das ganze Problem umgehen, indem man das Objekt in eine Funktion verpackt:

// Statt
//
// singleton instance;
//
// ...
//
// instance.do_something();

singleton &instance() {
  static singleton self;
  return self;
}

...

instance().do_something();

Allerdings muss man auch hier etwas aufpassen: Die Zerstörungsreihenfolge ist ähnlich komplex vorhersagbar. Es ist mitunter problematisch, wenn globale Objekte sich gegenseitig in ihren Destruktoren benutzen.

Dies ist natürlich nur einer der Gründe, warum Singletons eine Anti-Pattern sind. Gibt es irgendeinen wirklichen Grund, das ganze als Singleton zu behandeln anstatt als normale Klasse?

Übrigens, nur am Rande: Das englische Wort für Höhe ist "height", nicht "hight".

greece57

Hatte die letzten 2 Tage kein Internet -.-

Aber ich entdeck echt nix und wüsste auch nicht wie weit ich den code kürzen müsste damits nachstellbar ist
Ich hab hier jetzt mal das ganze Projekt hochgeladen (Compiler: Microsoft Visual C++ 2010 Express):
https://rapidshare.com/files/1087224170/Coingame.zip

Um es zu compilieren musst du dir noch die SFML 1.6 laden und in C:/ abspeichern:
http://sfml-dev.org/download.php

Vielleicht verstehst dus ja

MFK

SMFL 1.6 finde ich nur für VS2005 und VS2008.

Swordfish

seldon schrieb:

[...] Codebeispiel, das den Fehler reproduziert (hint, hint) [...]

Ich darf das um "minimales" ergänzen?

greece57

Also bei mir funktionierts mit der 1.6 für 2008.
Glaubst du daran könnt's liegen dass der Debugmodus nicht läuft?

@Swordfish: Wie gesagt ich weiß nicht wie viel ihr braucht um das ganze nachzustellen weil ich nicht genau weiß wo der Fehler auftritt.
Ich fand die Losung jetzt ganz elegant weil ihr ja trotzdem mit 3 Klicks alles nachstellen könnt

MFK

greece57 schrieb:

Also bei mir funktionierts mit der 1.6 für 2008.

Absturz bei Debug und falsche Werte bei Release nennst du "funktionieren"?

greece57 schrieb:

Glaubst du daran könnt's liegen dass der Debugmodus nicht läuft?

Ja.

Swordfish

greece57 schrieb:

Wie gesagt ich weiß nicht wie viel ihr braucht um das ganze nachzustellen [...]

DU sollst es soweit wie möglich kürzen daß bei minimaler Codemenge der Fehler reproduzierbar bleibt.

MFK

Absturz in Debug reproduzierbar mit

#include "SFML/Graphics.hpp"

int main()
{
	sf::String  sftext;
}

Ziemlich sicher, dass es an der falschen Version von SFML liegt.

Projekteigenschaften -> Konfigurationseigenschaften -> Allgemein -> Plattformtoolset -> v90 einstellen, dann benutzt der im Backend den 2008er-Compiler, und es müsste mit Bibliotheken für vc2008 funktionieren.

Die in VC2010 neuen Features gibt es dann allerdings natürlich nicht.

cooky451

Einfach die neueste Version selbst kompilieren, da sind VS Projekte bei, das ist wirklich nicht schwer.

greece57

Ok dh ich habe einfach nur die falsche sfml Version benutzt und deswegen is dieser koomische "Fehler" aufgetretten?
Gut dann danke an alle! Werde es mit dem selbst kompilieren versuchen