[range] concepts.hpp broken
Hi, range/concepts.hpp is utterly broken. You can't even include it. Anyone plans to fix it? or may I make a patch? -- Shunsuke Sogame
shunsuke skrev:
Hi,
range/concepts.hpp is utterly broken. You can't even include it. Anyone plans to fix it? or may I make a patch?
I could include it now in a test, but it might not be comlpetely properly specified yet. I'm working on updating on the much outdated docs, and will look at this too in the same round. -Thorsten
On 10/28/07, shunsuke <pstade.mb@gmail.com> wrote:
Hi,
range/concepts.hpp is utterly broken. You can't even include it. Anyone plans to fix it? or may I make a patch?
Could you be more specific? Which version of boost, compiler, etc. For example, I just tried the following with svn trunk, and it compiled without errors. $ cat test.cpp #include <boost/concept_check.hpp> #include <boost/range/concepts.hpp> #include <boost/range.hpp> using namespace boost; main() { function_requires<ForwardRangeConcept<iterator_range<int*> > >(); } $ g++ -dumpversion 4.1.2 $ g++ -Itrunk test.cpp Thanks, Daniel Walker
Daniel Walker wrote:
Could you be more specific? Which version of boost, compiler, etc. For example, I just tried the following with svn trunk, and it compiled without errors.
Sorry, that was svn trunk with msvc-8.0. Thorsten seems updating now. That is still broken, though. concepts.hpp(79) : error C2065: 'ci' is not defined. Regards, -- Shunsuke Sogame
On 10/28/07, shunsuke <pstade.mb@gmail.com> wrote:
Daniel Walker wrote:
Could you be more specific? Which version of boost, compiler, etc. For example, I just tried the following with svn trunk, and it compiled without errors.
Sorry, that was svn trunk with msvc-8.0.
Thorsten seems updating now. That is still broken, though. concepts.hpp(79) : error C2065: 'ci' is not defined.
Thanks. Yeah, I see Thorsten is in the processes of removing the checks with constant iterators. Has something changed with that? No more range_const_iterator? Daniel
Daniel Walker wrote:
Thanks. Yeah, I see Thorsten is in the processes of removing the checks with constant iterators. Has something changed with that? No more range_const_iterator?
Hmm, I'm not sure about Thorsten's thought. range_iterator is now nothing but a "client" metafunction which uses range_mutable_iterator and range_const_iterator. range_iterator should not be placed into concepts.hpp, IMHO. Regards, -- Shunsuke Sogame
shunsuke skrev:
Daniel Walker wrote:
Thanks. Yeah, I see Thorsten is in the processes of removing the checks with constant iterators. Has something changed with that? No more range_const_iterator?
Hmm, I'm not sure about Thorsten's thought. range_iterator is now nothing but a "client" metafunction which uses range_mutable_iterator and range_const_iterator. range_iterator should not be placed into concepts.hpp, IMHO.
You would rather see range_mutable_iterator and range_const_iterator there? What is the guideline one should follow? -Thorsten
Thorsten Ottosen wrote:
You would rather see range_mutable_iterator and range_const_iterator there? Yes.
I've found an interesting quote in doc/boost_range.html: The special metafunctions range_result_iterator and range_reverse_result_iterator are not part of any Range concept, You knew it. Regards, -- Shunsuke Sogame
shunsuke skrev:
Thorsten Ottosen wrote:
You would rather see range_mutable_iterator and range_const_iterator there? Yes.
I've found an interesting quote in doc/boost_range.html:
The special metafunctions range_result_iterator and range_reverse_result_iterator are not part of any Range concept,
You knew it.
Well, those docs are so old now, I'm not sure they should be take too seriously. The formulation I'm leaning towards in the new docs are the following: Single Pass Range: types: range_iterator<T>::type range_iterator<const T>::type range_size<T>::type expresions: boost::begin(r) boost::end(r) ... Random Access Range: expressions: boost::size(r); Now, the ways you provide a concept map may involve types such as range_mutable_iterator, const_iterator, and functions range_begin/range_end. -Thorsten
On 10/29/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
shunsuke skrev:
Thorsten Ottosen wrote:
You would rather see range_mutable_iterator and range_const_iterator there? Yes.
I've found an interesting quote in doc/boost_range.html:
The special metafunctions range_result_iterator and range_reverse_result_iterator are not part of any Range concept,
You knew it.
Well, those docs are so old now, I'm not sure they should be take too seriously.
The formulation I'm leaning towards in the new docs are the following:
Single Pass Range:
types:
range_iterator<T>::type range_iterator<const T>::type
What if you have a non-const range of const_iterators? It seems like you still need range_const_iterator.
range_size<T>::type
expresions:
boost::begin(r) boost::end(r)
...
Random Access Range:
expressions: boost::size(r);
This is good. It looks the same as the currently documented concepts except the syntax of return types of functions needs to be specified; i.e. the return type of begin(r) may be assigned to range_iterator<T>::type, etc.
Now, the ways you provide a concept map may involve types such as range_mutable_iterator, const_iterator, and functions range_begin/range_end.
What do you mean by "concept map?" Are you referring to C++0x concept_map? Or do you mean these types and functions will help users implement a type that models a range concept in C++98 terms? I think the later, but I want to make sure. Daniel
Daniel Walker skrev:
On 10/29/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
shunsuke skrev:
Thorsten Ottosen wrote:
You would rather see range_mutable_iterator and range_const_iterator there? Yes.
I've found an interesting quote in doc/boost_range.html:
The special metafunctions range_result_iterator and range_reverse_result_iterator are not part of any Range concept,
You knew it. Well, those docs are so old now, I'm not sure they should be take too seriously.
The formulation I'm leaning towards in the new docs are the following:
Single Pass Range:
types:
range_iterator<T>::type range_iterator<const T>::type
What if you have a non-const range of const_iterators? It seems like you still need range_const_iterator.
Why?
range_size<T>::type
expresions:
boost::begin(r) boost::end(r)
...
Random Access Range:
expressions: boost::size(r);
This is good. It looks the same as the currently documented concepts except the syntax of return types of functions needs to be specified; i.e. the return type of begin(r) may be assigned to range_iterator<T>::type, etc.
right.
Now, the ways you provide a concept map may involve types such as range_mutable_iterator, const_iterator, and functions range_begin/range_end.
What do you mean by "concept map?" Are you referring to C++0x concept_map?
I'm referring to the same idea. Until now we didn't really have a good terminology for what it meant to "extend the library".
Or do you mean these types and functions will help users implement a type that models a range concept in C++98 terms? I think the later, but I want to make sure.
Right. -Thorsten
On 10/29/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Daniel Walker skrev:
On 10/29/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
shunsuke skrev:
Thorsten Ottosen wrote:
You would rather see range_mutable_iterator and range_const_iterator there? Yes.
I've found an interesting quote in doc/boost_range.html:
The special metafunctions range_result_iterator and range_reverse_result_iterator are not part of any Range concept,
You knew it. Well, those docs are so old now, I'm not sure they should be take too seriously.
The formulation I'm leaning towards in the new docs are the following:
Single Pass Range:
types:
range_iterator<T>::type range_iterator<const T>::type
What if you have a non-const range of const_iterators? It seems like you still need range_const_iterator.
Why?
I was thinking of a scenario where mutability and constness don't correlate - for example, when an immutable range is not const. However, after taking a second glance at the old docs, I'm not sure this applies to ranges. The return type of begin(r) has always been tied to the constness of r, which is confusing for a non-const immutable range. So, you're suggesting to stop using types to distinguish the mutability of ranges? I think I get it, yeah, that could clean things up. So, if the range is made up of const_iterators, range_iterator<T>::type is const_iterator, and if the range is made up of mutable iterators, range_iterator<T>::type is iterator. begin(r) always returns range_iterator<T>::type: range_const_iterator<T>::type is no longer needed. It does simplify matters. Daniel
Thorsten Ottosen wrote:
Single Pass Range:
types:
range_iterator<T>::type range_iterator<const T>::type
You mean range_mutable_iterator is no longer a public interface but a customization point? It seems a rational idea; "NVI" is always better. range_iterator<remove_const<T>::type> might be cumbersome, though. BTW, why not remove range_size<> from RandomAccessConcept, which is utterly useless, and even wrong around iterator range. Regards, -- Shunsuke Sogame
shunsuke skrev:
Thorsten Ottosen wrote:
Single Pass Range:
types:
range_iterator<T>::type range_iterator<const T>::type
You mean range_mutable_iterator is no longer a public interface but a customization point?
yes.
It seems a rational idea; "NVI" is always better.
nvi?
range_iterator<remove_const<T>::type> might be cumbersome, though.
well, it shouldn't be neede that much.
BTW, why not remove range_size<> from RandomAccessConcept, which is utterly useless, and even wrong around iterator range.
I'm all for removing it. Why do you think it's wrong? -Thorsten
Thorsten Ottosen wrote:
It seems a rational idea; "NVI" is always better.
nvi?
Non-Virtual Interface. Say, Non-Specializable-Metafunction in this context? :-)
BTW, why not remove range_size<> from RandomAccessConcept, which is utterly useless, and even wrong around iterator range.
I'm all for removing it.
Why do you think it's wrong?
`boost::size(make_iterator_range(...))` would copy range_difference<...>::type into std::size_t. boost::make_unsigned<> might help, but anyway it is unneeded to force range_size<> specialization. Regards, -- Shunsuke Sogame
shunsuke skrev:
Thorsten Ottosen wrote:
It seems a rational idea; "NVI" is always better. nvi?
Non-Virtual Interface. Say, Non-Specializable-Metafunction in this context? :-)
BTW, why not remove range_size<> from RandomAccessConcept, which is utterly useless, and even wrong around iterator range. I'm all for removing it.
Why do you think it's wrong?
`boost::size(make_iterator_range(...))` would copy range_difference<...>::type into std::size_t.
If the requirent is that the secnd iterator is reachable from the first, there is no problem.
boost::make_unsigned<> might help, but anyway it is unneeded to force range_size<> specialization.
I think I agree. Do anybody what to argue for inclusion of range_size<> in the concept? -Thorsten
Thorsten Ottosen wrote:
`boost::size(make_iterator_range(...))` would copy range_difference<...>::type into std::size_t.
If the requirent is that the secnd iterator is reachable from the first, there is no problem.
Overflow may occur. boost::size(make_iterator_range(..)) behavior seems undefined for now. Regards, -- Shunsuke Sogame
participants (3)
-
Daniel Walker -
shunsuke -
Thorsten Ottosen