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/