From: MB (mb2act_at_[hidden])
Date: 2005-12-03 20:40:54
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.
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk