Boost logo

Boost :

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

kind regards


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