vector hinzufügen ohne objekt zu kopieren (ggf. refcount++)

[_frank_]

krümelkacker schrieb:

frank schrieb:

was ist denn so schlimm, wenn ich das const weglasse?

Wenn Du es bei GetRect weglässt, kannst Du GetRect nur auf einem Objekt aufrufen, wenn Du auch "Schreibzugriff" auf das Objekt hast. Aber warum solltest Du Schreibzugriff haben müssen, nur um das Objekt nach etwas fragen zu können?

ich meinte eigentlich das const beim DrawElement

krümelkacker schrieb:

frank schrieb:

die referenz selbst kann ich doch nicht ändern, sondern nur das Objekt dahinter...und das will ich ja

Wo?

bisher noch nicht, da ich noch keine Setter-Methoden groß drin habe...
Aber meine Befürchtung ist, dass ich irgendwann eine solche Methode habe, wo ich schreibzugriff habe (und brauche) und dann eine solche const-funktion aufrufen muss...
wenn ich da keine Probleme (lässt sich evtl. nur mit const-element aufrufen) bekomme ists ok

nochmals danke, dass du dir so viel Zeit für meine Probleme nimmst...allein auf die Idee mit dem Copy-Constructor zur Fehlersuche wäre ich nicht gekommen.

[_frank_]

eine Frage dazu hätte ich noch...

wie sähe eine Getter-Methode für die unique_ptr<TElement> aus?

unique_ptr<TElement> GetElement(/*std::string name*/ int index) const {return pElements[index];};

und

TElement& GetElement(/*std::string name*/ int index) const {return pElements[index];};

funktionieren nicht...

[Nexus]

Bevor du einfach irgendwas ausprobierst, mach dich mit der Materie vertraut. Schau dir das Konzept von Zeigern genau an (z.B. wann du Dereferenzierung brauchst). Anschliessend schaust du dir die Semantik von unique_ptr an und merkst, dass der Besitz transferiert wird, es also relativ sinnfrei ist, eine const -Methode einen unique_ptr zurückgeben zu lassen.

[_frank_]

ok, da ich weder unique_ptr zurückgeben noch TElement kopieren kann, habe ich es mal so probiert:

TElement& GetElement(/*std::string name*/ int index) const {return *pElements[index];};

funktioniert auch mit folgendem Code:

TElement &e=platine.GetElement(idx);
  e.Rotate(false);

müsste doch stimmen, oder?

habt ihr eine gute (möglichst deutsche) dokumentation zu unique_ptr? was ich so über google gefunden habe, war nicht wirklich verständlich für mich. mein Buch behandelt die STL nur rudimentär und die Smart-Pointer (unique_ptr/shared_ptr/auto_ptr) gar nicht.

[krümelkacker]

Ich habe den Eindruck, dass Du zu wenig von C++ verstehst, als dass dein aktuelles Design irgendwie etwas taugen würde. Beispielsweise zweifel ich ganz stark daran, dass an dieser Stelle der Einsatz von unique_ptr überhaupt sinnvoll ist.

[_frank_]

krümelkacker schrieb:

Ich habe den Eindruck, dass Du zu wenig von C++ verstehst, als dass dein aktuelles Design irgendwie etwas taugen würde.

ich bin noch Anfänger (ist mein 3. größeres Projekt) in C++. ich bin nur hobbymäßiger Programmierer, der nur aus Büchern und dem Netz lernt. C++ verwende ich aktiv seit ca. 2 Jahren. Programmieren allgemein seit ca. 14 Jahren.

weiterhin stammt das Design aus einer anderen Programmiersprache (Delphi). und dieses Design möchte so gut wie möglich 1:1 adaptieren, um die Pflege beider Code-Repos so einfach wie möglich zu halten.

Prinzipell brauche ich
- eine Liste von TElement/TConnection (TList unter delphi => einfache Pointerliste, wo man sich selbst um das Casten und die Speicherverwaltung der Elemente kümmern muss)
- die Elementliste befindet sich in TPlatine
- in TElement befindet sich eine TConnectionList
- dabei muss eine TConnection immer wissen zu welchem TElement sie gehört
- ich möchte von außerhalb (Hauptprogramm) auf die TElement/TConnection-Objekte zugreifen können (lesen und verändern).
- als beste Variante habe ich vector aus der STL verstanden, da ich mich dann nicht um die freigabe der Elemente kümmern muss und die Liste dynamisch wachsen kann, ohne dass ich mich um deren Speicherverwaltung kümmern muss (wie ich es bei einem dynamischen array z.b. müsste)
- standardmäßig kopiert vector das element beim hinzufügen => Pointer auf TElement wird ungültig (Objekt hinter dem Pointer ist ja lokal und wird freigegeben)
- und mit diesem Vorwissen ist dieser Thread entstanden...

krümelkacker schrieb:

Beispielsweise zweifel ich ganz stark daran, dass an dieser Stelle der Einsatz von unique_ptr überhaupt sinnvoll ist.

unique_ptr wurde mir in diesem Thread vorgeschlagen (gut, ich habe nicht alle Einzelheiten meines Vorhabens erwähnt)
wie im letzten Beitrag schon erwähnt sind meine STL-Kenntnisse rudimentär und von unique_ptr (aufgrund fehlender verständlicher Dokumentation) so gut wie gar nicht vorhanden. Was mir bleibt ist nur probieren bzw. anhand eurer Antworten und meinem bisherigem Wissen das umzusetzen (wie der Hinweis mit der Dereferenzierung). Warum ist mein Ansatz denn falsch?
Wenn es Alternativen gibt bin ich offen. vielleicht gibts es auch Möglichkeiten ohne vector...

ich hoffe, ich habe einen Einblick in das verschafft, was ich (nicht) weis und was ich erreichen will.

[_frank_]

da aktuell einige Threads sich mit Pointerlisten beschäftigen...

wäre das nicht eine sinnvolle Option für mein Problem?

so wie ich mir das vorstelle:

vector<TElement*> pElements;

void TPlatine::AddElement(...)
{
  TElement* pE = new TElement(...);
  pElements.push_back(pE);  
}

void TPlatine::DelElement(int index)
{
  delete pElements[index];
  pElements.erase (pElements.begin()+index);
}

TPlatine::~TPlatine()
{
  for (int i=0; i<pElements.size(); ++i)
    delete pElements[i]; 
}

TElement* TPlatine::GetElement(int index)
{
  if ((index >=0) && (index <pElements))
    return pElements[index];
  else
    return NULL;
}

wäre das so ok?

[Ethon]

Ist ok, wenn du eben falls Copy-Ctor und copy-assignment operator= überlädst.

[krümelkacker]

Nein. Das ist keine gute Lösung. Das kann man ganz unabhängig davon sagen, was das ganze werden soll; denn es ist eine manuelle Speicherverwaltung, die Du Dir mit vector<unique_ptr<TElement>> oder boost::ptr_vector<TElement> hättest sparen können.

[_frank_]

@krümelkacker
ich will halt nur ungern etwas machen, wo ich Null-Dokumentation da habe und es daher so gut wie nicht verstehe...meine Herauslösung von TElement war ja auch falsch, ob wohl es funktioniert.

und du hast selbst geschrieben, dass du bezweifelst, dass unique_ptr bei meinem Vorgehen sinnvoll ist...

daher habe ich nach Alternativen gesucht. und auf diese Weise habe ich es in dem Original-Programm (Delphi) gemacht (ohne Speicherlecks).

@ethon
wozu soll ich den Copy-Ctor und = überladen, wenn ich die Elemente nur mit den hier geposteten Methoden bearbeite? Außerhalb der TPlatine-Klasse wird kein Telement erstellt oder freigegeben. das holen der TElement-Objekte läuft nur über Pointer, wo danach auch das Objekt nicht automatisch freigegeben wird (Zugriff dann nur per ->).

ich persönlich habe nichts gegen eine manuelle Speicherverwaltung, wenn der Speicher an den Richtigen Stellen (Destructor der Liste bzw. bei mir TPlatine) UND beim löschen von Elementen freigegeben wird und gleichzeitig der/die Pointer auf das Element (nur in der Liste) vernichtet wird.

[Ethon]

@ethon
wozu soll ich den Copy-Ctor und = überladen, wenn ich die Elemente nur mit den hier geposteten Methoden bearbeite? Außerhalb der TPlatine-Klasse wird kein Telement erstellt oder freigegeben. das holen der TElement-Objekte läuft nur über Pointer, wo danach auch das Objekt nicht automatisch freigegeben wird (Zugriff dann nur per ->).

ich persönlich habe nichts gegen eine manuelle Speicherverwaltung, wenn der Speicher an den Richtigen Stellen (Destructor der Liste bzw. bei mir TPlatine) UND beim löschen von Elementen freigegeben wird und gleichzeitig der/die Pointer auf das Element (nur in der Liste) vernichtet wird.

