|If you plan to extend the lib as outlined in the "future work" section |to cope with pointer-like objects like shared_ptr (an maybe iterators?) |then indirect_xxx would fit better, though ptr_xxx is evocative enough. |Just my 2 cents, anyway. The first release will not consider the extension with shared_ptr. If people really want it, we should consider it for a second release. what do you mean by "and maybe iterators"? -Thorsten

|> |> what do you mean by "and maybe iterators"? |> | | I mean, maybe your lib can support in the future indirection through | external iterators --in this case, ownership won't be managed by your | container as is the case now. ownership can be enabled/disabled, but you still have to store pointers. | 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? That is going to be really hard. -Thorsten

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

| Thorsten Ottosen wrote: | | > 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 | | I'm starting to agree. thanks. after giving it some thought, then I also agree with myself :-) | > template< class Sequence > | > indirect_sequence; | > | > template< class Set > | > indirect_set; | > | > template< class Map > | > indirect_map; | > | > This might belong in a different library. | | VTL, perhaps. yeah, something like that. | If indirection is not really the unifying theme, perhaps you should use the name | Boost.ManagedContainer, which I think was suggested at some point. | ('ManagingContainer' might be more correct, but doesn't sound good.) Managed container is a good name. To recap, I think these are good condidates: Boost. Managed Container Boost. Managed Pointer Container Boost. Pointer Container Boost. Clonable Container Boost. Clonable Pointer Container Boost. Cloned Container My personal favourite would be Boost.Cloned Container with class names like this: cloned_vector<T> cloned_map<Key,T> When I think about it, I see cloning as the most central concept; in fact, the only new policy of the containers is the CloneAllocator. -Thorsten

Joaquín Mª López Muñoz <joaquin@tid.es> writes:

Thorsten Ottosen ha escrito:

...

Dear all,

I will soon start to write some more documentation for the indirect container library (formerly called the smart container library). Before I start on that I would like to get a vote on the preferred naming of

1. the library itself 2. library classes

Ad 1: library name: --------------------

Boost.Indirect Cotainer was suggested by Joaquin. It sounds reasonable to me. I don't have any alternatives, but suggestions are welcome.

Maybe Boost Pointer Containers would also do, specially if you keep the ptr_xxx names.

I've heard the term "pointainer" somewhere. Not that I like it or anything. I believe "indirect" is superior -- I am assuming containers of dereferenceable types other than pointers (like iterators) are also supported. -- Dave Abrahams Boost Consulting www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message

|I've heard the term "pointainer" somewhere. Not that I like it or |anything.

I agree, its not that good.

| I believe "indirect" is superior -- I am assuming containers of | dereferenceable types other than pointers (like iterators) are also | supported.

Curently they are not, unless the iterator happens to be a pointer.

The trouble in that case would be that my implementation used void* underneith and hence has special iterators that does a reinterpret_cast.

Aside: Why reinterpret_cast? Surely static_cast would be a more restrictive and less alarming choice.

A reinterpret_cast appears here and there in the container's implmentation too.

You just need specializations for pointers that do that casting trick, and a generalized template that doesn't.

So given that iterators in general are not supported, would you then prefer the ptr_ prefix?

No; I'd prefer if you planned to phase in support for dereferenceable types in general. -- Dave Abrahams Boost Consulting www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:cuvvd9$smq$1@sea.gmane.org... | "David Abrahams" <dave@boost-consulting.com> wrote in message | news:u1xbgsbhw.fsf@boost-consulting.com... || "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: || | || > The trouble in that case would be that my implementation used void* || > underneith and hence has special iterators that does a || > reinterpret_cast. || || Aside: Why reinterpret_cast? Surely static_cast would be a more || restrictive and less alarming choice. | | ah yes, my mistake. I forgot static cast could do the job. anyway, how would you convert from void*& to T*& with a static_cast ? -Thorsten

"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jl8qlp1.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | > | ah yes, my mistake. I forgot static cast could do the job. | > | > anyway, how would you convert from void*& to T*& with | > a static_cast ? | | You can't. But you can't do it portably with reinterpret_cast either. I see, does this implies that it's impossible to wrap an iterator with void* as its value type? -Thorsten