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
>> 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>();
>> could be nice to write
>> for( auto x : c.range<warrior>() )
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk