$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] range adaptors
From: Barend Gehrels (barend_at_[hidden])
Date: 2010-12-29 05:02:41
Hi Neil,
Thanks for your answer.
Op 28-12-2010 23:32, Neil Groves schreef:
>
>> - if this is a generic need, would it not be better to move them out of
>> namespace *detail?
> Yes indeed. This has been done. They are often implemented in range_detail
> and then pulled out with using.
I looked in the source code and see what you mean. That indeeds works
for me.
>> - I noticed that sliced and copied are not in namespace range_detail but in
>> adaptors, for me that sounds OK, but it is expected that for consistancy it
>> might move namespace in any future
> For the trunk version, all of the range adaptor return types can be accessed
> from the boost namespace. Not all of the return types are necessarily
> implemented in the range_detail namespace, but this shouldn't be a concern to the best of my knowledge and belief.
>
Yes and no. Indeed all is accessable without range_detail, but sliced
and copied are not or not yet pulled out of namespace adaptors. So I
have to make two types of specializations, one as boost::reversed_range,
one as boost::adaptors::sliced_range.
In my opinion, if you are reworking this now, this is also the right
moment (provided you have the time for it) to make it consistent (e.g.
all in adaptors ;-) )
>
> Yes, but not to naming, and not breaking backward compatibility. I am unsure
> how much I can get into the 1.46 release, but I have been working on a
> type-erasure range adaptor. I am testing a modification to improve
> compatibility with C++0x being/end. I am hopeful that people aren't using
> ADL to find the boost::begin / boost::end then this will break, since this
> is expressly discouraged in the documentation.
>
OK, great. I've seen a lot of emails about that. I must check our code
as well for this because we've also ranges defined.
Regards, Barend