3. warum stürzt das ab(push_back bei vector)

warum stürzt das ab(push_back bei vector)

  • P

    Also ich hab mir das ganze mit dem debugger angeschaut aber keine undefinierten variablen/pointer oder speicherfehler gefunden.

    void PSpawner::frame()
{
	if(cInterval < sAmount) //wenn weniger partikel ausgestoßen wurden, als insgesamt ausgestoßen werden sollen
	{
		if(sInterval > 0)//wenn der interval größer 0 ist
		{
			Uint32 cTime = SDL_GetTicks() - startTime;//alter des spawners
			int cDif = (int)(cTime/(float)sInterval) - cInterval ;//anzahl der abgelaufenen intervalle seit dem letzten aufruf von frame()
			cInterval += cDif;//intervalle auf abgelaufene intervalle addieren
			while(cDif > 0)//alle ausstehenden intervalle durchlaufen
			{
				SDL_Surface *t;
				t = sprite;
				t->refcount++; //partikel kopieren (surface)
				Particle pt(t, gravity, replaceColor, lifetime, pos.x, pos.y, direction.x, direction.y); // neuen partikel mit den gegebenen parametern erstellen
				if(hasFade)//irrelevant
					pt.addFadeStruct(fadeS);
				pList->push_back(pt);//auf die liste der partikel pushen (der pointer auf die liste wird beim erstellen des spawners übergeben.)

				cDif--;//is klar
			}
		}
	}
}

    das ist ein partikelspawner, der in intervallen partikel ausstößt.
    nachdem 1(glaube ich) partikel ausgestoßen wurde, beendet sich das programm bei der zeile pList->push_back(pt); (beim nächsten ausstoß)

    0
  • B

    wo ist pList deklariert also der vector?
    Wie hast du in deklariert?
    Hat Particel ein Copy C-tor?
    Übergibst du auch richtig den Pointer des Vectors?

    0
  • P

    BorisDieKlinge schrieb:

    wo ist pList deklariert also der vector?
    Wie hast du in deklariert?
    Hat Particel ein Copy C-tor?
    Übergibst du auch richtig den Pointer des Vectors?

    nein particle hat keinen copy ctor, worfür bräuchte man den hier ?

    0
  • M

    pixartist schrieb:

    nein particle hat keinen copy ctor, worfür bräuchte man den hier ?

    Keine Ahnung, dazu hast du nicht genug von Particle gezeigt. Da aber Particle im Konstruktor einen Zeiger mit Referenzzählung entgegennimmt, könnte es sein, dass du einen brauchst. Der Fehler steckt IMHO nicht in dem gezeigten Code, sondern irgendwo in Particle, oder an ganz anderer Stelle.

    0
  • B

    Dadurch das du PArtikel Objekte lokal in dem while block erzeugt:

    Particle pt(t, gravity, replaceColor, lifetime, pos.x, pos.y, direction.x, direction.y); // neuen partikel mit den gegebenen parametern erstellen

    und dann "pt" in den vector Pushed, erstell der vector eine Kopy von pt und haut legt dies im vector ab..

    von dem gezeigten code her hast du vector so delaiert?

    std::vector<Particle> *Liste;
    0
  • B

    Besser wäre es wohl so

    pList->push_back(Particle(t, gravity, replaceColor, lifetime, pos.x, pos.y, direction.x, direction.y));
if(hasFade)//irrelevant
     pList->back().addFadeStruct(fadeS);

    Da spart man sich eine Kopie. Den CopyCtor braucht man natürlich trotzdem.

    0
  • P

    Braunstein schrieb:

    Besser wäre es wohl so

    pList->push_back(Particle(t, gravity, replaceColor, lifetime, pos.x, pos.y, direction.x, direction.y));
