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

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:

  http://www.cplusplus.com/reference/typeinfo/

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:

http://article.gmane.org/gmane.comp.lib.boost.devel/243504

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

  c.insert(T1());
  c.insert(T2());

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

[snip]
>> 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.
[snip]

-regards,
Larry