You guys are following me? I think we are surrounded by aphonia and I can't tell what needs to be known. Right now shifted_ptr_test2.cpp works perfectly fine with the slightly adapted STL container to smart pointers and using special allocators needed to define all internal characteristics used by the container. We see in shifted_allocator: template <typename T> class shifted_allocator { public: typedef shifted<T> value_type; typedef shifted_ptr<T> pointer; typedef const shifted_ptr<T> const_pointer; ... }; - value_type: being the real concrete type expected by the smart pointer - pointer: defines the node pointer used internaly by the container Hence this leaves us with opened door yet to be defined. The following member functions, parameters and return type are correct but their implementation are questionnable. Right now this implemenation is brute force and expect type T having a default constructor but this is not exactly what we want. The commented version would be what we are looking for but creates ugly temporaries, therefore some different approach needs to be taken: template <typename T> class shifted_allocator { ... value_type * allocate(size_type s, const void * = 0) { //value_type * p = (value_type *) value_type::operator new(sizeof(value_type)); value_type * p = new value_type(); return p; } void deallocate(pointer & p, size_type) { } void construct(value_type * p, const T & x) { //::new (p) owned_base; //::new (p->element()) T(x); } void destroy(pointer & p) { p.reset(); } }; Thanks, -Phil "Phil Bouchard" <philippe@fornux.com> wrote in message news:g779rk$78a$1@ger.gmane.org...
Ok, this is awesome. Last week I made changes in the Sandbox I had to revert and rework all over... Now the changes I made in both the pointer and the STL containers are clearly to ones I want to stick with. This brings up interesting concepts at the same time, such as: what should be the right parameter of allocator::deallocate() ? We can't use a raw pointer over there. We can see the non-official patch inside the bits folder and shifted_allocator.hpp which I think solves the problem correctly. Furthermore allocator::allocate() I beleive shouldn't return yet a smart pointer because it creates unnecessary temporaries which can be costly, depending on the smart pointer used. So the typedefs inside shifted_allocator are the way I think they should be understood by the containers...
Thanks, -Phil
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost