Konstuktor initialiert Werte falsch?

greece57

So das hab ich jetzt getan... Jetzt funktionierts xD

Aber ich will ja nicht das aufs mindeste reduzierte Projekt kombilieren sondern das andere^^

Aber was mir aufgefallen ist, ist das ich im Debugmodus beim neuen reduzierten Projekt in den Konstruktor von CResolution reinspringe. Im gesamten Projekt tu ich das nicht o.O
Wenn ich n haltepunkt im gesamten PRjekt in den Konstruktor lege macht er diesen unsichtbar und sagt

Der Haltepunkt wird mom nicht erreicht. Mit dieser Zeile ist kein ausführbarer Code verbunden.
Mögliche Ursachen: Präprozessordirektiven oder Compiler/-Linkeroptimierung

pumuckl

greece57 schrieb:

So das hab ich jetzt getan... Jetzt funktionierts xD

Dann hast du es zu weit reduziert.

pumuckl schrieb:

Um deine Probleme analysieren zu könen bräuchten wir ein komplettes, compilierbares, aber aufs Wesentliche reduziertes Code-Beispiel, mit dem sich die Probleme nachstellen lassen.

Nimm schrittweise Teile aus deinem Code, von denen du glaubst, dass sie mit dem Problem nichts zu tun haben, und geh danach jedesmal sicher, dass das Problem auch weiterhin existiert.

Wenn ich n haltepunkt im gesamten PRjekt in den Konstruktor lege macht er diesen unsichtbar und sagt
Der Haltepunkt wird mom nicht erreicht. Mit dieser Zeile ist kein ausführbarer Code verbunden.
Mögliche Ursachen: Präprozessordirektiven oder Compiler/-Linkeroptimierung

Das bedeutet, dass der Konstruktor nicht ausgeführt wird. Mögliche Ursachen sind:
a) Du hast den Code, in dem du den Breakpoint setzt, nicht compiliert ("Kombilieren" gibts nicht), d.h. der Code, der beim Debuggen läuft, ist ein anderer als der, den du in der IDE offen hast.
b) Du hast beim Übersetzen Optimizer-Flags gesetzt, so dass der Ctor wegoptimiert wurde.
c) Du hast den Code ohne Debuginformationen übersetzen lassen.

greece57

Es lag an c Sobald ich mit Debuginformationen übersetzen lasse kriege ich eine "Zugriffsverletzung beim Lesen an Position 0xcccccccc." (Hatte ich aber vergessen - liegt an SFML aber ich dachte ich schalt auf Release um und kümmer mich einfach nicht weiter um das problem^^)

Heißt das mein Code funktioniert EIGENTLICH im releasemodus aber sobald ich ihn das ganze Debuggen lasse macht er einfach irgendwas?

MFK

greece57 schrieb:

Es lag an c

Nein, es liegt an deinem Code.

Irgendwo in deinem Code steckt (mindestens) ein Fehler, der undefiniertes Verhalten erzeugt. Der Fehler steckt auch selten da, wo er sich bemerkbar macht. Du musst deinen gesamten Code daraufhin prüfen. Und das geht am besten, indem du, wie pumuckl schon sagte, nach und nach Teile entfernst, bis das Problem nicht mehr auftritt.

Das kleinstmögliche Programm, das den Fehler noch zeigt, kannst du dann hier einstellen.

greece57

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

PS du weißt dass ich mit "es liegt an c" meinte dass es an seiner antwortmöglichkeit c) liegt, oder? Also nicht dass du denkst, ich denke es liegt an der Programmiersprache

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