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