Re: [boost] [poly_collection] Request for comments: fast polymorphic collections

Subject: Re: [boost] [poly_collection] Request for comments: fast polymorphic collections
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2016-11-16 12:39:10

El 16/11/2016 a las 11:54, Thorsten Ottosen escribió:
> B. I'm still wondering if requirering copyability is a good thing [...]
>
> Right. But maybe that access to be hidden to the outside world like in 
> Boost.Serialiation:
>
>   friend class boost::poly_collection::access;
>
> Then perhaps your library could work with private and protected 
> copy/move operations? My point is that we are still doing 
> OO-programming, and copying/moving is not natural operations for 
> objects in that domain.
>
> [...]
>
> You could always devirtualize it. Anyway, the point is, to hide the 
> copy/move semantics to clients of my class hierarchy. Take the 
> following use-case:
>
> I know what types to register and how many of each I'm going to insert.
> For that case I should be able to construct, reserve and insert 
> without having a copyable or movable type.
>
> Anyway, I would be ok with just being able to make copy/move 
> operations protected.

I'm in principle somewhat reluctant to add lib-specific mechanisms for 
generic operations such as copying (although the friend class 
boost::poly_collection::access thing is an opt-in feature not really 
needed for publicly copyable classes); that said, my wish is to flexible 
with whatever reviewers mostly agree on.

>> C. perhap some range versions of local iterators would be nice?
>>
>> [...]
>
> For example,
>
> for(auto first=c.begin<warrior>(),last=c.end<warrior>();
>     first!=last;++first)
>
> could be nice to write
>
> for( auto x : c.range<warrior>() )
>
> or
>
> for( auto x : restituted_range<warrior>(c) )
>

range<warrior>() (and range(typeid(warrior))) definitely save some 
keystrokes, so why not. What do you mean by restituted_range<warrior>(c)?

>>> E. Boost.PtrContainer does not throw exception when a container cannot
>>> be cloned or compared. Maybe its must be possible to get compile
>>> errors here too?
>>
>> I've re-read Boost.PtrContainer docs and seems like the containers
>> require Base to be clonable, which is tantamount to requiring
>> copyability for all derived classes in Boost.PolyCollection. Am I wrong
>> here? What's the behavior if a Base is not clonable?
>
> It's a compile error. But I think I don't give the compile error until 
> the cloning is needed.
>

The problem is that, unlike the case of Boost.PtrContainer, a 
polymorphic collection can hold simultaneously classes that are copyable 
and non-copyable, so whole-copyability cannot be determined till 
invocation time.

Best

Joaquín M López Muñoz