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