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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-05-12 13:51:38

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

| > | 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:
|
| template<typename SomeIterator>
| void some_algorithm(SomeIterator begin,SomeIterator end)
| {
|    // do stuff. Can't do anything which relies on calling begin() or end()
|    // with ADL, as variables will be found first.
| }

the proposal demands

using std::begin;

for example, the follwoing works just fine:

#include <boost/range.hpp>

#include <vector>

template< class Iter >
void some_algo( Iter begin, Iter end )
{
    std::vector<int> vec;
    using boost::begin;
    std::vector<int>::iterator i = begin(vec);
}

int main()
{
    std::vector<float> vec;
    some_algo( vec.begin(), vec.end() );
}

| Likewise, within a member function of a container that itself implements
| begin() and end() functions, the member functions will be found first, and
| prevent ADL.

same situation

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

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

-Thorsten