if(hasFade)//irrelevant
     pList->back().addFadeStruct(fadeS);

    Da spart man sich eine Kopie. Den CopyCtor braucht man natürlich trotzdem.

    achso zum pushen von objekten in nen vektor braucht das objekt nen copy ctor ? interessant, wusste ich nicht.
    was mich daran wundert ist, dass ich ja einen partikel pushen konnte! (der wurde dann auch dargestellt)

    0
  • C

    pixartist schrieb:

    BorisDieKlinge schrieb:

    wo ist pList deklariert also der vector?
    Wie hast du in deklariert?
    Hat Particel ein Copy C-tor?
    Übergibst du auch richtig den Pointer des Vectors?

    nein particle hat keinen copy ctor, worfür bräuchte man den hier ?

    Wenn du ihn nicht explizit abgeschafft hast, hat 'particle' einen Copy-Ctor. Das Problem ist, daß dieser vom Compiler bereitgestellte CCtor nicht immer korrekt funktioniert (der erzeugt eine flache Kopie aller Member - und wenn du irgendwelche dynamisch verwalteten Daten hast, erzeugst du dir damit nur Probleme*).

    * im Extremfall werden die Daten doppelt freigegeben, was zum Zusammenbruch des Heap führen kann.

    0
  • G

    Gleich mal ausprobieren, hatte eben auch das Problem das das pushen von eigenen Objekten zu Speicherfehlern führte.

    Dynamisch ist dort nur ein Vektor der eben Objekte der Besitzerklassses aufnehmen kann.

    class Hud {

std::vector<Hud> Kinder;
public:
void insert(Hud Kind){ this->Kinder.push_back(Kind);};
}

    wäre dies ein solcher Fall für nen eigenen CCtor? Oder liegt hier das Problem eher darin das sich dieKatze in den Schwanz beisst

    0
  • B

    genau , und diese vector muss du über den kopy Konstruktor kopieren (Tiefe kopie)?

    Ich frage mich allerding wie sieht der Automatisch Kopierte Kopy C-Tor von "hud" aus?

    Wenn er so aussieht, müssten die objekt ohne weiterere automatisch kopiert werden ??

    Hud::Hud(const Hud & oScr){

 this->Kinder = oScr.Kinder;

}
    0
  • M

    Wenn Hud wirklich nichts weiter enthält, braucht es keinen besonderen Copy-CTor, weil der automatisch generierte das Richtige tut.

    0
  • C

    GreyHound schrieb:

    wäre dies ein solcher Fall für nen eigenen CCtor? Oder liegt hier das Problem eher darin das sich dieKatze in den Schwanz beisst

    In dem Fall kommst du mit dem impliziten CTor völlig aus (der vector<> enthält zwar dynamische Daten, aber das ist sein Problem).

    0
  • B

    aha, dann sieht der Autmoatisch genierierte quaise immer so aus:

    Klasse::Klasse(const Klasse &oQuelle){

this->V_1= oQuelle.V_1;
this->V_2= oQuelle.V_2;
this->V_3= oQuelle.V_3;
.
.
.
.
this->V_N= oQuelle.V_N;

    }

    0
  • P

    BorisDieKlinge schrieb:

    aha, dann sieht der Autmoatisch genierierte quaise immer so aus:

    Klasse::Klasse(const Klasse &oQuelle){

this->V_1= oQuelle.V_1;
this->V_2= oQuelle.V_2;
this->V_3= oQuelle.V_3;
.
.
.
.
this->V_N= oQuelle.V_N;

    }

    hm wie würde denn der copy ctor hierfür aussehen?

    class Particle
{
public:
	//contructor
	Particle( SDL_Surface *img, Vektor *grav, Uint32 bgColor, int lifeTime = 0, double xpos = 0, double ypos = 0, double xvel = 0, double yvel = 0);

	const Particle& operator=(const Particle &right);
	void addFadeStruct(fadeStruct fs);
	void move(SDL_Surface *surf);
	SDL_Surface* getSprite();
	//dtor
	virtual ~Particle();

