Re: [boost] [Range] breaking update pending

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-31 10:16:53

Thorsten Ottosen <tottosen_at_[hidden]> writes:

> David Abrahams wrote:
>
>  > MB <mb2act_at_[hidden]> writes:
>  >
>  >
>  >> Thorsten Ottosen wrote:
>  >>
>  >>> Dear All,
>  >>>
>  >>> I have been trimming boost.range to incorporate the changes we have 
> been
>  >>> discussing some time ago.
>  >>>
>  >>> These changes will break many uses of the library. Inside boost 
> this will affect
>  >>>
>  >>> Boost.foreach
>  >>> Boost.string algo
>  >>> Boost.iostreams (*)
>  >>>
>  >>> (*) I don't this will break
>  >>>
>  >>> The list of major changes is the follwing:
>  >>>
>  >>> 1. ADL hooks renamed boost_range_begin -> range_begin,
>  >>>                      boost_range_end -> range_end
>  >>
>  >>
>  >> Why was such short name accepted??
>  >> Even 'const_begin' that calls unqualified 'begin' breaks down 
> Boost.MPL!!
>
>
> This was a bug. In the new version there is no unqualified
> call to begin(), end(), size() and empty().
>
>  >
>  > How so?  What happens?  Got a small reproducible case?
>  >
>
> GCC ADL looks up a class named "end" too. Old story.

You need to read more carefully.  A change from boost_range_end to
range_end would not cause any interaction with the name "end."

>  > Thorsten, did you consider providing a backward compatibility layer
>  > for the transition?
>
>
> Yes, but I don't have a good way to do this. putting the old version in, 
> say, boost/range/v1 was rejected because of ODR problems.
>
> Do you have any ideas?

I was thinking of a system that would (as much as possible) keep old
code working, without substituting different definitions.  For
example, you could keep boost_range_begin and dispatch to range_begin.
I'm not sure of the details, or how well it could work, but I thought
it was worth considering.  When thinking about it, keep in mind that
we can detect the presence of an overloaded function that is supposed
to be found via ADL.  I don't know if that helps, but it might.

Cheers,
Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com