Re: [boost] [shifted_ptr] STL support: 99%

From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-08-05 02:22:58

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_at_[hidden]> wrote in message 
news:g779rk$78a$1_at_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
>