	//x,y, gravity, alive vals usw.
	Vektor position;
	Vektor velocity;
	Vektor *gravity;
	bool alive;
	Uint32 bgColor;
private:
	SDL_Surface *sprite;
	int spawntime;
	int lifetime;
	Uint32 replaceColor;
	bool hasFadeStruct;
	fadeStruct fade;
	Uint32 *sprPixels;

};

    kann ich praktisch den operator= kopieren und den funktionskopf anpassen ?

    0
  • C

    @Boris: Praktisch ja - technisch läuft das eher auf Initialisierungslisten hinaus:

    Klasse::Klasse(const Klasse& src)
: Basis(src)
, V_1(src.V_1)
,
...
, V_N(src.V_N)
{}

    @pixartist: op= hat etwas andere Anforderungen als der CCtor (unter anderem braucht letzterer keinen Test auf Selbstzuweisung und muß die alten Objektdaten nicht freigeben).

    0
  • P

    CStoll schrieb:

    @Boris: Praktisch ja - technisch läuft das eher auf Initialisierungslisten hinaus:

    Klasse::Klasse(const Klasse& src)
: Basis(src)
, V_1(src.V_1)
,
...
, V_N(src.V_N)
{}

    @pixartist: op= hat etwas andere Anforderungen als der CCtor (unter anderem braucht letzterer keinen Test auf Selbstzuweisung und muß die alten Objektdaten nicht freigeben).

    hmm, wieso kann ich eigentlich beim operator= auf private's vom parameter zugreifen ? (und geht das auch beim copy ctor? )

    was sind die anderen "anderen anforderungen" ?

    0
  • B
     

    class Particle 
{ 
public: 
    //contructor 
    Particle( SDL_Surface *img, Vektor *grav, Uint32 bgColor, int lifeTime = 0, double xpos = 0, double ypos = 0, double xvel = 0, double yvel = 0); 

    const Particle& operator=(const Particle &right); 
    void addFadeStruct(fadeStruct fs); 
    void move(SDL_Surface *surf); 
    SDL_Surface* getSprite(); 
    //dtor 
    virtual ~Particle(); 

    //x,y, gravity, alive vals usw. 
    Vektor position; //<-- Tiefe Kopie
    Vektor velocity; //<-- Tiefe Kopie
    Vektor *gravity;  // <-- inhalt des Pointers für das neue Objekt mit new anlegen

    bool alive; //<-- einfach zuweisung
    Uint32 bgColor; //<-- einfach zuweisung
private: 
    SDL_Surface *sprite; // <-- inhalt des Pointers für das neue Objekt mit new anlegen

    int spawntime; //<-- einfach zuweisung
    int lifetime; //<-- einfach zuweisung
    Uint32 replaceColor; //<-- einfach zuweisung
    bool hasFadeStruct;   //<-- einfach zuweisung
    fadeStruct fade; //<-- einfach zuweisung (jenachdem was da drin ist)
    Uint32 *sprPixels; // <-- inhalt des Pointers für das neue Objekt mit new anlegen

};

    bei einem Poibnter komm es drauf an ob du für jede Instanz ein Objekt anlegen muss und dese npointer speicherst, oder ob du über den pointer ein externe Objekt referenzierst!

    0
  • C

    Erstens: private gilt auf Klassenebene, nicht auf Objektebene.

    Zweitens: Der Copy-Ctor erzeugt eine Kopie aus dem Nichts, der op= ersetzt ein bestehendes Objekt - das sind schon ganz andere Arbeitsbedingungen. Das bedeutet auch, daß der Copy-Ctor keine Tests auf Selbstzuweisung durchführen muß (this ist immer ein jungfräuliches Objekt) und auch keine Alt-Daten entsorgen muß.

    0
  • G

    Ich werde es wohl ausprobieren müssen. 😛
    Ausserdem ist der Grundansatz wohl eher ungeignet da sich auf die Art den Juds nur Kinder zugewiesen können bevor sie selbst in ein übergeordneten Hud gesteckt werden.

    0
  • P

    ähh was soll denn das jetzt ?

    __thiscall Particle::Particle(class Particle const &)" (??0Particle@@QAE@ABV0@@Z) bereits in Particle.obj definiert

    0
Anmelden zum Antworten