Naja, ich nehme an es gibt mehrere Objekte vom Typ TPlatine. (Wenn nicht, dann solltest du es sowieso frei implementieren).

Wenn du jetzt irgendwo ein Objekt TPlatine kopierst, dann wird der vector korrekt kopiert, aber die Pointer zeigen logischerweise auf den selben Storage. Wenn jetzt das erste TPlatine Objekt stirbt, ruft es für jedes Objekt im Storage delete auf, von daher wird allen Kopien der Boden unter den Füßen weggerissen.

[_frank_]

Ethon schrieb:

Naja, ich nehme an es gibt mehrere Objekte vom Typ TPlatine. (Wenn nicht, dann solltest du es sowieso frei implementieren).

Wenn du jetzt irgendwo ein Objekt TPlatine kopierst, dann wird der vector korrekt kopiert, aber die Pointer zeigen logischerweise auf den selben Storage. Wenn jetzt das erste TPlatine Objekt stirbt, ruft es für jedes Objekt im Storage delete auf, von daher wird allen Kopien der Boden unter den Füßen weggerissen.

gut zu wissen, aber dieser Fall wird nicht eintreten, da es nur eine TPlatine gibt (Hauptansicht des Programms) und selbst wenn es mehrere TPlatine-Objekte gibt (MDI), wird nix kopiert, sondern einfach eine neue ("leere") Instanz erstellt.

[Ethon]

So wäre eine möglicht elegante Implementierung mit unique_ptr, erfordert nen vernünftigen Compiler, also gcc 4.3 (oder 4.4 ?) oder neuer:

class TPlatine
{
public:
   typedef TElement value_type;

private:
   typedef std::unique_ptr<value_type> value_ptr;
   std::vector<value_ptr> m_storage;

public:
   template<typename... Args>
   void AddElement(Args const&... args)
   {
      m_storage.push_back(value_ptr(new value_type(args...)));
   }

   void DeleteElement(std::size_t index)
   {
      m_storage.erase(m_storage.begin() + index);
   }

   value_type* GetElement(std::size_t index)
   {
      if(index < m_storage.size())
         return m_storage[index].get();
      return nullptr;
   }
};

Kopieren kannst du damit auch nicht, der Compiler würde dir auf die Finger hauen.

da es nur eine TPlatine gibt (Hauptansicht des Programms)

Dann implementiere es doch frei, dann gehst du auf Nummer sicher.

[_frank_]

Ethon schrieb:

So wäre eine möglicht elegante Implementierung mit unique_ptr, erfordert nen vernünftigen Compiler, also gcc 4.3 (oder 4.4 ?) oder neuer:

Danke schonmal, ich schaue den Code mal genau durch und versuche das mal so umzusetzen.

wozu ist diese Zeile da? bis vohin geht die template-definition? Wozu muss ich ein eigenes Template definieren?

template<typename... Args>

sorry, wenn ich so blöd frage, aber mein Buch hat nur einen geringen Teil STL...ist halt ein Anfängerbuch

Hier nochmal der Aufruf mir ein gutes deutsches Buch zu nennen, wo die STL und die smart-Pointer mal richtig erklärt werden

Ethon schrieb:

Dann implementiere es doch frei, dann gehst du auf Nummer sicher.

mit freier Implementierung meinst du die Variante wie du sie oben gepostet hast? oder die mit der manuellen Speicherverwaltung?

[Ethon]

Naja, ein variadisches Template lässt dich beliebig viele Parameter mit beliebigen Typen übergeben. Diese reiche ich an den Konstruktor weiter.
Hat den Hintergrund dass du mit AddElement Objekte mit verschiedenen Konstruktorparametern erzeugen kannst.

Wenn zb TElement die Konstruktoren TElement(), TElement(int, char) und TElement(std::string const&) hat, dann würde im Gegenzug auch

AddElement(), AddElement(3, 'b'), AddElement("test") funktionieren und den passenden Ctor aufrufen.

mit freier Implementierung meinst du die Variante wie du sie oben gepostet hast? oder die mit der manuellen Speicherverwaltung?

Nein, ich dachte eher dass du eine Header-Datei TPlatine.hpp schreibst in der nur die Funktionsköpfe sind und alles andere in eine Sourcefile wandert, also ohne Klassenkapslung etc

[krümelkacker]

