ich benutze etwa folgenden Code um ein vector<template> objekt zu erzeugen:
[c++]
#include <vector>

using namespace std;

vector<templ> * _liste = new vector<templ>(50);
[/c++]

Wenn ich mir _liste nun anschaue, fällt mir auf, dass der Konstruktor von templ nur einmal aufgerufen wurde und dann nur noch kopiert wurde.

Was muss ich schreiben, damit der Konstruktor für jedes Element (0-49) den Konstruktor für templ aufruft?

MfG
Scarabol

2. wieso willst du, dass der ctor aufgerufen wird? es gibt keine ctor-überladung, die n-mal den ctor aufruft.

müsstest also nen leeren vector erzeugen und 50x push_back mit templ() als paramter nutzen.
alle anderen ctors rufen nur den copy-ctor auf.
da das objekt aber so und so kopierbar sein muss, spricht doch auch nichts gegen ein kopieren anstatt des konstruierens!?

bb

Scarabol schrieb:

vector<templ> * _liste = new vector<templ>(50);

Komisches Beispiel. Warum Zeiger/new?

Bsp:

objektliste = new list<objekt>;

MfG
Scarabol

MfG
Scarabol

#include <vector>

using namespace std;

vector<templ> * _liste = new vector<templ>(50);

Dieser Code ist ziemlich sinnlos. Entweder C Array oder std::vector

ich vermute das problem aber auch an einer anderen stelle.

bb

öhm also im Standard Konstruktor meiner Klasse wird eine objekt vom Typ list<templ2> erzeugt, dass aber nach der oben beschriebenen Methode für alle Elemente von _liste gleich ist, aber nicht gleich sein sollte.

Bsp:

objektliste = new list<objekt>;

Sag' ich doch. Klasse falsch entworfen. Das mit dem new gewöhnste Dir mal ganz schnell ab.

Es kann doch so einfach sein:

class object
{
public:
  int blah;
  explicit object(int j=0) : blah(j) {}
};

class dings
{
  list<object> objliste;
public:
  void hau_rein(object const& o);
};

void dings::hau_rein(object const& o)
{
  objliste.push_back(o);
}

int main()
{
  vector<dings> vec (50);
  vec[12].hau_rein(object(1729));
}

Wenn Du nicht willst, dass mehrere Objekte einer Klasse Zeiger besitzen, die auf das gleiche Zeigen, dann definiere Dir Deinen eigenen Kopierkonstruktor und Zuweisungsoperator oder "schalte sie ab", indem Du sie als privat deklarierst (und gar nicht erst definierst).

kk

class templ {
public:
  templ() : objektliste(new std::list<objekt>()) { }

private:
  std::list<objekt> *objektliste;
};

schlicht

class templ {
public:
  // ...

private:
  std::list<objekt> objektliste;
};

schreiben solltest.

Der Grund, warum std::vector Kopien macht, ist übrigens, dass std::vectors betreffender Konstruktor so aussieht:

explicit vector(size_type n, const T& value = T(), const Allocator& = Allocator());

...also

std::vector<templ> liste(50); // _liste ist ein reservierter Bezeichner!

das selbe bedeutet wie

std::vector<templ> liste(50, templ(), std::allocator<templ>());

und dementsprechend beim Aufruf ein temporäres Objekt erzeugt wird, das dann in alle Steckplätze des Vektors kopiert wird.

wenn ich:

class templ {
public:
  // ...

private:
  std::list<objekt> objektliste;
};

schreibe.

Meckert der Compiler:
"Instanz von abstrakter Klasse, bla bla bla..."
Diesen Umstand (abstrakte Klasse) kann ich auch leider nicht beheben, da die Klasse zu der Grafikengine (Irrlicht) gehört, die ich benutze.

MfG
Scarabol

Dann wirst du wohl so etwas hier brauchen:

class templ {
public:
  // ...

private:
  std::list<objekt*> objektliste;
};

class templ {
public:
  // ...
private:
  std::list<objekt> objektliste;
};

schreibe, meckert der Compiler:
"Instanz von abstrakter Klasse, bla bla bla..."

Das eine hat mit dem anderen nichts zu tun. Uns ging es um die Liste als echtes Datenelement Deiner templ-Klasse im Gegensatz zu einem Zeiger auf eine Liste als Datenelement.

Wenn jetzt "objekt" an sich abstrakt ist, funktioniert weder das eine noch das andere:

