Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-05-11 12:01:49


"Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message
news:k6m5enk7.fsf_at_yahoo.com...
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:

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

my point was that this "fragility" is all over the place in C++.

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

you make it sound like ADL is a horrible thing :-)

I havn't been able to construct realistic examples that shows your dreadful
scenario, but
I won't mind seeing them.

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

well, that's a problem already today. <std> is the way to go.

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

we're trying to get rid of arrays, so it might even be a good idea. if it
doesn't compiles.

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk