Date: Tue, 13 Aug 2013 18:33:41 +0200 From: Klaim - Jo?l Lamotte
Maybe a classic implementation example would make a clearer point on which case it solves.
I will try, actually I have to write the full documentation.
Anyway, let us suppose you have something as simple as a class hierarchy of
shapes. Base class: shape, and derived classes: square and triangle. You might
like to store shape objects in one container but you might not want to use:
vector
What if the class hierarchy is used to model a graph that contains cycles. For example, something like a spirit grammar where a non-terminal on the rhs of a non-terminals definition? Wouldn't this require some sort of smart pointer or other garbage collection method with the ability to collect cycles?
My understanding of the proposed container is that it's mostly like having a collection of vectors, one for each final types, but exposing only one base interface in container interface. If I'm correct, I don't see how the problem you describe might be a problem.
Joel.
Yes, that is the idea. Actually, whether the implementation uses a collection of vectors or other mechanism is an implementation detail. I use a map of vectors in the classifier container, but I will try other implementations.
Date: Tue, 13 Aug 2013 13:54:09 -0500 From: Larry Evans
Rereading the OP, I see:
collection.insert( derived_A(21) );
which means a completely new object is created during the insert; hence, no cycles in pointer graph can occur.
Yes, the interface of classifier<base> (for instance: classifier<shape>) should be similar to vector<triangle> but with the ability of inserting any object that derives from shape. Moreover, you can not have a std::vector of a pure abstract class, but you could have a classifier of an abstract class.
Date: Tue, 13 Aug 2013 23:33:25 +0400 From: Andrey Semashev
- The container classifier is _not_ a sequence.
Why? Is this intentional?
Both intentional and accidental, because I want to allocate objects contiguously in memory I have to store them in a collection of vectors, the container is not a sequence but a collection of sequences, one sequence for every class in the classifier. I will implement a sequence, but later.
- 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.
I am not sure how to do this. I need a allocator with a parameter in order to get: allocator<triangle>, allocator<square>, ... this allocator must be instantiated when an object of a new class is inserted in the classifier.
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".
As far as I know it is not possible to get a multimap of a pure abstract class,
therefore, for example, you can not use a multimap