class templ {
public:
  // ...
private:
  std::list<objekt>* zeiger_auf_objektliste;
};

MfG
Scarabol

Versteh ich das jetzt richtig?

Edit Frage 2:
Ich habe eine Klasse, die den Pointer auf eine abstrakte Klasse als Member hat.
Wenn ich jetzt den Ctor definieren möchte, sollte der Pointer nicht nur kopiert werden sondern auch das Objekt auf das er evtl. zeigt.
Nur wie stell ich das an?
Wenn ich versuche

myklasse::myklasse(const myklasse& k)
{
_pointer_auf_abstrakt = new abstrakteKlasse(*k._pointer_auf_abstrakt);
}

Meint der Compiler "Instanz von abstrakter Klasse kann nicht erstellt werden."

MfG
Scarabol

Der üblichste, mir bekannte solche Mechanismus wäre eine virtuelle Klon-Funktion in der Basisklasse, die dann in jeder abgeleiteten Klasse überschrieben wird.
Die Klon-Funktion gibt dir als Returnwert einen Basisklassen-Zeiger auf das kopierte, vollständige Objekt.

Verwendung ist dann hübsch einfach:

myklasse::myklasse(const myklasse& k)
{
    _pointer_auf_abstrakt = k._pointer_auf_abstrakt->Clone();
}

Nur frage ich mich gerade, wieso du Objekte der Grafikengine kopieren willst/musst.

BTW: wenn es sich um Texturen/Meshes o.ä. handelt, dann kannst du die normalerweise "kopieren" indem du einfach ein neues Objekt über die Factory-Funktion der Engine erzeugst, und dann den Inhalt rüberkopierst.

Quasi (sinngemäss)

MyTexture::MyTexture(MyTexture const& other)
{
    // neue Textur anlegen
    Size const size = other.m_engineTexture->GetSize();
    m_engineTexture = other.m_engineTexture->GetEngine()->CreateTexture(
        size,
        other.m_engineTexture->GetPixelFormat());

    // Daten rüberkopieren
    m_engineTexture->UpdateRect(Rect(Point(0, 0), size), other.m_engineTexture, Point(0, 0));
    // oder wie auch immer man die Pixeldaten von einer Textur in eine andere kopiert
}

Um bspw. die Skybox zu kopieren bzw. nach deiner Methode neu zu erzeugen sind einige Parameter notwendig, genau wie für andere Objekte. Daher müsste ich in fast alle meiner klassen dafür extra private Member zusätzlich definieren (Overhead).

Ich schau mal nach einer Klon Funktion...
Edit:
Die Engine hat tatsächlich für einige abstrakte Objekte eine clone Funktion. Leider kopiert die aber nicht das komplette Objekt sondern nur den Teil der geerbt wurde. Hilft mir also nicht weiter....

MfG
Scarabol

Ich MUSS die Daten ja nicht kopieren, aber ein guter Kopierkonstruktor setzt voraus das ich es mache, oder?

Wieso willst du kopieren?
Wieso meinst du dass du einen Copy-Ctor brauchst?

MfG
Scarabol

Nimm nen Pointer-Container, oder nen vector<shared_ptr<T>> .

MfG
Scarabol

Wenn Dir das zu teuer ist, solltest Du ptr_vector<T> nehmen (der zerstört deine Objekte am Ende wieder) oder vector<shared_ptr<T>>, wenn Du T noch außerhalb der Klasse nutzt, es aber keine zentrale Instanz gibt, welche verantwortlich für die Zerstörung ist (oder wenn ptr_vector<T> aus irgendeinem Grund nicht unterstützt wird). vector<T*> ist auch in Ordnung, wenn der vector nicht verantwortlich für die Zerstörung sein soll.

hustbaer:
Wieso findest Du das denn so schlimm?

Warum?

Weil es Symptombekämpfung ist.
Weil es schlechter Stil ist, und er sich sowas gar nicht angewöhnen sollte.
Weil er sich damit weitere Probleme schafft, die man vermutlich wieder nur mit unsauberen Hacks lösen kann, was wieder zu Problemen führt uswusf.

Warum ich das alles denke?

Weil für mich Texturen ganz klar eine Identität haben, also "class types" und keine "value types" sind. Und die haben in einem Vektor nunmal nix verloren, da ein Vektor Objekte "by value" kopiert (und das nicht nur beim erstmaligen Einfügen!), und damit ihre Identität vernichtet.

