public: // modifiers         
        std::pair<iterator,bool>  insert( key_type& k, T* x );                         
        template< class U >
        std::pair<iterator,bool>  insert( const key_type& k, std::auto_ptr<U> x );

Warum wurde die Schnittstelle gegenüber std::map derart verändert? Und was soll die Referenz auf key_type& bei der ersten insert() -Überladung? Gibt es einen Grund, dass man keine temporären Objekte als Schlüssel übergeben darf?

Auch Debugging wird zur Hölle, da man etwa sieben Indirektionen hat, bis man nur zum Pair kommt und dann merkt, dass man gar nicht auf den second -Teil zugreifen kann, weil dort ein void* verwendet wurde. Sehr sauber, von Boost hätte ich mehr erwartet. Und weshalb existiert eigentlich die Indirektion über boost::ptr_map_adapter ?

Ich finde es ja nett, dass Boost jede Klasse unter massivem Einsatz von Templates, Hilfsklassen und Adaptoren gestaltet, aber manchmal nervt es echt. Ich hätte es zum Beispiel schön gefunden, wenn boost::ptr_map ähnlich wie std::map einfach aufgebaut wäre. Mindestens soweit möglich ähnliches Interface und eindeutiger value_type . Nein, es muss implementation-defined (bei mir ref_pair ) sein, natürlich mit eigener Semantik. Naja...

Was meint ihr dazu?

Warum wurde die Schnittstelle gegenüber std::map derart verändert? Und was soll die Referenz auf key_type& bei der ersten insert() -Überladung? Gibt es einen Grund, dass man keine temporären Objekte als Schlüssel übergeben darf?

FAQ

Nexus schrieb:

Auch Debugging wird zur Hölle, da man etwa sieben Indirektionen hat, bis man nur zum Pair kommt und dann merkt, dass man gar nicht auf den second -Teil zugreifen kann, weil dort ein void* verwendet wurde. Sehr sauber, von Boost hätte ich mehr erwartet.

Future Developments

Nexus schrieb:

Und weshalb existiert eigentlich die Indirektion über boost::ptr_map_adapter ?

Soweit mir bekannt ist, damit man auf einfache Art und Weise eigene Implementationen realisieren kann. Also ist quasi ein Hilfsmittel.

Nexus schrieb:

Was meint ihr dazu?

Ich bin durchaus der Meinung, dass man gewisse Dinge einfacher hätte machen können. Vor allem das mit dem void* ist mir irgendwie schleierhaft.

Grüssli

FAQ

Danke. Naja, man muss ja alle Fälle abdecken, und Exceptionsicherheit ist einer der wichtigen Punkte bei Pointer-Containern. Dadurch hat man aber teilweise hässlichen Code, weil man jedes kleine Objekt erst deklarieren muss. Für gewisse Variablen muss man sogar const_cast einsetzen, weil eine Non-Const-Referenz erwartet wird. Wieso haben sie nicht gleich const key* genommen? Da würde auch kein Kopierkonstruktor aufgerufen...

Dravere schrieb:

Future Developments
[...]
Vor allem das mit dem void* ist mir irgendwie schleierhaft.

Wirklich. Das Statement ist lustig:

Thorsten Ottosen (Boost-Mensch) schrieb:

There are indications that the void* implementation has a slight performance overhead compared to a T* based implementation. Furthermore, a T* based implementation is so much easier to use type-safely with algorithms. Therefore I anticipate to move to a T* based implementation.

Warum haben sie es nicht schon längst so gemacht? Sieht nicht so aus, als hätte T* Nachteile...

...

Was meint ihr dazu?

Ich hatte die Doku kurz überflogen - fand es ganz interessant, aber konnte der Bibliothek keinen praktischen Nährwert abgewinnen.
Wenn ich schon Pointer in Container packe, dann immer als Smart-Pointer (bei Containern dann natürlich shared_ptr). Oder ich implementiere Klassen mit schwer kopierbarem Inhalt nach dem Bridge-Pattern (heißt das so?) - also die Daten werden auf dem Heap angelegt und die Klasse selbst hält nur genau einen Pointer darauf.

Das hat in beiden Fällen den Vorteil, dass ich die Objekte auch außerhalb des Containers halten kann, ohne mir Sorgen um irgendwelche Memory- und sonstige Leaks zu machen.

Gruß
Werner

Wenn ich schon Pointer in Container packe, dann immer als Smart-Pointer (bei Containern dann natürlich shared_ptr).

shared_ptr ist aber der teuerste Smartpointer (Performance...), so das - sofern nur an einer Stelle die Verwaltung erfolgt, die ptr-Container schon ihren Sinn haben. shared_ptr sind wiederum dann recht gut, wenn man das Objekt an mehreren Stellen hält, und nicht garantieren kann, welche Stelle nun die Speicherverwaltung übernimmt.

Wobei ich auch lieber einheitlich programmiere, und dann eher zum shared_ptr greife (sofern es sich nicht als Flaschenhals erweist).

cu André

Wenn ich schon Pointer in Container packe, dann immer als Smart-Pointer (bei Containern dann natürlich shared_ptr).

So lange haben wir gekämpft dass smart pointer statt rohen zeiger verwendet werden und dann packen die leute überall nur noch shared_ptr hin anstatt nachzudenken. es ist furchtbar.

Weil z.b. man aus einem ptr_container den ptr wieder hinaus bekommt, aber wenn man ihn dann in einen shared_ptr tut, ist der "Rückweg" versperrt, ausser man nutzt clone oder ähnliche Kopiertechniken.

Man sollte auch dazu sagen, das sich ptr_container und shared_ptr/boost::smart_ptr nicht unbedingt vertragen.

Was nie ein Problem darstellt.

Denn entweder hat die map ownership der Zeiger, dann brauche ich keine shared_ptr oder aber die map hat keinen owner ship, dann brauche ich keine ptr_container sondern nehme normale...

So lange haben wir gekämpft dass smart pointer statt rohen zeiger verwendet werden und dann packen die leute überall nur noch shared_ptr hin anstatt nachzudenken. es ist furchtbar.

Hey, ich habe immerhin die Mühe auf mich genommen, mich in ptr_map einzulesen und mich an die spezielle Schnittstelle zu gewöhnen.

Ich benutze auch schon länger andere Pointer-Container, zum Beispiel ptr_vector . shared_ptr brauch ich in Containern eigentlich nur, wenn ich Ownership teile oder Elemente von einem in einen anderen Container verschieben will, was bis jetzt allerdings nicht oft vorkam.

Noch eine Frage: Wenn ich mit BOOST_FOREACH eine ptr_map durchiterieren will, kann ich ja Folgendes tun:

typedef boost::ptr_map<int, std::string> NumberMap;

NumberMap Map;
int a = 4;	// jaja...
int b = 7;
int c = 0;
Map.insert(a, new std::string("vier"));
Map.insert(b, new std::string("sieben"));
Map.insert(c, new std::string("null"));

BOOST_FOREACH(NumberMap::value_type v, Map)
{
	std::cout << v.first << " -> " << *v.second << std::endl;
}

Warum erhalte ich eine Warnung wegen Referenzen auf temporäre Objekte, wenn ich NumberMap::value_type& schreibe? Bei anderen BOOST_FOREACH -Konstrukten ist doch das auch möglich...

Werner Salomon schrieb:

Wenn ich schon Pointer in Container packe, dann immer als Smart-Pointer (bei Containern dann natürlich shared_ptr).

So lange haben wir gekämpft dass smart pointer statt rohen zeiger verwendet werden und dann packen die leute überall nur noch shared_ptr hin anstatt nachzudenken. es ist furchtbar.

Ja - und es hat gar nicht weh getan

Und trotz shared_ptr haben wir auch das Nachdenken nicht aufgegeben! Es hat sich aber auf ein Abstraktionsstufe höher verlegt - so zwischen zyklischen und wandernden Ownerships mit weak_ptr und enable_from_this. Wie das mit rohen Zeigern hinzubekommen ist ... naja vielleicht weiß volkard das?

Gruß
Werner

phlox81 schrieb:

Man sollte auch dazu sagen, das sich ptr_container und shared_ptr/boost::smart_ptr nicht unbedingt vertragen.

Was nie ein Problem darstellt.

Denn entweder hat die map ownership der Zeiger, dann brauche ich keine shared_ptr oder aber die map hat keinen owner ship, dann brauche ich keine ptr_container sondern nehme normale...

Hm, doch doch. Immer dann wenn du unter umständen den Pointer wieder aus der map entfernen willst, ohne ihn zu löschen. Wobei das natürlich dann wiederum so sein kann das man ihn in einen weiteren ptr_container tut.
Wollte mal für ein undo/redo einen boost::circular_buffer<shared_ptr<T> > machen, das verträgt sich aber nicht, wenn man den aus einem/meheren ptr_containern füttert.

BOOST_FOREACH(NumberMap::value_type& v, Map) // hier mit Referenz
{ 
    std::cout << v.first << " -> " << *v.second << std::endl; 
}

eine Non-Const-Referenz an ein temporäres Objekt bindet? Wenn man BOOST_FOREACH sonst einsetzt, funktioniert das doch auch...

@phlox81,
Das ist aber weniger das Problem von dem ptr_container , sondern eher das Problem vom shared_ptr . Der shared_ptr hat nämlich keine Möglichkeit den Zeiger freizugeben, also sowas wie ein release durchzuführen. Wieso sowas nicht vorhanden ist, steht hier:
http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm#FAQ
(Zweitletzte Frage/Antwort)

Grüssli

PS: Hat einer von euch schon mal angeschaut, was der Präprozessor aus BOOST_FOREACH macht? Komplizierter geht es wohl kaum noch

Dravere schrieb:

PS: Hat einer von euch schon mal angeschaut, was der Präprozessor aus BOOST_FOREACH macht? Komplizierter geht es wohl kaum noch

Mir hat es eigentlich gereicht, dass bei Drüberfahren mit der Maus ein recht grosser und unübersichtlicher Block mit der Makrodefinition kam.

Bei Boost schreiben sie:

BOOST_FOREACH is designed for ease-of-use and efficiency. It [...] makes no calls that are not transparent to the compiler's optimizer. This results in near-optimal code generation; the performance of BOOST_FOREACH is usually within a few percent of the equivalent hand-coded loop.

1. Beim Profilen mit AMD CodeAnalyst habe ich zumindest noch einige Funktionsaufrufe für BOOST_FOREACH entdecken können (auch wenn diese im Verhältnis zum Programm kaum Zeit benötigen), also ganz wegoptimierbar scheint es mir nicht zu sein. Ich hab allerdings auch nicht allzu lange herumprobiert, einfach mit der Standard-Release-Einstellung bei MSVC++.
2. Einige wenige Prozent? Das klingt für mich ehrlich gesagt nicht wie nichts. Klar, in vielen Fällen kommt es nicht drauf an, aber bei performancekritischen Anwendungen wäre ich da eher skeptisch. Aber in der Praxis kann es natürlich wieder ganz anders aussehen...