Re: smart pointer clarifications

I am currently writting a smart pointer which is reasonnably stable and I
decided supporting allocators for completion because of its increase in
efficiency when the same pool used by containers is shared. I was told=

new standards are being finalized and I am hoping minor but important
changes could be applied before anything else.

To give a quick overview on the current status of this topic, you will fi=

below the latest text relating to allocator member functions (n2641). =

see over there there are no dictinction between the pointer type returned=

allocate() and the pointer type expected by deallocate() and destroy().
This is a big problem because this logic doesn't make sense anymore if sm=

pointers are to be used. Smart pointers are owners of their objects an=

aren't in no way going to give away external access to its object. We =

these functions to use
1) distinct pointer type from the one returned by allocate()
2) make the parameter (pointer) passed as a non-const reference

The latter is necessary to make changes to either the smart pointer itsel=

or the object pointed to in case raw pointer are used. We can see my
personnal implementation here and I would like to propose the following
function signatures:

template <typename T>
    class shifted_allocator
    {
    public:
        typedef shifted<T> value_type;
        typedef shifted_ptr<T> pointer;
        typedef shifted_ptr<const T> const_pointer;

        value_type * allocate(size_type s, const void * = 0);
        void deallocate(pointer & p, size_type);
        void construct(value_type * p, const T & x);
        void destroy(pointer & p);
        ...
    };