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

Subject: Re: [boost] [poly_collection] Request for comments: fast polymorphic collections
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2016-11-18 06:02:39

On 16-11-2016 18:39, Joaquin M López Muñoz wrote:
> 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;
>>

>> 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.

Yes, please consider it. Most OO-hierarchies start off with prohibiting 
copying by inheriting from boost::noncopyable or something similar. It 
would be a shame if such hierarchies would now be /forced/ to have 
public copy/move operations.

>>> 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)?

The name was referring to type restitution from your docs. This latter 
one is a free-standing function, so c is the collection. Anway, I prefer 
members.

kind regards

-Thorsten