From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-02-16 17:59:30
| "Thorsten Ottosen" <nesotto_at_[hidden]> 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
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
class CloneAllocator = heap_clone_allocator, // ignored if T is not a
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
The indirect behavior could be provided by one (or three) containers
of the form
template< class Sequence >
template< class Set >
template< class Map >
This might belong in a different library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk