Bei einer Liste gibt es aber auch die Möglichkeit, den previous- und den next-container direkt im Objekt zu halten, das in der Liste drin ist. Das kann Vorteile haben, weil man beispielsweise wenn man schon einen Zeiger auf das Objekt hat auch direkt an der entsprechenden Position in der Liste ist und das Element zum Beispiel entfernen kann. Allerdings werden die Objekte halt durch den Container modifiziert. Daher eben der Begriff intrusive -- eingreifend, wie Ajaw schon gesagt hat.

der Begriff wird oftmals im Zusammenhang mit Container gebraucht. Ein non-intrusive Container legt seine Daten zur Verwaltung des Containers außerhalb seiner Elemente ab. So beispielsweise alle STL-Container.

Nenn mich klugscheisser, aber es ist ausserhalb der deklaration der elemente, nicht ausserhalb des instanzierten elements.

@Topic:
non-intrusive wird meist als saubere art empfunden, weil man dabei nicht in die bestehenden implementierungen eingreifft. sauber deswegen, weil man zum einen die element-deklarationen (also CFoo gegen CBar) tauschen kann, als auch neue kontainer anwenden kann ohne fuer jeden container-typen die objekte zu modifizieren.

Jester schrieb:

der Begriff wird oftmals im Zusammenhang mit Container gebraucht. Ein non-intrusive Container legt seine Daten zur Verwaltung des Containers außerhalb seiner Elemente ab. So beispielsweise alle STL-Container.

Nenn mich klugscheisser, aber es ist ausserhalb der deklaration der elemente, nicht ausserhalb des instanzierten elements.

Den Einwand verstehe ich nicht. Wenn ich eine std::list<Foobar> anlege, dann werden die Daten zur Verwaltung der Liste außerhalb meiner Foobar-Objekte abgelegt. Diese verändern sich nicht, bloß weil sich die Struktur der Liste verändert. Das ist auch außerhalb der instanziierten Listenelemente. Aber vermutlich meintest du was anderes, oder?

@Topic:
non-intrusive wird meist als saubere art empfunden, weil man dabei nicht in die bestehenden implementierungen eingreifft.

Ja, es hat ein bißchen diesen "ist-sauber"-touch. Andererseits kann man mit ner intrusive list tolle sachen machen, die man anders nicht hinkriegt. Besonders für komplexere Datenstrukturen kommt man häufig nur mit großem Speicheraufwand (und damit auch schlechterer Laufzeit) um eine intrusive Implementierung herum.

sauber deswegen, weil man zum einen die element-deklarationen (also CFoo gegen CBar) tauschen kann, als auch neue kontainer anwenden kann ohne fuer jeden container-typen die objekte zu modifizieren.

Naja, das stimmt ja so auch nicht ganz. std::vector ist zwar nicht intrusive, verlangt aber auch bestimmte Verhaltensweisen von den Objekten, die darin gespeichert werden können. Implementiert man diese zugegebenermaßen recht allgemeine Schnittstelle nicht richtig, dann funktioniert auch ein non-intrusive Container nicht mit den Elementen. Daher liegt für mich der Unterschied eher darin, wo die zur Verwaltung des Containers nötigen Daten liegen.

Nenn mich klugscheisser, aber es ist ausserhalb der deklaration der elemente, nicht ausserhalb des instanzierten elements.

Hm?

+------+   +-------+   +------+
  | list |-->| node  |-->| data |
  +------+   | next* |   +------+
             | prev* |
             +-------+

v.

+------+   +-------+
  | list |-->| data  |
  +------+   | next* |
             | prev* |
             +-------+

rapso schrieb:

Jester schrieb:

der Begriff wird oftmals im Zusammenhang mit Container gebraucht. Ein non-intrusive Container legt seine Daten zur Verwaltung des Containers außerhalb seiner Elemente ab. So beispielsweise alle STL-Container.

Nenn mich klugscheisser, aber es ist ausserhalb der deklaration der elemente, nicht ausserhalb des instanzierten elements.

Den Einwand verstehe ich nicht. Wenn ich eine std::list<Foobar> anlege, dann werden die Daten zur Verwaltung der Liste außerhalb meiner Foobar-Objekte abgelegt. Diese verändern sich nicht, bloß weil sich die Struktur der Liste verändert. Das ist auch außerhalb der instanziierten Listenelemente. Aber vermutlich meintest du was anderes, oder?

ich meine, dass man mit c++ auch konstrukte erstellen kann, bei denen die verlinkungspointer und das zu handlende element ein 'verschmolzenes' objekt sind. Die programmierung ist dann non-intrusive, das resultat ist aber als ob es 'intrusive' waere.
non-intrusive verwendet man wegen der 'sauberkeit' im design. intrusive verwendet man wegen besserem laufzeitverhalten. beides zu nutzen ist da natuerlich die kroenung des ganzen

und bezueglich std::vector, ich denke es gibt wohl keinen container der ueberhaupt keine anforderungen an die verwalteten objekte setzt. dann steht man aber vor der entscheidung, ob man non-instrusive bleibt, oder ob man 'mal eben was einhackt'. *hehe*

ich meine, dass man mit c++ auch konstrukte erstellen kann, bei denen die verlinkungspointer und das zu handlende element ein 'verschmolzenes' objekt sind. Die programmierung ist dann non-intrusive, das resultat ist aber als ob es 'intrusive' waere.

Z.B.?

Das Dokument geht übrigens auf Templates und Polymorphy ein und es wird das Zeil diskutiert, beides in einem vereinen zu können. Anscheinend mit den ConceptC++. Habs mir aber noch nicht richtig angeschaut.

Wen ein ausführlicheres Dokument dazu interessiert:
http://www.emarcus.org/papers/MPOOL2007-marcus.pdf

Ich wäre immer noch an den C++-Insider-Tricks interessiert