news:uvf8sqwwb.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > | Useful for implementing view-like containers. | > | Get my point? | > | > probably, I think you're suggesting the same as David, that is to | > be able to say ptr_vector< some_type::iterator >, right? | | indirect_vector< some_type::iterator > | | > That is going to be really hard. | | Oh, pshaw. Let me first say that nobody really had this wish during the review, so it hasn't really been a design goal. Is it easy to imagine situations where this is useful? After looking at the code, I don't think I can reuse much code. The design exploits the fact that we assume the stored type to be T* for some T. And this affects exception-safety and speed/safety tradeoffs. What I might do instead is to create some simple wrapper that behaves exactly like container<T>, but with a layer of indirection. The basic design could be something like this template < class T, class CloneAllocator = heap_clone_allocator, // ignored if T is not a pointer class Allocator = std::allocator<T> // or void* if T is a pointer
class indirect_container : public typename mpl::eval_if< is_pointer<T>, ptr_implementation, value_implementation >::type { // some constructors }; a container like indirect_container< shared_ptr<T> > or indirect_container< std::vector<int>::iterator > would then have the exact same exceptions-safety guarantees as their std::container counterparts. This does beg the question what happens if container::iterator is itself a pointer? How do we select which container to use? indirect_container< no_ownership<T> > ? indirect_container< T, view_clone_allocator > ? Another thorn is that the class would basically have two unused template parameters when we just want the indirect behavior. In some sense it seems like we're trying to cram two different classes into one. The indirect behavior could be provided by one (or three) containers of the form template< class Sequence > indirect_sequence; template< class Set > indirect_set; template< class Map > indirect_map; This might belong in a different library. -Thorsten