Listen extern iterieren

Der Member 'galaxy' wird zwar im Player gesetzt, aber nicht im GravityHandler!

FroZenViper

fuck, vielen Dank :S manche Fehler sind so trivial. Also danke an alle die mitgeholfen haben, werde das mal schleunigst korrigieren.

Und wenn du gerade schon dabei zu verbessern:
Wenn du alpha auch noch auf dem Heap erzeugst hast du wenigstens konsequent alles auf dem Heap liegen... naja, fast.
Kommst du aus der Java/C# Ecke?

using namespace sf; 

int main() 
{ 
    float alpha = new float( 0.0f ); 

    VideoMode desktop = VideoMode::getDesktopMode(); 
    RenderWindow window(desktop,GAMENAME, Style::Fullscreen); 

    //Creation of Player and one Planet 
    Vector2f planetPosition; 
    planetPosition.x = (float) desktop.width/2; 
    planetPosition.y = (float) desktop.height/2; 
    Planet* planet = new Planet(planetPosition, 200.0f); 
    Player* player = new Player(); 

    //Gravitation 
    RadialGravity* gravity = new RadialGravity(400, 1, 5); 

    //A new Galaxy 
    Galaxy* galaxy = new Galaxy(); 
    galaxy->getPlanetList()->push_back(planet);

    ...
}

FroZenViper

danke, für den Hinweis, werde ich auch noch machen. Naja Java/c#, sogar basic und delphi, hab ich auch schon geschrieben, eigentlich alles Querfeld, merkt man wahrscheinlich schon an der ein oder anderen Stelle.

DocShoe

Ich ~~denke~~ hoffe, das war ironisch gemeint. Du solltest eigentlich vermeiden, Daten explizit auf dem Heap zu erzeugen. Das gilt gerade für Galaxy , Planet und Player , die könnten genauso gut auf dem Stack liegen.

FroZenViper

das war leider nicht mal der Fehler, ich habs ein bisschen trickreich in meinem Code gemacht

void Player::setNewGalaxy(Galaxy* galaxy)
{
	this->gravityHandler->setGalaxy(galaxy);
}

man setzt das Level beim Spieler und der setzt es bei der Gravitation

FroZenViper

DocShoe schrieb:

Ich ~~denke~~ hoffe, das war ironisch gemeint. Du solltest eigentlich vermeiden, Daten explizit auf dem Heap zu erzeugen. Das gilt gerade für Galaxy , Planet und Player , die könnten genauso gut auf dem Stack liegen.

ja okay, ich muss mich da mal schlau machen, mit dem Unterschied der Erzeugung etc., bin halt kein Profi.

camper

FroZenViper schrieb:

danke, für den Hinweis, werde ich auch noch machen. Naja Java/c#, sogar basic und delphi, hab ich auch schon geschrieben, eigentlich alles Querfeld, merkt man wahrscheinlich schon an der ein oder anderen Stelle.

Zeiger+new und "Handler" sind ein Indiz. Ich würde GravityHandler ja zumindest durch GravityForce ersetzen, dann fällt nicht so auf, dass die Gravitation nicht selbst agieren kann.

FroZenViper schrieb:

Also Shared_ptr sind im Allgemeinen ja schon einfacher da es keine Speicherlecks gibt etc., oder schwerer sind diese herbeizurufen.

Ja, aber shared_ptr ist für geteilten Besitz. Den hast du nicht.

Für RAII bitte unique_ptr nehmen.

Unique Pointer Commitee schrieb:

Für RAII bitte unique_ptr nehmen.

unique_ptr ist aber für Polymorphie. Den hat er hier nicht.

Für RAII bitte vector<Planet> nehmen.

Eisflamme

Man kann unique_ptr auch nutzen, wenn man Verweise auf die Zeiger nutzen möchte oder häufig Dinge eingefügt werden. Bei vector<Object> hat man dann häufiges Umkopieren und Zeiger werden eben invalide. Polymorphie ist nur ein Grund.

Eisflamme schrieb:

Man kann unique_ptr auch nutzen, wenn man Verweise auf die Zeiger nutzen möchte oder häufig Dinge eingefügt werden. Bei vector<Object> hat man dann häufiges Umkopieren und Zeiger werden eben invalide.

In dem Fall ist aber deque<Objekt> besser als vector<unique_ptr<Objekt> >.

FroZenViper

also ihr seid alle falsch gelegen :p,

Im Prinzip war der Typ mit der Galaxy schon gut, weil ihr davon ausgegangen seid dass es galaxy nicht gibt, es lag jetzt aber daran dass ich dummerweise vergessen hatte die Gravitation des Planeten zu setzen, obwohl ich extra noch die Funktion geschrieben hatte. Mich wundert das nur, weil doch normalerweise Nullpointer Exception explizit dran steht.

Aber jetzt ist der Fehler ja weg.