Hi, I wrote an "interest" version of Boost.Range support for ATL/MFC: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename... or http://tinyurl.com/evddv There are *40* ranges. The test is problematic... It is possible to fail to complete. :-( They are roughly tested under: VC7.1 + ATL7 + MFC7 VC8 + ATL3 and Boost.Range at cvs BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range. Thanks! -- Shunsuke Sogame
On 5/23/06, Shunsuke Sogame <mb2act@yahoo.co.jp> wrote:
BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range.
If I recall correctly applying boost::size() was intentional. size(r) is a valid expression for the ForwardRange concept, and I believe Thorsten didn't want ADL to kick in, so in the concept check implementation boost:: is used to qualify all the functions. boost::size() eventually dispatches either a size() member of the range object or std::distance(). Daniel Walker
Daniel Walker wrote:
On 5/23/06, Shunsuke Sogame <mb2act@yahoo.co.jp> wrote:
BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range.
If I recall correctly applying boost::size() was intentional. size(r) is a valid expression for the ForwardRange concept, and I believe Thorsten didn't want ADL to kick in, so in the concept check implementation boost:: is used to qualify all the functions. boost::size() eventually dispatches either a size() member of the range object or std::distance().
Updated cvs shows 'boost::size' uses 'operator-' ? I somewhat wonder why 'boost::size' and 'boost::range_size' are not deprecated like 'boost::range_result_iterator'. -- Shunsuke Sogame
Shunsuke Sogame wrote:
Daniel Walker wrote:
On 5/23/06, Shunsuke Sogame <mb2act@yahoo.co.jp> wrote:
BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range.
If I recall correctly applying boost::size() was intentional. size(r) is a valid expression for the ForwardRange concept,
Well, that has changed.
and I believe
Thorsten didn't want ADL to kick in, so in the concept check implementation boost:: is used to qualify all the functions. boost::size() eventually dispatches either a size() member of the range object or std::distance().
Updated cvs shows 'boost::size' uses 'operator-' ? I somewhat wonder why 'boost::size' and 'boost::range_size'
you mean just return range_difference<R>::type from size()? That could be an idea. The only thing I hate is that vector<int>::size_type s = boost::size( cont ); will know generate a warning. I wish we could synthesize range_size<> from range_difference<>. -Thorsten
Thorsten Ottosen wrote:
Updated cvs shows 'boost::size' uses 'operator-' ? I somewhat wonder why 'boost::size' and 'boost::range_size'
you mean just return range_difference<R>::type from size()?
That could be an idea. The only thing I hate is that
vector<int>::size_type s = boost::size( cont );
will know generate a warning.
But 'boost::size' is already beyond the warning. It actually made an *error* at <concepts.hpp>, which is the part of Boost.Range! I wonder why 'boost::size' that is (IMO) no longer used increases the job of customization, 'boost::range_size'. -- Shunsuke Sogame
On 5/23/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Shunsuke Sogame wrote:
Daniel Walker wrote:
On 5/23/06, Shunsuke Sogame <mb2act@yahoo.co.jp> wrote:
BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range.
If I recall correctly applying boost::size() was intentional. size(r) is a valid expression for the ForwardRange concept,
Well, that has changed.
I just read through the new documentation and size(r) is still a valid expression of ForwardRange. I was looking at the new sections on extending the library, and I'm a little confused. How do the free standing functions for library extension, boost_range_size() and boost::range_size() for example, relate to the range concepts? Before I was talking about boost::size() calling std::distance to do the work. Should it instead call these new functions? Daniel Walker
Daniel Walker wrote:
On 5/23/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Shunsuke Sogame wrote:
Daniel Walker wrote:
On 5/23/06, Shunsuke Sogame <mb2act@yahoo.co.jp> wrote:
BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range.
If I recall correctly applying boost::size() was intentional. size(r) is a valid expression for the ForwardRange concept,
Well, that has changed.
I just read through the new documentation and size(r) is still a valid expression of ForwardRange.
The docs are not updated yet. -Thorsten
On 5/23/06, Shunsuke Sogame <mb2act@yahoo.co.jp> wrote:
Daniel Walker wrote:
On 5/23/06, Shunsuke Sogame <mb2act@yahoo.co.jp> wrote:
BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range.
If I recall correctly applying boost::size() was intentional. size(r) is a valid expression for the ForwardRange concept, and I believe Thorsten didn't want ADL to kick in, so in the concept check implementation boost:: is used to qualify all the functions. boost::size() eventually dispatches either a size() member of the range object or std::distance().
Updated cvs shows 'boost::size' uses 'operator-' ? I somewhat wonder why 'boost::size' and 'boost::range_size' are not deprecated like 'boost::range_result_iterator'.
My bad. I just got the new range files (very busy the last few weeks) and there is a bug here. Actually, I think this is a case of the concept checks reveling a bug in the library. The following generates the error you're seeing. #include <boost/concept_check.hpp> #include <boost/iterator/iterator_archetypes.hpp> #include <boost/range/concepts.hpp> #include <boost/range/iterator_range.hpp> using namespace boost; using namespace std; int main() { typedef iterator_archetype< int, iterator_archetypes::readable_iterator_t, forward_traversal_tag > iterator_type; typedef iterator_range<iterator_type> range_type; function_requires<ForwardRangeConcept<range_type> >(); } The problem is that the ForwardRange concept requires the expression size(r) where r is an object of type X modeling ForwardRange and boost::range_iterator<X>::type is a model of ForwardTraversalIterator. However, the implementation of boost::size(r) expects X to provide operator-, which is an expression of RandomAccessTraversalIterator. So, I think either size(r) should be removed from the FowardRange concept (bad idea), or boost::size(r) should either offer a specialization for ForwardRanges or revert to dispatching the call to std::distance() (better idea?). Daniel
Shunsuke Sogame wrote:
Hi, I wrote an "interest" version of Boost.Range support for ATL/MFC:
http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename... or http://tinyurl.com/evddv
There are *40* ranges. The test is problematic...
what do you mean by that? Have you nowt tries the code? On what compilers does it work?
It is possible to fail to complete. :-(
What do you mean? I can't understand that sentence?
They are roughly tested under: VC7.1 + ATL7 + MFC7 VC8 + ATL3 and Boost.Range at cvs
BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range.
Thanks. I will put it onto the todo list. -Thorsten
Thorsten Ottosen wrote:
http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename...
There are *40* ranges. The test is problematic...
what do you mean by that? Have you nowt tries the code?
As you can see the vault, poor tests are included. I mean it is difficult to test 40 ranges. :-(
On what compilers does it work?
The goal is to support VC7.1/VC8.
It is possible to fail to complete. :-(
What do you mean? I can't understand that sentence?
I mean this is a sort of challenging work for me. :-) I had to write some framework to write 40 customizations. And some design choices seem to be needed. -- Shunsuke Sogame
Shunsuke Sogame wrote:
Thorsten Ottosen wrote:
http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename...
There are *40* ranges. The test is problematic...
what do you mean by that? Have you nowt tries the code?
As you can see the vault, poor tests are included. I mean it is difficult to test 40 ranges. :-(
Well, can't you run them through the same function template (which takes a range parameter) ? You don't have to do much inside that function, just apply begin() and end() and perhaps write the range to std::cout.
On what compilers does it work?
The goal is to support VC7.1/VC8.
Seems fine.
It is possible to fail to complete. :-(
What do you mean? I can't understand that sentence?
I mean this is a sort of challenging work for me. :-)
Well, judging from your code, you seem to know C++ very well. -Thorsten
participants (3)
-
Daniel Walker -
Shunsuke Sogame -
Thorsten Ottosen