Re: [boost] [foreach] cheap_copy crisis?

From: MB (mb2act_at_[hidden])
Date: 2005-12-03 21:33:49

Eric Niebler wrote:
> MB wrote:
> 
>>Eric Niebler wrote:
>>
>>
>>>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
> 
> 
> 
> I'll fix that.
> 
> 
> 
>>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?
> 
> 
> 
> Sorry, I don't understand the question. Are you saying you think it's 
> wrong to assume that types derived from iterator_range are cheap to copy?

Errata:

   But I think about the case that my ranges which are customized as 'cheap_copy'
   becomes base classes of anyone else.

   replaces:

     >But I think about the case that my ranges which are customized as 'cheap_copy'
     >are derived from anyone else.

English is as difficult as C++ :-)

>>Now that 'has_cheap_copy' becomes one of the requirements of Range-concepts, doesn't it?
> 
> No. Boost.Range defines the range concept, and FOREACH works correctly 
> with any type that satisfies that concept. has_cheap_copy is nothing 
> more than an optimization hint to the BOOST_FOREACH macro. It is not 
> required and it doesn't change the meaning of anything.

But the hint expands to the derived classes and
the derived classes "must" customize 'has_cheap_copy'.

>>In general, do we have the safe way of telling whether or not a type
>>is cheap to copy without metafunctions?
> 
> No.

Is it portability-issue the reason why you avoid metafunctions?

Regards,
MB
http://p-stade.sourceforge.net/