Re: [boost] Re: boost::shared_ptr interface

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-10-18 10:28:37

David M. Jones wrote:
>
> Thank you for your reply, Peter.
>
> Let me be more specific about the problem I ran into. I am using MSVC 7.1
> and the implementation of the STL that comes with it. When I tried to
> create and use an object of type
>   std::list<int, my_allocator<int> >,
> I received a compiler error because the STL code contains
>   _Myhead = 0;
> where _Myhead is of type
>   my_allocator<node>::pointer (ie. boost::shared_ptr<node>)
> and node is the class that defines the nodes in the linked list.
>
> So the STL is not calling operator=() for a boost::shared_ptr with
> just any pointer type on the right-hand side. In fact, it's not even
> a T* -- it is specially setting it to null.
>
> Are you telling me that this STL implementation is (slightly) invalid? Or
> are you telling me that I should not expect boost::shared_ptr to be a
> valid type for use as a custom allocator::pointer? Or both?
>
> I have read that Scott Meyers (Effective STL; Item 10) says that
> custom allocators should always have
>   typedef T* pointer
> but I have also read that Matt Austern (December 2000 CUJ column)
> says that custom allocators can sometimes be "some pointer-like
> class"; it seems to me that boost:shared_ptr is a "pointer-like
> class".

The Standard says (in Table 32, Allocator requirements) that 
Allocator::pointer must be a "pointer to T", but doesn't go into more 
detail. It is not clear what requirements must a type P meet in order to be 
considered a valid "pointer to T".

The Standard also says in 20/4 that implementations are permitted to assume 
that Allocator::pointer is T*.

20/5 goes on to inform us that implementors are encouraged to support "more 
general memory models" and that in those cases the semantics are 
implementation defined. "Implementation defined" means that they can do 
whatever they choose, as long as it is documented.

So. This STL implementation is valid. It makes an attempt to support 
::pointer types that are not T*. However, it places a requirement on these 
types to support the expression

    p = 0;

which shared_ptr does not.

It is possible to add this capability to shared_ptr, but it's also possible 
to rewrite the STL so that it uses the alternate syntax:

    p = pointer();

thereby relaxing the requirements placed on ::pointer types. From where I 
sit, the second option seems more "correct", but the STL authors may not 
agree.

As to your question:

> Or are you telling me that I should not expect boost::shared_ptr to be a
> valid type for use as a custom allocator::pointer?

Well, I don't know. It might or might not work, depending on how you use it 
and what else implicit requirements the STL has. Try adding

    shared_ptr & operator=(unspecified_bool_type)
    {
        reset();
        return *this;
    }

to your copy of shared_ptr.hpp and see what happens.