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?
From the point of client view, I have never called 'range_iterator', while I called 'range_result_iterator' 159 times.
As for 'range_result_iterator', there is no reason why it should be removed. If it were removed, I would add just:
// legacy name of range_iterator template< class Range > struct range_result_iterator : range_iterator<Range> { };
right, this could be done to provide some form of backwards compatibility.
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. I read the long discussion why 'boost_range_begin' was born. Did I overlook another discussion about the birth of 'range_begin'?
Thus, no problem breaks except for 'char*', doesn't it?
well,
- char[N] returns the same as T[N] - range_iterator is named range_mutable_iterator.
BTW: please use your real name when posting
Formal rule? If so, this should be the final post...
I don't think so, but I like to know whom I'm speaking with.
Nice to meet you and the world. Regards, Shunsuke Sogame