ich komme aus der Java-ecke und wollte mal wieder seit langem in C++ programmieren.
Und schon kommen die ersten Probleme die ich nicht verstehe und zu denen ich auch nix im Internet finde

Mein Problem: Ich will einfach nur einen Konstuktor einer Membervariablen aufrufen um diese zu initialisieren...

Hier die Codeausschnitte:

//Framework.hpp
//
#ifndef FRAMEWORK_HPP
#define FRAMEWORK_HPP

#include "Singleton.hpp"
#include "Resolution.hpp"

#define g_pFramework CFramework::Get()

class CFramework : public TSingleton<CFramework>
{
  public:

	  CFramework() {};

	bool		Init	(std::string Titel, int ScreenWidth, int ScreenHeight,
						int ColorDepth, bool bFullscreen);

  private:

        // Variablen
        //
	CResolution			actResolution;

	// Final
	//
	static const CResolution maxResolution;

};

#endif

// Framework.cpp
//

#include "Framework.hpp"

const CResolution CFramework::maxResolution = CResolution(2048,1536);

//Init
//
// Aufgabe: Framework initialisieren
bool CFramework::Init (std::string Titel, int ScreenWidth, int ScreenHeight, int ColorDepth, bool bFullscreen)
{

	actResolution = CResolution(ScreenWidth, ScreenHeight);

	if (bFullscreen)
		window.Create(sf::VideoMode(actResolution.getWidth(), actResolution.getHight(), ColorDepth), Titel, sf::Style::Fullscreen);
	else
		window.Create(sf::VideoMode(actResolution.getWidth(), actResolution.getHight(), ColorDepth), Titel);
}

// Resolution.hpp
//

#ifndef RESOLUTION_HPP
#define RESOLUTION_HPP

class CResolution
{
public:
	CResolution() {};
	CResolution(int width, int hight) : width(width),hight(hight) {};

	// getMethoden
	//
	int getWidth()const	{return width;};
	int	getHight()const	{return hight;};

private:

	int width;
	int hight;

};

#endif

Die Werte in der FramworkInit() Methode für ScreenWidth und ScreenHight sind 1024 und 768.
Nachdem ich sie durch den Konstruktor laufen lasse hat actResolution die Werte 1024 und -1163005939 und ScreenWidth 768 und ScreenHight auch 768.

Hää?

Danke für eure Erklärungen!
Niko

Felix

greece57 schrieb:

Nachdem ich sie durch den Konstruktor laufen lasse hat actResolution die Werte 1024 und -1163005939 und ScreenWidth 768 und ScreenHight auch 768.

-1163005939 = BAADF00D

Du zerschießt dir vermutlich irgendwo vorher den Speicher, wahrscheinlich durch uninitialisierte Variablen oder Array-Bereichsüberschreitungen. Das erzeugt in C++ im Gegensatz zu Java nicht sofort einen Laufzeitfehler, sondern kann zu ganz merkwürdigem Verhalten irgendwann später führen.

CFramework::CFramework()
{
	frametext = CText();
	actResolution = CResolution();

}

Jetzt sind die Werte für actResolution für width 1244880 und für hight 4019872.
Nachdem ich jetzt die InitMethode aufrufe und die Zeile

actResolution = CResolution(ScreenWidth, ScreenHeight);

durchgelaufen ist hat actResolution die Werte width 1024 und hight immernoch 4019872

ich checks nicht
Wieso erkennt er mir den hightwert nicht an
Und wieso verändert er plötzlich den Wert von ScreenWidth auf ScreenHight

P.S.: Namensänderung hat wie erwartet nix gebracht

Ich rufe jetzt im Frameworkkonstruktor die Konstruktoren aller Membervariablen auf.

Tust du nicht. Du lässt den Compiler die Default-Initialisierung generieren und rufst hinterher Zuweisungsoperatoren auf. Schau mal im Netz nach dem Stichwort "Initialisierungsliste".

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.

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

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.

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

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.

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

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.

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.

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

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".

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

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

Ich darf das um "minimales" ergänzen?

@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

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.

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.

#include "SFML/Graphics.hpp"

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

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

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