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.