Eric Niebler wrote:
Peter Dimov wrote:
Eric Niebler wrote:
Templates don't "foil lookup in the global namespace." They merely require that the overload has been seen already. I have no problem requiring users of broken compilers to put the overload where BOOST_FOREACH can find it. Users of non-broken compilers can put the overload in an associated namespace and be happy.
That's what I do. Non-ADL compilers usually don't have two-phase lookup, so it balances out.
Actually, I just found a compromise: make the global namespace an associated namespace. Now, the recommended procedure for customizing BOOST_FOREACH is to define a function:
inline boost::mpl::true_ * boost_foreach_has_cheap_copy(your_type*, boost::foreach::tag) { return 0; }
This can go in an associated namespace of your_type /or/ for maximum portability in the global namespace. (boost::foreach::tag is a typedef for an enum_at_global_scope_with_a_really_long_ugly_name.) This allows for a very simple implementation of BOOST_FOREACH that even VC6 seems happy with.
I tried boost::foreach::tag-version under VC++7.1. 'to_ptr' makes: warning C4100: 't' : unreferenced formal parameter Anyway I think it is ok for "me". But I think about the case that my ranges which are customized as 'cheap_copy' are derived from anyone else. Won't the same problem as 'iterator_range<>*' come? Now that 'has_cheap_copy' becomes one of the requirements of Range-concepts, doesn't it? I don't care, but I think foreach is so primitive that professionals should consider that. In general, do we have the safe way of telling whether or not a type is cheap to copy without metafunctions? Regards, MB http://p-stade.sourceforge.net/