Alle mir bekannten 3D APIs arbeiten mit Referenzen (Zeigern, Smart-Pointern etc.) auf Texturen. Wenn ich eine Textur in einen Texture-Slot stecke, dann stecke ich da den Zeiger rein, die eigentliche Textur (der "Wert") wird dabei nicht kopiert. Das selbe gilt für Render-Targets.

Wenn sich nun aber die Adresse der Textur ändern kann, dann gibt's Probleme. Die Textur könnte gerade als Render-Target ausgewält sein, oder in einem Texture-Slot stecken. Wenn man dann rendert wird nicht die "neue" Textur bzw. das "neue" Render-Target verwendet, das nach z.b. einer Reallokation im Vektor steckt, sondern die alte, die ursprünglich dem 3D Device übergeben wurde. Das führt dann im Ideallfall zu Grafikfehlern und schlimmstenfalls zu Abstürzen.

Auch wird es dadurch unmöglich, irgendwo Referenzen auf die Textur zu halten. z.B. in irgendwelchen Game-Objekten. Man müsste stattdessen mit irgendwelchen IDs/Indexen/... arbeiten, und sich die Textur jedes mal wenn man sie braucht über diese IDs/... holen. D.h. man bastelt sich die Referenz-Semantik nach, die man gerade vernichtet hat, indem man den falschen Container verwendet hat.

Und das alles nur um std::vector<T> statt boost::ptr_vector<T> oder std::vector<std::tr1::shared_ptr<T>> verwenden zu können.

Und da ich mir keine Vorteile vorstellen kann, die die oben skizzierten Probleme aufwiegen, halte ich das für Murks.

----

Ansonsten, etwas allgemeiner: auch wenn es sich um teuer zu kopierende "value types" handelt halte ich std::vector<T> für unpassend. Und zwar weil jedes eingefügte Objekt im Schnitt 2-3 mal kopiert wird (vorausgesetzt dass man nie Elemente löscht). 1x beim Einfügen selbst, und weitere ~~ 1-2 mal (je nach Vektor-Implementierung) durch das "Umkopieren" wenn der Vektor wächst. Da das beim Fenster hinausgeworfene Rechenzeit ist, halte ich es für schlecht. Vor allem wenn man sich keine Vorteile dadurch erkauft. Und was für Vorteile ein Vektor im Vergleich zu einem Pointer-Vektor bei teuer zu kopierenden Elementen haben könnte, weiss ich nicht. Falls dir einer einfällt, lass es mich wissen

Nagut, also bei Grafikengines ist es ja nun so, dass hin und wieder auch die Grafikbibliothek das eigentliche Speichern uebernimmt. Deswegen stecke ich meine Textur sehr wohl in eine map, weil die aber auch nur die ID haelt, ueber welche OpenGL angesprochen werden kann.

Gut, sobald Objekte in einen Renderzyklus gelangen oder von mehr als einer Seite via Zeiger angesprochen werden muessen, ist der Zeiger natuerlich klar.

Rein aus Interesse jetzt Mal als Randthema: Wieso koennte vector etwas umschieben, wenn er waechst? Weil er den Speicher sonst nicht mehr zusammenhaengend speichern kann? Eigentlich bin ich bisher davon ausgegangen, dass vector garantiert, dass darauf gerichtete Zeiger gueltig bleiben, egal, wie man vergroessert.

Vorteile bei Nutzung von automatischen Variablen statt Zeigern gibt es ja genug wie automatische Speicherverwaltung, Entlastung des Heaps ([url="http://c-plusplus.net/forum/viewtopic-var-t-is-274631.html"]in einem anderen Thread[/url], wo es um etwas Aehnliches ging, zeigte sich der ja auch begrenzt) oder direkter Zugriff auf die Variablen ohne Indirektion, was bei der geringen Anzahl von Zugriffen natuerlich vernachlaessigbar sein sollte.

- Und ja, ich habe gelesen, dass Du geschrieben hast, dass es um Vorteile gibt, welche die Nachteile aufwiegen. Darum stimme ich Dir schon zu, dass hier Pointer mehr Sinn machen, wenn man die Textur tatsaechlich in der Klasse speichert, um die Ladezeiten fuer den Benutzer zu verringern.

Die value type und class type-Begriffe sind sehr praktisch, das werde ich mir Mal im Kopf behalten.