struct M {
  std::vector<unsigned char> image;
  M() {}
  M(M& m) { // moving with copy constructor
    image.swap(m.image);
  }

  void operator=(M& m) { // moving with assignment operator
    image.swap(m.image);
    m.image.clear();
  }
};

Um einen Typ T mit std::vector zu benutzen, muss er kopierbar sein. M ist das leider nicht. Was passiert wenn ich es trotzdem mache? Was geht kaputt? Reicht es, einen Containeradapter zu schreiben und alle kaputten Operationen einfach nicht anzubieten? Der Typ M soll beispielsweise in std::priority_queue oder in std::deque benutzt werden.

Als Alternative bietet boost (nur 1.49 verfuegbar) in seiner Containerbibliothek Klassen an, die diese Einschraenkungen nicht besitzen. Gibt es dazu ein Tutorial? Prinzipiell fand ich das Beispiel etwas zu makrolastig. Auch wuerde ich eher auf die C++ Standardbibliothek als auf boost zurueckreifen.

//Non-copyable class
class non_copyable
{
   BOOST_MOVABLE_BUT_NOT_COPYABLE(non_copyable)

   public:
   non_copyable(){}
   non_copyable(BOOST_RV_REF(non_copyable)) {}
   non_copyable& operator=(BOOST_RV_REF(non_copyable)) { return *this; }
};

Welche anderen Alternativen bieten sich?

Der Container std::vector<M> selbst soll niemals kopiert oder sortiert werden (bei std::priority_queue ) wohl nicht vermeidbar.

Erzingen std::priority_queue oder std::queue ebenfalls, dass der Typ kopierbar (im Sinne von: a = b => a == b) sein muss?

Afaik ist Kopierbarkeit mehr oder weniger eine Grundanforderung aller Standardcontainer in C++03 (genaugenommen sind die Anforderungen an den Typen afaik für jede Operation extra definiert, aber ohne Kopierbarkeit wird der Container wohl praktisch nutzlos, zumindest std::vector und vermutlich auch deque, bei list, map oder set kann mal unter Umständen ohne davonkommen).

Edit: Ok, ohne Default Ctor und Copy Assignment könnte man bei list etc. evtl. noch leben, aber ohne Copy Ctor wirds schwer...

Container Adapter bauen

Habe ich ja schon, std::priority_queue und std::queue .

Container wohl praktisch nutzlos

Nun, ich will die Elemente nur in den Container reinpacken und wieder rausholen. Eine Messagequeue halt. Sie soll nicht kopiert werden.

Nun fehlt mir leider das Detailwissen. Bei SGIs STL Beschreibung (Wo sonst steht das vernuenftig?) steht beispielsweise Nur Assignable und nur wenn operator== benutzt wird, dann sollte EqualityComparable sein. Wenn ich == im Beispiel von std::queue<M> nicht benutze, kann ich dann auch sicher sein, dass nicht schlimmes passiert, wenn der darunterliegende Container std::vector<M> ist?

Ziel ist natuerlich, so viel wie moeglich aus der C++ Standardbibliothek nachzunutzen, insbesondere Container (weil Nachrichten als Elemente einfacher selbst zu implementieren sind), und unnoetige Kopieroperationen von Nachrichten zu vermeiden.

g++ 3.3.5

Der ist allerdings schon ziemlich lange EOL.

Aber grundsätzlich erfordern STL-Container in C++03 nicht-destruktive Kopierbarkeit. Wenn du diese verletzt, sind Probleme nicht ausgeschlossen. Allerdings wird es schon schwierig, dass der Code überhaupt kompiliert.

void std::vector<T>::push_back(const T& element)
{
    T copy(element);
    ...
}

std::vector<M> vec;
M obj;              // hat Kopierkonstruktor M::M(M&)
vec.push_back(obj); // keine Kopie von Const-Referenz möglich

Früher habe ich in diesen Fällen oft Boosts Pointer-Container benutzt. Zur Not tuts auch ein std::vector<T*> .

knivil schrieb:

g++ 3.3.5

Der ist allerdings schon ziemlich lange EOL.

Ja, aber leider habe ich keine Wahl. Vielleicht ... mal schauen.

Die Problematik wurde vor allem durch die Speicherung von std::auto_ptr in STL-Containern bekannt. Wenn du danach suchst, findest du genauere Informationen.

Ja, das ist mir bekannt, deswegen frage ich ja. Aber alle haben nur ein std::vector als Beispiel.

Zur Not tuts auch ein std::vector<T*>

Das wird es wohl werden und ich werde dots Vorschlag folgeleisten.