[range][foreach] Range fixes broke foreach
Looks like the range fixes broke foreach. See http://mysite.verizon.net/beman/bgd-win32-trunk-results.html --Beman
Beman Dawes skrev:
Looks like the range fixes broke foreach. See http://mysite.verizon.net/beman/bgd-win32-trunk-results.html
This is my fault, sinc eI changed the names of the ADL hooks back to 1.34 names: namespace boost { char * range_begin(mine::dummy&) {return 0;} char const * range_begin(mine::dummy const&) {return 0;} char * range_end(mine::dummy&) {return 0;} char const * range_end(mine::dummy const&) {return 0;} } should be namespace boost { char * boost_range_begin(mine::dummy&) {return 0;} char const * boost_range_begin(mine::dummy const&) {return 0;} char * boost_range_end(mine::dummy&) {return 0;} char const * boost_range_end(mine::dummy const&) {return 0;} } The old names have been in use for so long that I don't see the point in changing them anymore. -Thorsten
Thorsten Ottosen wrote:
Beman Dawes skrev:
Looks like the range fixes broke foreach. See http://mysite.verizon.net/beman/bgd-win32-trunk-results.html
This is my fault, sinc eI changed the names of the ADL hooks back to 1.34 names:
namespace boost { char * range_begin(mine::dummy&) {return 0;} char const * range_begin(mine::dummy const&) {return 0;} char * range_end(mine::dummy&) {return 0;} char const * range_end(mine::dummy const&) {return 0;} }
should be
namespace boost { char * boost_range_begin(mine::dummy&) {return 0;} char const * boost_range_begin(mine::dummy const&) {return 0;} char * boost_range_end(mine::dummy&) {return 0;} char const * boost_range_end(mine::dummy const&) {return 0;} }
The old names have been in use for so long that I don't see the point in changing them anymore.
I'm dumbfounded. Thorsten, how can you make an API-breaking change to a core library like Range at a time like this, and not tell anybody? My code, docs and tests would all need to change because of this. !!!!! We agreed long ago that range_begin() was the name of the customization point, because the Range concept is larger than Boost. Has that changed? Beman, what do you want to do? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler skrev:
Thorsten Ottosen wrote:
Beman Dawes skrev:
Looks like the range fixes broke foreach. See http://mysite.verizon.net/beman/bgd-win32-trunk-results.html This is my fault, sinc eI changed the names of the ADL hooks back to 1.34 names:
namespace boost { char * range_begin(mine::dummy&) {return 0;} char const * range_begin(mine::dummy const&) {return 0;} char * range_end(mine::dummy&) {return 0;} char const * range_end(mine::dummy const&) {return 0;} }
should be
namespace boost { char * boost_range_begin(mine::dummy&) {return 0;} char const * boost_range_begin(mine::dummy const&) {return 0;} char * boost_range_end(mine::dummy&) {return 0;} char const * boost_range_end(mine::dummy const&) {return 0;} }
The old names have been in use for so long that I don't see the point in changing them anymore.
I'm dumbfounded. Thorsten, how can you make an API-breaking change to a core library like Range at a time like this, and not tell anybody?
I could have announced this better, I apologize for that. What time is this?
My code, docs and tests would all need to change because of this.
!!!!!
We agreed long ago that range_begin() was the name of the customization point, because the Range concept is larger than Boost. Has that changed?
And that is the problem: do you want to break the few boost libs in a development trunk, or break all clients out there? The names where settled for maybe two years ago. -Thorsten
Thorsten Ottosen wrote:
Eric Niebler skrev:
Thorsten Ottosen wrote:
Beman Dawes skrev:
Looks like the range fixes broke foreach. See http://mysite.verizon.net/beman/bgd-win32-trunk-results.html This is my fault, sinc eI changed the names of the ADL hooks back to 1.34 names:
namespace boost { char * range_begin(mine::dummy&) {return 0;} char const * range_begin(mine::dummy const&) {return 0;} char * range_end(mine::dummy&) {return 0;} char const * range_end(mine::dummy const&) {return 0;} }
should be
namespace boost { char * boost_range_begin(mine::dummy&) {return 0;} char const * boost_range_begin(mine::dummy const&) {return 0;} char * boost_range_end(mine::dummy&) {return 0;} char const * boost_range_end(mine::dummy const&) {return 0;} }
The old names have been in use for so long that I don't see the point in changing them anymore.
I'm dumbfounded. Thorsten, how can you make an API-breaking change to a core library like Range at a time like this, and not tell anybody?
I could have announced this better, I apologize for that. What time is this?
We're stabilizing for 1.35.
My code, docs and tests would all need to change because of this.
!!!!!
We agreed long ago that range_begin() was the name of the customization point, because the Range concept is larger than Boost. Has that changed?
And that is the problem: do you want to break the few boost libs in a development trunk, or break all clients out there? The names where settled for maybe two years ago.
Have you just changed the names of the adl hooks? There are lots of other breaking changes, like the changed meaning of range_iterator<>, the deprecation of range_result_iterator<> and the addition of range_mutable_iterator<>. And the behavior of range_end(char (&)[N]), too. Are you going to roll all of that back? If not, then you haven't really got a leg to stand on -- you're breaking clients anyway. This change is a mistake. Please, back it out. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler skrev:
Thorsten Ottosen wrote:
We agreed long ago that range_begin() was the name of the customization point, because the Range concept is larger than Boost. Has that changed? And that is the problem: do you want to break the few boost libs in a development trunk, or break all clients out there? The names where settled for maybe two years ago.
Have you just changed the names of the adl hooks? There are lots of other breaking changes, like the changed meaning of range_iterator<>, the deprecation of range_result_iterator<> and the addition of range_mutable_iterator<>. And the behavior of range_end(char (&)[N]), too. Are you going to roll all of that back? If not, then you haven't really got a leg to stand on -- you're breaking clients anyway.
This change is a mistake. Please, back it out.
oK. Done. -Thorsten
shunsuke wrote:
Thorsten Ottosen wrote:
This change is a mistake. Please, back it out. oK. Done.
Why not call boost_range_begin from range_begin?
Not a bad idea ... but this doesn't address the problem of the changed meaning of the boost::range_iterator<> metafunction. (E.g., in your scheme, what is the return type of range_begin()?) -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Why not call boost_range_begin from range_begin?
Not a bad idea ... but this doesn't address the problem of the changed meaning of the boost::range_iterator<> metafunction. (E.g., in your scheme, what is the return type of range_begin()?)
Right. There is no workaround for that name swapping. :-( BTW, I think you added a workaround for msvc-7.1 array into Boost.Foreach. That part is no longer needed. You can remove it, waiting for Boost.Range tests to pass. Regards, -- Shunsuke Sogame
Thorsten Ottosen skrev:
Eric Niebler skrev:
We agreed long ago that range_begin() was the name of the customization point, because the Range concept is larger than Boost. Has that changed?
And that is the problem: do you want to break the few boost libs in a development trunk, or break all clients out there? The names where settled for maybe two years ago.
That being said, it is easy for me to roll the change back. It has nothing to do with the orther patches for the lib. -Thorsten
I'm a bit confused. I'm working with blitz++. It has template<typename T, int N> class Array ... which already has a begin(), end(), but I can't use them. I'm specializing boost::begin,end,etc to hide them (I don't want to modify the blitz Array class) If I specialize range_begin: namespace boost { template<typename T, int N> inline typename blitz::array_iterator< blitz::Array<T,N> >::type range_begin (blitz::Array<T,N> & a) { return blitz::range_begin (a); } } Then this doesn't work, it seems that boost::begin (blitz::Array<T,N>&) finds the original begin(), but if I do: namespace boost { template<typename T, int N> inline typename blitz::array_iterator< blitz::Array<T,N> >::type begin (blitz::Array<T,N> & a) { return blitz::range_begin (a); } } it works as desired. My questions are: 1) Is this reasonable? 2) What is the advantage of using e.g., range_begin() instead of just specializing boost::begin()?
Neal Becker skrev:
I'm a bit confused.
I'm working with blitz++. It has
template<typename T, int N> class Array ...
which already has a begin(), end(), but I can't use them. I'm specializing boost::begin,end,etc to hide them (I don't want to modify the blitz Array class)
If I specialize range_begin:
namespace boost {
template<typename T, int N> inline typename blitz::array_iterator< blitz::Array<T,N> >::type range_begin (blitz::Array<T,N> & a) { return blitz::range_begin (a); } }
Then this doesn't work, it seems that boost::begin (blitz::Array<T,N>&) finds the original begin(), but if I do:
namespace boost {
template<typename T, int N> inline typename blitz::array_iterator< blitz::Array<T,N> >::type begin (blitz::Array<T,N> & a) { return blitz::range_begin (a); } }
it works as desired. My questions are:
1) Is this reasonable?
Compared to what?
2) What is the advantage of using e.g., range_begin() instead of just specializing boost::begin()?
i guess that would work too ... I think this is what is done for Shims in the STLSoft libs. I can't remember the details of the differences between the two approaches, but I'm sure there is a someone on the list that can. I guess the ADL version emplasizes putting stuff in the same interface as your class, instead of messing around into another namespace. -Thorsten
Neal Becker wrote:
I'm a bit confused.
I'm working with blitz++. It has
template<typename T, int N> class Array ...
which already has a begin(), end(), but I can't use them. I'm specializing boost::begin,end,etc to hide them (I don't want to modify the blitz Array class)
If I specialize range_begin:
namespace boost {
template<typename T, int N> inline typename blitz::array_iterator< blitz::Array<T,N> >::type range_begin (blitz::Array<T,N> & a) { return blitz::range_begin (a); } }
(Terminology issue: this is an overload, not a specialization.) The correct place for the range_begin() overload for conforming compilers would be in the same namespace as the Array class. That way, it is found via ADL. HTH, -- Eric Niebler Boost Consulting www.boost-consulting.com
Beman Dawes wrote:
Looks like the range fixes broke foreach. See http://mysite.verizon.net/beman/bgd-win32-trunk-results.html
Can someone tell me what changed? Thorsten? -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (5)
-
Beman Dawes -
Eric Niebler -
Neal Becker -
shunsuke -
Thorsten Ottosen