Re: [boost] [cpo-proposal] presentation of the idea

Subject: Re: [boost] [cpo-proposal] presentation of the idea
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-08-13 15:37:10

On Tuesday 13 August 2013 23:33:25 you wrote:
> On Tuesday 13 August 2013 02:07:15 Santiago Tapia wrote:
> > Hi everyone,
> > 
> > I would like to make a proposal for a new library. I only have a draft
> > without documentation but I would like to know people’s opinion
> > about the idea before making a formal proposal.
> > 
> > The library will be named CPO (containers for polymorphic objects)
> > and it will provide containers to store dynamic allocated objects from
> > a class hierarchy. I have drafted one container and I have two more
> > 
> >  in process. The cpo library could be an alternative solution for
> > 
> > boost pointer container library or some other solutions that use pointers.
> > In order to understand the idea, I think that the following example of the
> 
> > use of the library might be better than a long explanation:
> [snip]
> 
> I created containers of dynamically typed elements with Boost.Intrusive a
> few times. It was a bit more verbose than your example but the resulting
> solution was quite efficient and it had all the properties of a container.
> The drawback was that the solution was intrusive w.r.t. the stored types.
> Do you think you could create a set of containers (e.g. list, set, map) of
> polymorphic objects based on Boost.Intrusive without requiring to modify
> the types of the elements?
> 
> > Some details and advantages must be remarked in the provided
> > example:
> > 
> > - The container classifier is _not_ a sequence.
> 
> Why? Is this intentional?
> 
> > - The allocator argument in the classifier will be applied to every object
> > added to the classifier. Thus, the allocator is provided without its
> > argument. The std::allocator is the default argument.
> 
> It's better not to use template template parameters in the container
> interface as it limits its usefullness because users won't be able to
> specify non- template allocators or template allocators with different
> template arguments. You can use the standard interface for allocator
> rebinding:
> 
>  typedef allocator<T> allocator_T;
>  typedef typename allocator_T::template rebind<U>::other allocator_U;
> 
> You can use std::allocator<void> by default then.
> 
> 
> All in all the basic idea looks interesting, although I'm not sure about the
> particular classifier container. It looks very specific to me, the same
> functionality could be achieved with a multimap or unordered_multimap of
> polymorphic elements.

...or I should have said "multiset or unordered_multiset".