#include <iostream>
using namespace std;

class ABC
{
public:
    virtual void func()=0;
};

class Foo : public ABC
{
public:
    void func()
    {
        cout << "Ich bin func aus Foo\n";
    }
};

class Bar : public ABC
{
public:
    void func()
    {
        cout << "Ich bin func aus Bar\n";
    }
};

template<typename T>
class Container
{
private:
    T* matrix_[2];  

public:

    Container(ABC* first, ABC* second)
    {
        matrix_[0]=first;
        matrix_[1]=second;
    }

    ~Container()
    {
        delete matrix_[0];
        delete matrix_[1];
    }

    Container(const Container<T>& c)
    {
        //wie implementieren?
    }

    Container operator=(const Container<T>& c)
    {
        //wie implementieren?
        return *this;
    }
};

int main()
{    
    Container<ABC> a(new Foo(), new Bar()),
              b(new Bar(), NULL),
              c(a);

    a=b;

    return 0;
}

Zuweisungoperator:

void oparator=(Container<T> ziel, Container<> quelle)
{
ziel.getMatrix() = quelle.getMAtrix();
//muss natürlich für jeden wieder überladen werden
//und getMAtrix muss ne REferenz zurückgeben, weil es ja private is

etc....
}

jedenfalls vom prinzip her......

1. nutzt du das template nicht, sondern codest den typ ABC fest rein.

Hast natuerlich recht. Ich meine natuerlich

T* matrix_[2];

dev_MAddoX schrieb:

2. geht das?: matrix_[2] ????

warum sollte es nicht?

dev_MAddoX schrieb:

Zuweisungoperator:

void oparator=(Container<T> ziel, Container<> quelle)

Was soll das denn?
Ich will den operator= doch nicht als friend function implementieren.

dev_MAddoX schrieb:

ziel.getMatrix() = quelle.getMAtrix();

Dann wuerde ich nur die Zeiger kopieren und nicht die Objekte.
Aber genau das ist mein Problem, die Matrix zu kopieren.
Ich haette gerne sowas gemacht:

Container operator=(const Container<T>& c)
    {
        if(this == &c) return;

        for(int i=0; i<2; ++i)
            delete matrix_[i];

        for(int i=0; i<2; ++i)
            if(c.matrix[i] == NULL)
                this->matrix_[i] = NULL;            
            else
                this->matrix_[i] = new T(c.matrix_[i]);
        return *this;
    }

Haette glaube ich auch hingehaun(haette es??), waere die Klasse nicht generisch.
Weil ich sie aber mit dem Typ ABC parametrisiert habe(der ja abstrakt ist) funktioniert new T(c.matrix_[i]); schon mal gar nicht.
Hat jemand schonmal sowas gehabt?

thx in advance

Der typ sollte einen vernünftigen assignment-op und copyctor implementieren und dann kannst die benutzen.

const Container &operator=(const Container<T>& c)
    {
        if(this == &c) return;

        *matrix_[0]=c.get_matrix1();  //op= des enthaltenen typen
        *matrix_[1]=c.get_matrix2(); 

        return *this;
    }

Für den copy-ctor genau so.

musst natürlich noch dereferenzieren.

const Container &operator=(const Container<T>& c)
    {
        if(this == &c) return;

        *matrix_[0]=*c.get_matrix1();  //op= des enthaltenen typen
        *matrix_[1]=*c.get_matrix2();

        return *this;
    }

überseh ich jetzt was wesentliches ?

Argh...

musst natürlich noch dereferenzieren.

const Container &operator=(const Container<T>& c)
    {
        if(this == &c) return;
       
        *matrix_[0]=*c.get_matrix1();  //op= des enthaltenen typen
        *matrix_[1]=*c.get_matrix2();

        return *this;
    }

überseh ich jetzt was wesentliches ?

IMHO schon.
Was passiert mit den vorherigen Elementen der Matrix?

*matrix_[0]=*c.get_matrix1();  //op= des enthaltenen typen

Was ist nun mit dem Element, das vorher an *matrix_[0] stand?
Du hast es nicht deleted, also hast du nun ein schoenes memory leak.

Er kopiert keinen speicherbereich sondern , weisst die klasse(ABC in diesem fall) an die werte zuzuweisen. Was ja auch richtig ist weil nur sie weiss wie man das am besten macht.

Container operator=(const Container<T>& c)
    {
        if(this != &c)
        {   
            for(int i=0; i<2; ++i)
                if(c.matrix_[i] == NULL) 
                {
                    delete this->matrix_[i];
                    this->matrix_[i] = NULL;
                }            
                else
                {
                    //Wer sagt mir, dass *this->matrix_[i] != NULL ist?
                    *this->matrix_[i] = *c.matrix_[i];
                }           
        }
        return *this;
    }

Falls mir ein NULL Pointer beim kopieren von einem Containerobjekt A unterkommt, delete ich das Element und setze es auf NULL. Wenn nun auf A erneut der operator= aufgerufen wird, dann schlaegt folgende Anweisung fehl:

//Wer sagt mir, dass *this->matrix_[i] != NULL ist?
                    *this->matrix_[i] = *c.matrix_[i];

//EDIT NOCHMAL ... machst du doch nicht, bleibt dir in diesem fall also nichts übrig als nochmal zu testen, dann würdest du eben ein neues element anlegen müssen, dafür könntest zum beispiel den copy-ctor der klasse benutzen.

if(matrix[i]==NULL)
     matrix[i]=new T(*c.matrix[i]);

Weil ich sie aber mit dem Typ ABC parametrisiert habe(der ja abstrakt ist) funktioniert new T(c.matrix_[i]); schon mal gar nicht.

Dann musst du einen weg finden dass keine NULL-pointer auftauchen.

Finde ich keine befriedigende Loesung
Die NULL Pointer brauche ich, um zu erkennen, ob das Feld meiner Matrix leer ist.
Und immer ein Test mit instanceof find ich auch nicht gut, wenn ich einen leeren Typ anlege.

Das new Problem(matrix[i]=new T(*c.matrix[i]);) wuerde sowieso spaetestens im CopyCtor erneut auftreten, weil ich da auf jeden Fall Speicher anfordern muss.

Container(const Container<T>& c) 
{ 
    for(int i=0; i<2; ++i) 
        this->matrix_[i] = new T(c.matrix_[i]);
}

Angenommen, ich liesse mich auf deinen Vorschlag ein, dann gaebe es aber noch folgendes Problem:

*this->matrix_[i] = *c.matrix_[i];

Diese Technik called immer den operator= von T, also von ABC.
Um dieses Problem zu loesen muesste ich den operator= in ABC virtual definieren.
Das zoege nach sich, dass alle Klassen in meinem Vererbungsgraphen zuweisungskompatible zueinander sind.
Sowas waere also Problemlos moeglich:

class ABC
{
public:
    virtual ABC& operator=(const ABC&){}
};

class KlasseA_dieNichtsMit_B_zuTunHat : public ABC
{
public:
    KlasseA_dieNichtsMit_B_zuTunHat operator=(const KlasseA_dieNichtsMit_B_zuTunHat& A)
    {
        ABC::operator=(A);
    }
};

class KlasseB_dieNichtsMit_A_zuTunHat : public ABC
{
public:
    KlasseB_dieNichtsMit_A_zuTunHat operator=(const KlasseB_dieNichtsMit_A_zuTunHat& B)
    {
        ABC::operator=(B);
    }
};

