Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-05-02 10:22:03

"Eric Niebler" <eric_at_[hidden]> wrote in message
> Gennadiy Rozental wrote:
>> 1. Rvalues support
>> I agree it's cool and "magical" - the way you added support for rvalues.
>> But I believe it's actually misplaced efforts. IMO support for rvalues
>> brings more harm than advantage. I could accidently or mindlessly (using
>> some global replacement in sources, for example) introduce rvalue in
>> BOOST_FOREACH statement and compiler wouldn't warn me. Now I am paying
>> for an unnessesary copying. while exist perfectly good alternative that
>> doesn't require it:
>> my_collection_type my_function();
>> ...
>> my_collection_type const& v = my_function()
>> BOOST_FOREACH(... , v )
>> {
>> }
>> In addition eliminating rvalues support will signicantly simplify
>> implementation and as a result speed up compilation.
> There is an important usage scenario that requires iteration over rvalue
> containers ... when you don't know the type of the container. With the
> ragex_lib (in boost-sandbox), you can filter and transform a range *in
> place* and then immediately iterate over it. Consider:
> BOOST_FOREACH(..., v | filter(my_pred()) | transform(my_func()))
> {
> }

Hopefully soon enough we may be able to write

auto const& r = v | filter(my_pred()) | transform(my_func());

BOOST_FOREACH(..., r ) {

> Here, filter and transform are range adaptors, built on top of
> filter_iterator and transform_iterator. The type of the container is
> complicated, but you don't have to mention it anywhere because FOREACH
> correctly handles rvalues.
> This is very powerful.

And dangerous. Cause allows developer to "forget" about an extra copy. I
guess I could live with it. I wrap it into my own header and disable rvalues
by definining appropriate macros

>> 2. Usage of Boost.Range
>> I understand why FOREACH is using Boost.Range, but:
>> a) In many (most) cases I (and any other developer now) working with stl
>> containers and wouldn't need any extra help from boost.range for FOREACH
>> to work properly.
>> b) Usage of Boost.Range introduces an extra dependency on ...
>> Boost.Range and everything it depends on in its' turn (including all
>> portability limitations). I for one couldn't afford this dependency,
>> c) Usage of Boost.Range adding a level of indiration and slightly
>> complicate am implementation
> Actually, I switched to Boost.Range to make the implementation *less*
> complicated.

It adds a level of indirection, right. You are using Boost.Range for support
arrays and extencibility. If you would stick with col.begin() and col.end()
it would be simpler.

>> I am not going to propose to eliminate this dependency completely. But
>> I think we need to make it optional.
> What do you mean by and optional dependency on Boost.Range?





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