Boost logo

Boost :

Subject: Re: [boost] [cpo-proposal] presentation of the idea
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-08-16 20:20:36

On 08/16/13 08:21, Santiago Tapia wrote:
>> Date: Tue, 13 Aug 2013 18:33:41 +0200
>> From: Klaim - Jo?l Lamotte <mjklaim_at_[hidden]>
>> 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 <shape*>, nor vector< shared_ptr< shape> >, nor boost pointer container
> library.
> Then the classifier could be an alternative.
>>> 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.
Is the map key something like the type_info:

If there is a separate vector for each type, then the storage for a
container containing more than one type can't be contiguous,
since the vectors for the containers for the types cannot be
contiguous, or am I missing something? I think what Thorsten
was aiming at in this post:

was each element in the container was truly contiguous. IOW,
given a container, c, then.


The T1 inserted into c would be contigous with the T2.

>> Date: Tue, 13 Aug 2013 23:33:25 +0400
>> From: Andrey Semashev <andrey.semashev_at_[hidden]>
>>> - 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 above reinforces my above conclusion that T1 and T2 elements
cannot be contiguous in the container.


Boost list run by bdawes at, gregod at, cpdaniel at, john at