Thorsten Ottosen wrote:
MB wrote:
Thorsten Ottosen wrote:
It is possible to hook 'range_iterator' from user specializations?
template< class T > struct range_iterator<const T> : range_const_iterator<T> { };
Fortunately, Boost.Range documentation doesn't say 'range_iterator< const Foo::Pair<T> >' must be specialized. User 'range_iterator' specializations still work.
I'm not sure what you're saying here. Could you explain?
Sorry, please forget this code. I was confused or drunken. I had ever specialized 'range_iterator<const MyX>' to return "mutable" iterator, before I removed it some time ago.
I see "range_iterator -> range_mutable_iterator" change doesn't break any current user customizations. Am I right?
well, it could break any specialization of range_iterator.
I'll see if I can avoid it, but I won't promise that I can.
As for 'boost_range_begin', the change is rather dangerous. Please do google "range_end".
I don't get a lot of hits that uses range_end as a function.
If 'range_end' is a function, it is rather lucky. Once "int range_end;" is defined, I think there is no workaround.
right, if you have a namespace static variable called range_end, then you can't define a function of the same name in that namespace. But what are the chances of that? remember there is no problem with
{ // some scope int range_end; boost::end(rng); }
I already define a function as a functor to support 'result_of': const range_end_function& range_end = ...;
I read the long discussion why 'boost_range_begin' was born. Did I overlook another discussion about the birth of 'range_begin'?
maybe, there was some discussion about the problems of tying a concept to a library name. the range concept exists out-side of boost and any type T conforms to it if it implements range_begin(T&) and range_end(T&) etc.
Where the range concept belongs? "Global"? I'm maybe an worrier, struggling with ADL invasions. But short names conflict. Regards, Shunsuke Sogame