[boost] Re: FOREACH / C++ "for" proposal

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-05-13 03:37:10

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message 
> news:u0l8ddr1.fsf_at_yahoo.com...
> | "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> |
> | > "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?
>
> | > my point was that this "fragility" is all over the place in C++.
> |
> | Yes, and we do what we can to avoid it. Introducing an instance into the 
> core
> | of the language seems to be asking for trouble.
>
> I would like to see examples of this "fragility".

I will construct one for you.

> | > | 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 :-)
> |
> | It can be. Introducing ADL needs to be done carefully and with much
> | thought. begin and end are common words, and there may be overloads in scope
> | which are nothing to do with iterating. Actually, come to think of it, if I 
> am
> | iterating over a range, I sometimes use *variables* called begin and end to
> | mark the ends of the range, which would completely scew up ADL:
>
> the proposal demands
>
> using std::begin;

So it does, I got carried away on my train of thought. My mistake. The example
I gave were of ADL not applying, which it does if you add the using.

> | > well, that's a problem already today. <std> is the way to go.
> |
> | In current cases where it happens, you can generally modify the call site to
> | ensure that the correct overload is called. If you can't access the call 
> site,
> | because it is generated by the compiler, then you can't fix it. Note that 
> the
> | problem is not that of required headers not being included, but rather that 
> of
> | not-wanted headers being included.
>
> I don't get it; can you show this?

I will construct an example.

> | > | 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.
> |
> | Who is "we"? There are many valid uses of arrays, not least of which for
> | fixed-content tables, which is precisely one scenario where I might wish to
> | use for(:) to iterate over the contents.
>
> boost::array<T,N> should work there too.

Well, yes, but why use a library type when there's a built-in type that works
just as well? Sounds like unnecessary additional overhead to me. Just because
there's an alternative doesn't mean that my approach is not valid.

Again, who's "we"?

Anthony
-- 
Anthony Williams
Software Developer