Re: std::ext STL (was: Re: design doc on alternative pointer support)

["Phil Bouchard" <philippe at fornux dot com>]

"Paolo Carlini" <paolo.carlini@oracle.com> wrote in message 
48A94F42.4050409@oracle.com">news:48A94F42.4050409@oracle.com...
> Phil Bouchard wrote:
>> My allocator is basically made only for my own smart pointer support and 
>> wouldn't make sense using for different purposes.
> I don't know about "your" allocator, but as far as libstdc++-v3 is 
> concerned, I think all the containers can possibly support only C++98 
> conforming allocators, or, maybe, C++0x conforming allocators 
> (when -std=c++0x is used). Of course the pointer typedef can be 
> non-trivial, that's the point. At this late stage I don't think we want to 
> consider the possibility of a new, non-standard type, frankly. Maybe we 
> could have done that say, 2-3 years ago, but given all the changes in the 
> allocator chapter of C++0x isn't the right time to fiddle with something 
> different yet. As a general policy, we want to concentrate on either the 
> current or the new standard.

As far as the next standards are concerned, I think it will create 
corruption if virtual allocator functions are accepted (which is currently 
proposed) and supported for easy interchange of containers using different 
allocators because the parameters will be different.  Let's say we have

namespace std
{
class allocator_implementation
{
    typedef void *          pointer;

    virtual void deallocate(pointer p, size_type) = 0;
    ...
};
}

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

        virtual void deallocate(pointer & p, size_type) // won't override
        {
        }
        ...
    };

But when I think about it I guess it would be possible adding an implicit 
cast operator to type void *.  This way deallocate(void *) will compile 
properly when shifted_ptr is passed to it but the function will not do 
anything as far as shifted_allocator::deallocate(void *) is concerned. 
After the call to deallocate() is made inside the container in question 
we'll have to add an explicit assignment of the pointer to 0 to make sure 
the possible smart pointer is reset.

It's not a big performance loss but I am more worried about the problems 
added by the new virtual allocator functions.  No ideal solutions comes on 
top of my head for this.


-Phil