void sample(ABC& a, ABC& b)
{ a=b;   //unsinnig, aber leider erlaubt }

int main()
{
    KlasseA_dieNichtsMit_B_zuTunHat A;
    KlasseA_dieNichtsMit_B_zuTunHat B;
    sample(A,B);
}

Durch die Namen angedeutet, kann man erkennen, dass KlasseA_dieNichtsMit_B_zuTunHat
und KlasseA_dieNichtsMit_B_zuTunHat nichts miteinander zu tun haben, ausser eine gemeinsame ABC. Trotzdem koennte ich sie einander zuweisen.
In den Klassen meiner Vererbungshierarchie existiert eigentlich kein solcher Isomorphismus, dass ich so etwas wollte.

Im copy-ctor kann man locker mit dem blosen assignment-op der enthaltenen klasse arbeiten. Die erzeugung der objekte wäre dann auch wieder nicht deine aufgaben. Da wäre dann ein

container.insert(new derived());

angebracht.

Und naja ein container soll ja wenn er was enthält auch was enthalten was sinnvoll ist, darum geht es doch gerade. Ich versteh auch nicht warum die beiden abgeleiteten klassen, wenn sie nichts miteinander zu tun haben, dann von der selben basisklasse erben. In diesem moment haben sie was gemeinsam, nämlich die basis. Wenn du das nicht willst dann musst du deinem container eben sagen dass er nicht container der basisklasse ist sondern jeweils einen container für die abgeleiteten klassen instanzieren.

class A{

};

class B : public A{

};

class C : public A{

};

container<A*> container_A_;
container<B*> container_B_;
container<C*> container_C_;

container_A_.insert(new B());
container_A_.insert(new C());

container_B_.insert(new B());
container_C_.insert(new C());

//conatainer_B_=container_C_  schlaegt dann fehl

Oder überseh ich wieder was ?

Hmm ich versteh das problem ehrlich gesagt nicht.

Im copy-ctor kann man locker mit dem blosen assignment-op der enthaltenen klasse arbeiten.

ohne vorher speicher zu allozieren? das wuerde mich sehr wundern, nachdem man mir hier versicherte genau das tun zu muessen.

Die erzeugung der objekte wäre dann auch wieder nicht deine aufgaben. Da wäre dann ein

container.insert(new derived());

Sicher, das wuerde das Problem loesen, wenn ich wuesste, dass ich wirklich gerade ein derived kopiere und nicht ein anderes von ABC abgeleitetes Objekt derived2.
Leider weiss ich aber nicht, welche Instanz ich von meinen 12 von ABC abgeleiteten Klassen gerade kopiere. D.h. es muesste ein Typtest her und der ist ganz sicher nicht im Sinne des Erfinders.

class ABC;
class A : public ABC { /* blablabla */ };
class B : public ABC { /* */};
class C : public ABC...
class D....
...

class Container //enthaelt ABC Objekte
Container(const Container& c)
{
    for(int i=0; i<1000; ++i)            
        if(c.matrix_[i] instanceof A)
            this->matrix_[i] = new A(c.matrix_[i]);
        else if(c.matrix_[i] instanceof B)
            this->matrix_[i] = new B(c.matrix_[i]);
        else if(c.matrix_[i] instanceof C)
            this->matrix_[i] = new C(c.matrix_[i]);
        else if(c.matrix_[i] instanceof D)
            this->matrix_[i] = new D(c.matrix_[i]);
        //und so weiter...

        //ich kann keine Typen nachtraeglich hinzufuegen, ohne eine weitere Verzweigung hinzuzufuegen.
        //gaaanz schlecht!!
}
};

Ich versteh auch nicht warum die beiden abgeleiteten klassen, wenn sie nichts miteinander zu tun haben, dann von der selben basisklasse erben. In diesem moment haben sie was gemeinsam, nämlich die basis.

Nur die Basis. Das heisst noch lange nicht, dass sie den selbem abstrakten Status haben, der fuer einen virtuellen assingnmentOp notwendig waere. Nur weil mehrere Klassen von derselben ABC erben, will ich doch noch lange nicht, dass man sie alle einander gegenseitig zuweisen kann

class Shape
{
protected:
    int x,y;
};

class Square : public Shape { };
class Circle : public Shape { };

void sample(Shape& a, Shape& b)
{ a=b; }

int main()
{
    Square a;
    Circle b;
    sample(a,b); // vollkommen unsinnig!!!
}

Vielleicht verstehe ich dich auch nicht, dann koenntest du dich ja an dem Codefragment probieren, dass ich anfangs gepostet hatte. Waere gespannt auf deine Loesung.

Gehört TGGC eigentlich auch zu den Big Three?

Nein, dafür ist er zu schlecht.

Dass man keine instanz einer abstracten klass erzeugen kann liegt in der natur der c++-dinge, da wirst du nichts dran drehen können. Was du willst ist offensichtlich eine deep-copy-semantic beim op= und copy-ctor. Gut dann musst
du aber dafür sorgen dass du nie mit null-pointern zu tun hast. Weil sonst immer das problem mit der instanzierung der basis auftritt. Der container ist nicht für allocierung bzw. deallocierung verantwortlich. Wenn der container leer ist enthält er kein objekt, wenn er die größe 1 hat dann enthält er eben ein definiertes objekt. Es ist aufgabe des clients dafür zu sorgen dass da ordentliche werte vorhanden sind um damit arbeiten zu können wie ers erwartet.

Kannst du mal sagen warum du diesen weg überhaupt gehst mit dem eigenen container ? Ich meine einen groben umriss des kontexts geben, dass man mal schaun kann ob das nicht auch anders geht ?

Ich würde wahrscheinlich boost::array <basis*> verwenden. Aber es kann ja sein dass das für dich nich ausreicht weil du noch irgendwas besonderes machen willst. Aber vom jetzigen standpunkt aus verschliesst sich mir irgendwie der sinn des ganzen.

Ansonsten kannst du auch einfach ne shallow-copy der zeiger machen, musst halt nur drauf achten dass die zeiger nicht ausversehen durch einen andren container zerstört werden. Deswegen sollte der container auch die elemente nicht im dtor oder ähnliches freigeben. Dafür ist auch der client verantwortlich.

Sry nochmal, das muss frustrierend für dich sein aber probiers doch nochmal genau zu schildern bitte.

ich denke mal HumeSikkins und volkard gehören auf jeden Fall dazu. Aber wer noch?

TGGC

Ok, also wenn du weisst dass du nur abgeleitete klassen verwalten musst dann brauchst du keine templates. Du arbeitest eben mit den basisklassenzeigern.

Gut, dann werde ich meine Klasse ungenerisch machen.

Dass man keine instanz einer abstracten klass erzeugen kann liegt in der natur der c++-dinge, da wirst du nichts dran drehen können. Was du willst ist offensichtlich eine deep-copy-semantic beim op= und copy-ctor.

Ja

Gut dann musst
du aber dafür sorgen dass du nie mit null-pointern zu tun hast. Weil sonst immer das problem mit der instanzierung der basis auftritt

Ich brauchte halt einen Wert, der mir signalisiert, dass in einem Feld kein ABC Objekt vorhanden ist. Der NULL Pointer bot sich IMHO dafuer an.

Der container ist nicht für allocierung bzw. deallocierung verantwortlich.

Wie jetzt? Wer dann? Ich wuesste nicht, wie ich beim CopyCtor um eine Allokation herumkommen koennte.

Kannst du mal sagen warum du diesen weg überhaupt gehst mit dem eigenen container ? Ich meine einen groben umriss des kontexts geben, dass man mal schaun kann ob das nicht auch anders geht ?

Ich brauchte einige spezielle member functions, die kein std container bereitstellt. Meine Container Klasse ist auch nur ganz kurz und eigentlich recht simpel.

Es geht mir im Moment nicht so sehr darum, dass ich ja viel einfacher eine bereits fertige Containerklasse verwenden koennte.
Das eigentliche Problem liegt darin: Ich habe eine Klasse, die ein Attribut vom Typ Zeiger auf ABC hat. Ich habe mich jetzt gefragt, wie ich den CopyCtor und den AssignmentOp zu implementieren habe, um das Attribut zu kopieren, ohne seinen genauen Typ zu wissen(weil ich ja 12 Unterklassen habe) und dabei noch die NULL Pointer angemessen behandeln zu koennen.
std::vector etc koennen das doch auch! Wie machen die das denn?
Mir kommt das Problemm so alltaeglich vor!

wenn ich micht nicht irre passiert bei vectoren von zeigern auch keine tiefe copie. AFAIK werden da nur zeiger kopiert. Deswegen kann der das. Aber das ist ja nicht was du willst. Weil eine veränderung eines elements im einen container eine änderung desselben elements im andren container nach sich ziehen würde.

Ich hab allerdings jetzt auch nicht nachgesehen, also wenn das nicht stimmen sollte möge man mich korrigieren.

Aber eins scheint mir sicher, du kannst keine instanz der basis erzeugen um dann evtl. danach die ableitete klasse tief reinzukopieren. Das musst du irgendwie umgehen.

Man könnte ja zum beispiel sowas überlegen.

class base{
     public:
        explicit base(const bool c=false):concrete_(c){}
        virtual ~base(){}
        virtual void func()=0;
        void concrete(const bool &n){concrete_=n;}
        const bool &concrete() const {return conctrete_;}
    private:
        bool concrete_;
};

class derived : public base{
      public:
          derived(const int v,const int v2) : base(true),v1_(v),v2_(v2) {}
          void func(){}
      private:
          int v1_;
          int v2_;
};

Dann könntest du mit zeigern und tiefen copien in deinem container arbeiten. Und wenn du die werte brauchst müsstest du vorher testen ob concrete true ist oder nicht und entsprechend im einen fall von unsinn ausgehen und im andren von sinnvollen werten.

Falls die Standard Container alle nur triviale CopyCtors und AssignmentOps haben, dann wundert mich gar nichts mehr. Dann ist das ja kein Problem
Ich haette aber nicht gedacht, dass mein Problem doch so subtil ist.

Ich werde da noch n bisschen rumgruebeln...
Dank dir vielmals fuer deine Muehe! thx.

@all: so, jetzt koennt ihr weiter ausdiskutieren, wer der dritte unter den BigThree ist

copy-ctor meiner vector-implementierung:

/**
       *  @brief  %Vector copy constructor.
       *  @param  x  A %vector of identical element and allocator types.
       * 
       *  The newly-created %vector uses a copy of the allocation
       *  object used by @a x.  All the elements of @a x are copied,
       *  but any extra memory in
       *  @a x (for fast expansion) will not be copied.
       */
      vector(const vector& __x)
      : _Base(__x.size(), __x.get_allocator())
      { _M_finish = uninitialized_copy(__x.begin(), __x.end(), _M_start); }

Da werden so wie ich das sehe auch nur zeiger kopiert.

uninitialized_copy würde in deinem fall so aussehen, da du ja mit zeigern also POD-typen arbeitest.

template<typename _InputIter, typename _ForwardIter>
    inline _ForwardIter 
    __uninitialized_copy_aux(_InputIter __first, _InputIter __last,
			     _ForwardIter __result,
			     __true_type)
    { return copy(__first, __last, __result); }

template<typename _InputIter, typename _ForwardIter>
    inline _ForwardIter
    uninitialized_copy(_InputIter __first, _InputIter __last, _ForwardIter __result)
    {
      typedef typename iterator_traits<_ForwardIter>::value_type _ValueType;
      typedef typename __type_traits<_ValueType>::is_POD_type _Is_POD;
      return __uninitialized_copy_aux(__first, __last, __result, _Is_POD());
    }

Es gibt da noch spezialisierungen für char pointer.

Und im dtor steht auch was ich schon sagte.

/**
       *  The dtor only erases the elements, and note that if the elements
       *  themselves are pointers, the pointed-to memory is not touched in any
       *  way.  Managing the pointer is the user's responsibilty.
       */
      ~vector() { _Destroy(_M_start, _M_finish); }

@std.proposal

seit wann dürfen denn ctors virtual sein ? oder meinst du das anders ?