FYI, The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some. The breaking changes are - boost::end( CharT[N]) does not differ from boost::end(T[N]) - boost::range_iterator<const T> is not a mutable iterator anymore - boost::size(rng) requires random access iterators - boost_range_begin ADL hooks renamed range_begin (ditto for boost_range_end) - mutable iterators must be defined as a specialization of boost::range_mutable_iterator Some additions are - new traits: * range_category * range_pointer * range_reference - fewer specializations needed to implement the concepts (and no specializations for const X) * range_iterator or range_mutable_iterator and range_const_iterator * range_size * range_begin/range_end All other traits/function are synthesized - new functions * distance(rng) * as_literal(rng) * as_array(rng) best regards -Thorsten
Thorsten Ottosen wrote:
FYI,
The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some.
Thorsten, when I open the files you just checked on Windows in I see ^M line terminators. As this doesn't happen with any other file in Boost, I suspect something was out of place when you committed. Cheers, Nicola Musatti
Nicola Musatti wrote:
Thorsten Ottosen wrote:
FYI,
The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some.
Thorsten, when I open the files you just checked on Windows in I see ^M line terminators. As this doesn't happen with any other file in Boost, I suspect something was out of place when you committed.
I've run dos2unix on all the files. Why don't inspect pick this up? -Thorsten
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
FYI,
The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some.
The breaking changes are
- boost::end( CharT[N]) does not differ from boost::end(T[N]) - boost::range_iterator<const T> is not a mutable iterator anymore - boost::size(rng) requires random access iterators - boost_range_begin ADL hooks renamed range_begin (ditto for boost_range_end) - mutable iterators must be defined as a specialization of boost::range_mutable_iterator
What do you mean? Surely not _all_ mutable iterators. I assume the library doesn't magically make char* an invalid mutable iterator? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
- mutable iterators must be defined as a specialization of boost::range_mutable_iterator
What do you mean? Surely not _all_ mutable iterators. I assume the library doesn't magically make char* an invalid mutable iterator?
Now the library does not treat char* as a Range anymore. If you wanted to, you could do so with namespace boost { template<> struct range_mutable_iterator<char*> { typedef char* type; } } -Thorsten
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
David Abrahams wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
- mutable iterators must be defined as a specialization of boost::range_mutable_iterator
What do you mean? Surely not _all_ mutable iterators. I assume the library doesn't magically make char* an invalid mutable iterator?
Now the library does not treat char* as a Range anymore.
I know that, but I don't see the relevance. AFAICT your statement was not about what qualifies as a Range but about mutable iterators. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
David Abrahams wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
- mutable iterators must be defined as a specialization of boost::range_mutable_iterator
What do you mean? Surely not _all_ mutable iterators. I assume the library doesn't magically make char* an invalid mutable iterator?
Now the library does not treat char* as a Range anymore.
I know that, but I don't see the relevance. AFAICT your statement was not about what qualifies as a Range but about mutable iterators.
right, range_iterator is now range_mutable_iterator and range_result_iterator is now range_iterator. -Thorsten
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
David Abrahams wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
David Abrahams wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
- mutable iterators must be defined as a specialization of boost::range_mutable_iterator
What do you mean? Surely not _all_ mutable iterators. I assume the library doesn't magically make char* an invalid mutable iterator?
Now the library does not treat char* as a Range anymore.
I know that, but I don't see the relevance. AFAICT your statement was not about what qualifies as a Range but about mutable iterators.
right, range_iterator is now range_mutable_iterator and range_result_iterator is now range_iterator.
I know that, but I don't see the relevance. AFAICT your statement was not about how to ask for a Range's iterator types but about about mutable iterators being specializations of some particular class template. I still don't understand what that statement meant. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Thorsten Ottosen wrote:
FYI,
The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some.
The breaking changes are
- boost::end( CharT[N]) does not differ from boost::end(T[N]) - boost::range_iterator<const T> is not a mutable iterator anymore - boost::size(rng) requires random access iterators - boost_range_begin ADL hooks renamed range_begin (ditto for boost_range_end) - mutable iterators must be defined as a specialization of boost::range_mutable_iterator
Some additions are
- new traits:
* range_category * range_pointer * range_reference
- fewer specializations needed to implement the concepts (and no specializations for const X) * range_iterator or range_mutable_iterator and range_const_iterator * range_size * range_begin/range_end
All other traits/function are synthesized
- new functions
* distance(rng) * as_literal(rng) * as_array(rng)
best regards
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I found that range/iterator.hpp #includes "range/mutable_iterator.hpp" but there is no mutable_iterator.hpp any more. Is there something wrong with this? Thanks. Minmin Gong
Thorsten Ottosen wrote:
FYI,
The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some.
The breaking changes are
- boost::end( CharT[N]) does not differ from boost::end(T[N]) - boost::range_iterator<const T> is not a mutable iterator anymore - boost::size(rng) requires random access iterators - boost_range_begin ADL hooks renamed range_begin (ditto for boost_range_end) - mutable iterators must be defined as a specialization of boost::range_mutable_iterator
'boost::size' seems to be a breaking change for me, but 'boost::distance' will replace it? FWIW, after combating Range and FOREACH, my qualityless ranges are here: http://tinyurl.com/lebuq Thanks! -- Shunsuke Sogame
Shunsuke Sogame wrote:
Thorsten Ottosen wrote:
FYI,
The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some.
The breaking changes are
- boost::end( CharT[N]) does not differ from boost::end(T[N]) - boost::range_iterator<const T> is not a mutable iterator anymore - boost::size(rng) requires random access iterators - boost_range_begin ADL hooks renamed range_begin (ditto for boost_range_end) - mutable iterators must be defined as a specialization of boost::range_mutable_iterator
'boost::size' seems to be a breaking change for me, but 'boost::distance' will replace it?
right.
FWIW, after combating Range and FOREACH, my qualityless ranges are here: http://tinyurl.com/lebuq
I can see you have picked up on the idea of range adaptors which I'm also baking. I'll definitely have a look. And btw, wasn't it you who made some MFC implementation of ranges? With your permission, I would like to include that in the library. best regards -Thorsten
Thorsten Ottosen wrote:
Shunsuke Sogame wrote:
Thorsten Ottosen wrote: FWIW, after combating Range and FOREACH, my qualityless ranges are here: http://tinyurl.com/lebuq
I can see you have picked up on the idea of range adaptors which I'm also baking. I'll definitely have a look.
Rightly or wrongly, temporary container of iterators seems to increase range adaptor candidates. Actually 'sort_range/sorted' becomes essential part of my code.
And btw, wasn't it you who made some MFC implementation of ranges?
With your permission, I would like to include that in the library.
Though it was interesting work, I have never used them except for CSimpleArray. :-( I did think they were legacy and unrecommended while implementing. They are now sleeping here... http://tinyurl.com/qucoa -- Shunsuke Sogame
Shunsuke Sogame wrote:
Thorsten Ottosen wrote:
Shunsuke Sogame wrote:
Thorsten Ottosen wrote: FWIW, after combating Range and FOREACH, my qualityless ranges are here: http://tinyurl.com/lebuq
I can see you have picked up on the idea of range adaptors which I'm also baking. I'll definitely have a look.
Rightly or wrongly, temporary container of iterators seems to increase range adaptor candidates. Actually 'sort_range/sorted' becomes essential part of my code.
are these it different from in-place sorting?
And btw, wasn't it you who made some MFC implementation of ranges?
With your permission, I would like to include that in the library.
Though it was interesting work, I have never used them except for CSimpleArray. :-( I did think they were legacy and unrecommended while implementing. They are now sleeping here... http://tinyurl.com/qucoa
Ok, there would need to be some test along with these, other wise I can't include them. Another question is: does it work with vc6+, vc7+, or vc7.1+ ? -Thorsten
Thorsten Ottosen wrote:
Shunsuke Sogame wrote:
Thorsten Ottosen wrote:
Shunsuke Sogame wrote:
Thorsten Ottosen wrote: FWIW, after combating Range and FOREACH, my qualityless ranges are here: http://tinyurl.com/lebuq I can see you have picked up on the idea of range adaptors which I'm also baking. I'll definitely have a look.
Rightly or wrongly, temporary container of iterators seems to increase range adaptor candidates. Actually 'sort_range/sorted' becomes essential part of my code.
are these it different from in-place sorting?
'sorted' doesn't modify its left argument, instead it creates and sorts temporary container of iterators. I don't know for sure whether such adaptor is legal or not.
And btw, wasn't it you who made some MFC implementation of ranges?
With your permission, I would like to include that in the library.
Though it was interesting work, I have never used them except for CSimpleArray. :-( I did think they were legacy and unrecommended while implementing. They are now sleeping here... http://tinyurl.com/qucoa
Ok, there would need to be some test along with these, other wise I can't include them.
Another question is: does it work with vc6+, vc7+, or vc7.1+ ?
vc7.1+. I guess Boost.Range non-intrusive customization doesn't support vc6/7. I will try to simplify the header structure and move them to boost/range/detail/mfc. I can maybe... promise, if they are really wanted. :-( Apart from mfc, I think users (and I) hope some runtime test functions are written by professionals (like range/concepts.hpp) if possible. -- Shunsuke Sogame
participants (5)
-
David Abrahams -
gongminmin -
Nicola Musatti -
Shunsuke Sogame -
Thorsten Ottosen