[boost] Re: Formal Review: FOREACH macro

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-05-02 10:06:50

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message 
news:d53uss$p3n$1_at_sea.gmane.org...

| 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.

hm...that won't save you anything AFAICT.

| 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.

things like pair<iterator,iterator> are very common...just look at BGL.

besides, you need a way to make your own collection work with foreach.

| 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

so.? the standard containers part of it is pretty portable.

-Thorsten