frank schrieb:

sorry, wenn ich so blöd frage, aber mein Buch hat nur einen geringen Teil STL...ist halt ein Anfängerbuch

Das schließt sich allerdings nicht aus, also Anfängerbuch + STL. Ich würde sogar behaupten, dass ein gutes Anfängerbuch viel von der STL enthält und diese auch von Anfang an lehrt.

frank schrieb:

Hier nochmal der Aufruf mir ein gutes deutsches Buch zu nennen, wo die STL und die smart-Pointer mal richtig erklärt werden

Also, empfehlenswerte "smart-Pointer" enthält der frühere C++ Standard nicht. Es gibt zwar std::auto_ptr, aber dieser lässt sich leicht falsch benutzen. std::shared_ptr und std::unique_ptr sind C++11 Neuerungen, wobei es shared_ptr schon in std::tr1:: als TR1-Erweiterung gab. std::unique_ptr ist der moderne Ersatz für std::auto_ptr und std::auto_ptr ist nun deprecated. Soweit ich weiß gibt es noch kein deutsches Buch, welches diese neuen Dinge erklärt. Allzu kompliziert sind diese schlauen Zeiger auch nicht. Es sind einfach "besitzergreifende Zeiger". Für die Löschung dessen, worauf sie zeigen, fühlen sie sich verantwortlich.

unique_ptr: Alleiniger Besitzer (in einem "korrekten" Programm kann höchstens ein einziger unique_ptr auf ein bestimmtes Objekt zeigen), ein unique_ptr kann nicht kopiert werden, ist aber "movable" und "swappable", geringer Overhad (Speicher, Laufzeit), der Deleter (das Ding, was das Objekt dann auch löscht) ist Teil des Typs. Wird ein unique_ptr zerstört, wird automatisch das gelöscht, worauf er zeigte.

shared_ptr: Kann sich den Besitz unter mehreren shared_ptr-Objekten teilen. Wird der letzte shared_ptr zerstört, wird das Objekt freigegeben. shared_ptr ist zusätzlich kopierbar und benötigt typischerweise ein etwas höheren Overhead (z.B. Referenzzähler). Der Deleter ist nicht Teil des Typs sondern wird (typischerweise) beim Referenzzähler "versteckt".

weak_ptr: Den braucht man manchmal, um "Referenzzyklen", die bei shared_ptr entstehen könnten, aufzulösen. Ein weak_ptr kann auf etwas zeigen, worauf auch ein anderer shared_ptr zeigt. Ein weak_ptr hält aber das Objekt nicht zusätzlich am Leben. Wenn der letzte shared_ptr gelöscht wurde, wird auch das Objekt gelöscht und übrig gebliebende weak_ptr Instanzen zeigen dann einfach auf nichts mehr, was sich nachträglich noch überprüfen lässt.

Will man ein Objekt und ein dazugehörigen shared_ptr<ObjektTyp> erzeugen, bietet sich std::make_shared an. Hierbei kann das Objekt und der Referenzzähler gleichzeitig in demselben Speicherblock erzeugt werden. Es muss also nur einmal statt zweimal Speicher angefordert werden:

auto sp = make_shared<MeineKlasse>(param1,param2,param3);
sp->foo();

[_frank_]

@ethon
gut, diesen dynamischen Constructor brauche ich da eigentlich nicht...vielleicht bei der TConnection-Klasse...mal schauen
dein code hat mir zumindest den (vermutlich richtigen) Weg gezeigt, das Objekt zurückzugeben (hab ich schon eingebaut)

eine Freie Implementierung ohne die Klassenstruktur würde bei dem Programm definitiv chaotisch werden.
TPlatine ist ja nicht nur eine Containerklasse für die TElement und TConnection-Listen. sondern muss sich auch z.b. um das Zeichnen dieser kümmern, hält das Grafische Element (gtkDrawingArea) und deren Steuerung (offscreen-bitmap,events,...). TElement und TConnection sind eher (fast) nur Datenspeicher, aber auch die sind meiner Meinung nach gut in einer Klasse untergebracht. gerade, wenn zusätliche Methoden kommen (TElement hat bereits Rotate, welches die Ausrichtung des Elements und der Connections umrechnet)

@krümelkacker
Danke für die Erklärung

krümelkacker schrieb:

Das schließt sich allerdings nicht aus, also Anfängerbuch + STL. Ich würde sogar behaupten, dass ein gutes Anfängerbuch viel von der STL enthält und diese auch von Anfang an lehrt.

ich finde da Buch so sehr gut. für Anfänger finde ich die STL (was übder das Buch hinaus geht) sehr verwirrend. In dem Buch werden halt die standard-Templates (vector,map,multimap,list,deque,...) erklärt und wie sie angewendet werden (u.a. auch Iteratoren).
übrigends, hier kannst du reinschauen, was drin ist und wie es erklärt wird: http://www.willemer.de/informatik/cpp/index.htm

was hälsts du von dem Buch: Der C++-Programmierer
hab da mal bisschen rumgesucht...unique_ptr wird behandelt und auch die variadischen templates. sieht nach einem guten Aufbaubuch zu meinem aus...

was bringt mir das swappen bei unique_ptr?
ist die variante mit dem unique_ptr<T>.get() (von ethon) zum Zurückgeben des Elementzeigers korrekt? funktionieren tuts auf alle fälle.

Was meinst du mit den referenzzyklen bei weak_ptr (bzw. von shared_ptr)? kann es sein, dass ein Objekt zu zeitig freigegeben wird (nicht alle Pointer wurden gezählt)?

und wie prüft man, ob ein Objekt noch existiert, wenn der Pointer != NULL ist?
aus meiner Erfahrng kann man das nicht so einfach feststellen. (außer bestimmter zugriff mit exception-handling)

hast du irgendwo im netz ein paar Beispiele für die Verwendung der Smart-Pointer? könnte mir zwar welche suchen, weis aber dann nicht, ob die richtig sind

[krümelkacker]

frank schrieb:

@krümelkacker
Danke für die Erklärung

krümelkacker schrieb:

Das schließt sich allerdings nicht aus, also Anfängerbuch + STL. Ich würde sogar behaupten, dass ein gutes Anfängerbuch viel von der STL enthält und diese auch von Anfang an lehrt.

ich finde da Buch so sehr gut. für Anfänger finde ich die STL (was übder das Buch hinaus geht) sehr verwirrend. In dem Buch werden halt die standard-Templates (vector,map,multimap,list,deque,...) erklärt und wie sie angewendet werden (u.a. auch Iteratoren).
übrigends, hier kannst du reinschauen, was drin ist und wie es erklärt wird: http://www.willemer.de/informatik/cpp/index.htm

Ich habe mir jetzt nur das Inhaltsverzeichnis angesehen, musste aber feststellen, dass die Reihenfolge, in der C++ Mittel (inklusive Dinge aus der Standardbibliothek) beigebracht werden, meiner Meinung nach unvorteilhaft ist. Du wirst erst mit so lästigem low-level Zeugs belästigt und gewöhnst Dir u.U. einen schlechten Stil an.

frank schrieb:

was hälsts du von dem Buch: [Breymann]
hab da mal bisschen rumgesucht...unique_ptr wird behandelt und auch die variadischen templates. sieht nach einem guten Aufbaubuch zu meinem aus...

Ich habe zumindest nichts schlechtes von dem Autor gehört.

frank schrieb:

was bringt mir das swappen bei unique_ptr?

Probier doch mal einen Bubble-Sort auf einem vector<unique_ptr<dings>> laufen zu lassen. Da ist das mit dem swap(vec[i],vec[i+1]); schon sehr praktisch.

frank schrieb:

ist die variante mit dem unique_ptr<T>.get() (von ethon) zum Zurückgeben des Elementzeigers korrekt? funktionieren tuts auf alle fälle.

Ob das "korrekt" ist, kann ich nicht beurteilen. get liefert Dir zumindest einen rohen Zeiger auf das Objekt. Und ein roher Zeiger ist eigentlich nur dann ungeschickt, wenn er Dich zwingt, manuell das zu verwalten, worauf er zeigt (manuelles delete). Da im Vektor aber noch der unique_ptr sitzt, dem das Objekt gehört, hast Du zumindest kein Speicherleck. Allerdings darfst Du diesen rohen Zeiger natürlich nicht weiterverwenden, wenn der unique_ptr das Objekt zerstört hat (via Destruktor oder reset-Funktion). Ich hoffe, das ist klar soweit.

frank schrieb:

Was meinst du mit den referenzzyklen bei weak_ptr (bzw. von shared_ptr)? kann es sein, dass ein Objekt zu zeitig freigegeben wird (nicht alle Pointer wurden gezählt)?

Bissel mehr Eigeninitiative bitte
http://de.wikipedia.org/wiki/Referenzzählung

frank schrieb:

und wie prüft man, ob ein Objekt noch existiert, wenn der Pointer != NULL ist?

Generell: Gar nicht. Mit C++ als "zero overhead language" fehlt dazu der nötige Overhead ..ähm.. Metainformation, um das feststellen zu können. Im Falle von shared_ptr/weak_ptr ist diese "Metainformation" aber vorhanden -- nicht weil der C++ Compiler weak_ptr anders behandelt, sondern weil sich jemand extra darum gekümmert hat: Die, die sich shared_ptr/weak_ptr ausgedacht haben. Mit einem weak_ptr kann man selbst nicht viel anfangen. Du kannst ihn aber in einen shared_ptr konvertieren. Ist das Ergebnis dieser Konvertierung gleich nullptr, wurde das Objekt vorher schon von dem letzten shared_ptr gelöscht.

frank schrieb:

hast du irgendwo im netz ein paar Beispiele für die Verwendung der Smart-Pointer? könnte mir zwar welche suchen, weis aber dann nicht, ob die richtig sind

Nee, habe ich nicht. Ich kann mich auch gerade schwer in Deine Lage versetzen. Die Sache mit den Zeigern ist eigentlich ganz einfach. Was ist denn noch unklar?

kk

[Ethon]

eine Freie Implementierung ohne die Klassenstruktur würde bei dem Programm definitiv chaotisch werden.
TPlatine ist ja nicht nur eine Containerklasse für die TElement und TConnection-Listen. sondern muss sich auch z.b. um das Zeichnen dieser kümmern, hält das Grafische Element (gtkDrawingArea) und deren Steuerung (offscreen-bitmap,events,...). TElement und TConnection sind eher (fast) nur Datenspeicher, aber auch die sind meiner Meinung nach gut in einer Klasse untergebracht. gerade, wenn zusätliche Methoden kommen (TElement hat bereits Rotate, welches die Ausrichtung des Elements und der Connections umrechnet)

Meistens eher leichter aus.

Aus einem

TPlatine platine;
platine.AddElement(1);
platine.AddElement(2);
platine.AddElement(3);
platine.Draw();

würde ein

TPlatineAddElement(1);
TPlatineAddElement(2);
TPlatineAddElement(3);
TPlatineDraw();

werden und du müsstest nirgendwo Instanzen der Klasse verwalten, weil alle benötigten Daten statisch in der Sourcefile alloziert sind.

[_frank_]

krümelkacker schrieb:

Ich habe mir jetzt nur das Inhaltsverzeichnis angesehen, musste aber feststellen, dass die Reihenfolge, in der C++ Mittel (inklusive Dinge aus der Standardbibliothek) beigebracht werden, meiner Meinung nach unvorteilhaft ist. Du wirst erst mit so lästigem low-level Zeugs belästigt und gewöhnst Dir u.U. einen schlechten Stil an.

ich habe bereits unter Delphi viel low-level Zeugs gemacht (weils teilweise keine andere Möglichkeit gab). und für mich ist es einfacher, da ich die hintergründe besser verstehe.
Die problematiken, die normale Pointer mitbringen sind mir natürlich bekannt (gesetzte Zeiger ohne vorhandes Objekt und verwaiste Objekte, die nicht mehr verlinkt sind).

krümelkacker schrieb:

Ich habe zumindest nichts schlechtes von dem Autor gehört.

ok, habe mir das buch mal bestellt...dauert natürlich ne weile, bis ich da einigermaßen eingelesen bin

krümelkacker schrieb:

Die Sache mit den Zeigern ist eigentlich ganz einfach. Was ist denn noch unklar?

Pointer an sich sind schon einfach, aber die Probleme die sich aus der Eigentümer-Funktion der Smartpointer ergeben (std::move) verwirren halt am Anfang...
der swap, kann ich da std::swap nehmen?
Um ein Element zu löschen ist es sinnvoll, einen swap mit dem letzten vectorelement durchzuführen und dann resize? oder doch auf erase-remove zurückgreifen?

@ethon: wie gesagt, TPlatine ist nicht nur die reine Element-Liste, daher habe ich das gleich als Klasse gekapselt. da gehören noch viele Variablen dazu, die ohne klasse global und "ohne Bezug" wären (erst recht wenn dann die Drag&drop-Routinen mit reinkommen), weiterhin lässt sich dann einfacher Platformabhängiger code von Platformunabhängigem code trennen