Two more comments on extrusive containers: -> Instead of changing functions passing the address of the container, the traits can define a function called "get_external_traits()" or similar that the container will call before using the trait if the corresponding option is activated (code not compiled, so it might contain errors): //Predeclaration struct external_value_traits; //Internal traits struct internal_value_traits { typedef external_value_traits external_traits; //Suppose external_value_traits is derived //from the container template<class C> static const external_traits *get_external_traits(const C &c) { return static_cast<RealTraits>(c); } }; so we can have something like this: typedef list_options < value_traits<internal_value_traits> , external_value_traits<true>
::type options;
typedef list<T, options> MyList; struct external_value_traits : public MyList { //... snode_ptr to_node_ptr (value_type &value) { //whatever conversion using any external auxiliary data } } -> If external traits are used (for example, external value traits) iterator should be also modified adding an additional pointer pointing to the container (so that the iterator can have access to the external traits to make conversions). I still don't know how can this impact some operations like merging, etc... So external traits look exciting but they might require a bit of work to avoid any overhead to users not activating those advanced options. Regards, Ion