Boost logo

Boost :

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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk