"Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message news:u0l8ddr1.fsf@yahoo.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message | > news:k6m5enk7.fsf@yahoo.com... | > | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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