From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-05-11 11:26:32
"Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> | Thorsten Ottosen wrote:
> | > "Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message
> | > news:k6m6f12b.fsf_at_yahoo.com...
> | >> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> | >>
> | >>> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> | >
> | >>>> I think that the benefits of not having to include <iterator> and
> | >>>> confining this to a pure core extension not requiring library
> | >>>> support outweigh the costs.
> | >>
> | >> Agreed. I like the idea of this being essentially a rewrite-rule. If
> | >> it calls free functions rather than member functions it starts to
> | >> depend on what headers have been included, which seems rather
> | >> fragile.
> | >
> | > in what way is it fragile?
> | The meaning of the language construct for( type i: expr ) changes based on
> | what overloads are visible. This is relatively uncommon for C++.
> the meaning of
> for( const auto& r : make_range( expr ) )
> would also change depending on what overloads that are visible.
> so I'm still not getting what "fragile" means.
If you explicitly say make_range(expr), then you're explicitly calling a
function, so it's obvious that if you include headers that define overloads of
that function, the behaviour may change. If you really really want to ensure a
particular overload is called, you can, with some combination of qualification
If the "for(:)" construct calls free functions directly then you have no
control over which overload is selected, except by carefully choosing which
headers get included. If you need a header which changes the overload set in a
bad way, you're stuck. If the contents of the headers varies by platform
(e.g. standard headers don't specify which other standard headers they pull
in), then the code may work on one platform and not on another, *and there's
not a lot you can do about it*.
Also, the use of free functions implies that at least one header *has* to be
included, even to use the construct with arrays, which just feels wrong.
-- Anthony Williams Software Developer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk