Re: [boost] [foreach] cheap_copy crisis?

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.

'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/