Re: [boost] [foreach] cheap_copy crisis?

From: Eric Niebler (eric_at_[hidden])
Date: 2005-12-03 21:08:01

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?

> 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.

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

No.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com