What is the rationale behind this name? It seems unintuitive to me, and what's more, unneccessary. Shouldn't range_iterator<T const>::type just be range_const_iterator<T>::type? If not, why not? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u1x8pceqw.fsf@boost-consulting.com... | | What is the rationale behind this name? | It seems unintuitive to me, | and what's more, unneccessary. why? | Shouldn't | range_iterator<T const>::type just be range_const_iterator<T>::type? | | If not, why not? container::const_iterator is the parallel. -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u1x8pceqw.fsf@boost-consulting.com... | | What is the rationale behind this name? It seems unintuitive to | me, and what's more, unneccessary.
why?
Unintuitive: it's not clear what The "result" part refers to. It's such a generic word when applied to a (meta)function that it lacks obvious semantic content... it's almost like naming the max fucntion "result_of_max."
| Shouldn't range_iterator<T const>::type just be | range_const_iterator<T>::type? | | If not, why not?
container::const_iterator is the parallel.
That doesn't explain anything (to me). What I was asking was: why provide this oddly-named metafunction when people could just make the inquiry using range_iterator with a const argument? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uk6mga3yb.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "David Abrahams" <dave@boost-consulting.com> wrote in message | > news:u1x8pceqw.fsf@boost-consulting.com... | > | | > | What is the rationale behind this name? It seems unintuitive to | > | me, and what's more, unneccessary. | > | > why? | | Unintuitive: it's not clear what The "result" part refers to. It's | such a generic word when applied to a (meta)function that it lacks | obvious semantic content... it's almost like naming the max fucntion | "result_of_max." well, I think const_if_arg_is_const_mutable_otherwise_iterator<T>::type was considered. ideas are welcome. | > | > | Shouldn't range_iterator<T const>::type just be | > | range_const_iterator<T>::type? | > | | > | If not, why not? | > | > container::const_iterator is the parallel. | | That doesn't explain anything (to me). What I was asking was: why | provide this oddly-named metafunction when people could just make the | inquiry using range_iterator with a const argument? I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator. -Thorten
Thorsten Ottosen wrote:
I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator.
I'm not sure how did container<T const> enter the picture. Isn't range_iterator<R>::type the iterator type of the range R? Isn't it the return type of r.begin(), where r is of type R (in the typical container case)? Doesn't r.begin() return R::const_iterator when R is const?
"Peter Dimov" <pdimov@mmltd.net> writes:
Thorsten Ottosen wrote:
I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator.
Isn't range_iterator<R>::type the iterator type of the range R?
Yes, in a world where iterator and const_iterator are distinguished.
Isn't it the return type of r.begin(), where r is of type R (in the typical container case)?
Not when R is const. In that case you get the const_iterator type. Unless you live in the world I'm proposing, in which case the iterator type of C const is C's const_iterator type.
Doesn't r.begin() return R::const_iterator when R is const?
Yes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Thorsten Ottosen wrote:
I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator.
Isn't range_iterator<R>::type the iterator type of the range R?
Yes, in a world where iterator and const_iterator are distinguished. [...]
My question is to be read as follows: Is it not the design intent of range_iterator<R>::type to give the iterator type of the range R, so that I can write: template<class R> void f( R & r ) { typename range_iterator<R>::type i = r.begin(); } and hence, is it not perfectly logical for it to return C::const_iterator for R == C const? It was meant to support your point.
Peter Dimov wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Thorsten Ottosen wrote:
I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator.
Isn't range_iterator<R>::type the iterator type of the range R?
Yes, in a world where iterator and const_iterator are distinguished. [...]
My question is to be read as follows:
Is it not the design intent of range_iterator<R>::type to give the iterator type of the range R, so that I can write:
template<class R> void f( R & r ) { typename range_iterator<R>::type i = r.begin(); }
and hence, is it not perfectly logical for it to return C::const_iterator for R == C const?
It was meant to support your point.
My understanding of the current design is that this is the purpose of range_result_iterator, so I would rewrite your code as: template<class R> void f( R & r ) { typename range_result_iterator<R>::type i = r.begin(); } range_iterator always evaluates to R::iterator regardless of the const-ness of R, and range_const_iterator always evaluates to R::const_iterator. In my experience with Boost.Range, I have found range_result_iterator to be useful. I have found little need for range_iterator and range_const_iterator. YMMV. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:427903CB.4060808@boost-consulting.com... | | Peter Dimov wrote: | > template<class R> void f( R & r ) | > { | > typename range_iterator<R>::type i = r.begin(); | > } | > | > and hence, is it not perfectly logical for it to return | > C::const_iterator for R == C const? | > | > It was meant to support your point. | | | My understanding of the current design is that this is the purpose of | range_result_iterator, so I would rewrite your code as: | | template<class R> void f( R & r ) | { | typename range_result_iterator<R>::type i = r.begin(); | } | | range_iterator always evaluates to R::iterator regardless of the | const-ness of R, and range_const_iterator always evaluates to | R::const_iterator. | | In my experience with Boost.Range, I have found range_result_iterator to | be useful. I have found little need for range_iterator and | range_const_iterator. YMMV. this is a good point; we mostly just need range_result_iterator<T> so it could just be spelled range::iterator<T>. -Thorsten
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Thorsten Ottosen wrote:
I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator.
Isn't range_iterator<R>::type the iterator type of the range R?
Yes, in a world where iterator and const_iterator are distinguished. [...]
My question is to be read as follows:
Is it not the design intent of range_iterator<R>::type to give the iterator type of the range R, so that I can write:
template<class R> void f( R & r ) { typename range_iterator<R>::type i = r.begin(); }
and hence, is it not perfectly logical for it to return C::const_iterator for R == C const?
It was meant to support your point.
I know, and I know what you meant. I just wanted to be accurate. Probably my overly-literal mind at "work" again. Sorry. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uk6mga3yb.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "David Abrahams" <dave@boost-consulting.com> wrote in message | > news:u1x8pceqw.fsf@boost-consulting.com... | > | | > | What is the rationale behind this name? It seems unintuitive to | > | me, and what's more, unneccessary. | > | > why? | | Unintuitive: it's not clear what The "result" part refers to. It's | such a generic word when applied to a (meta)function that it lacks | obvious semantic content... it's almost like naming the max fucntion | "result_of_max."
well, I think const_if_arg_is_const_mutable_otherwise_iterator<T>::type was considered.
ideas are welcome.
range::iterator<T>::type
| > | Shouldn't range_iterator<T const>::type just be | > | range_const_iterator<T>::type? | > | | > | If not, why not? | > | > container::const_iterator is the parallel. | | That doesn't explain anything (to me). What I was asking was: why | provide this oddly-named metafunction when people could just make the | inquiry using range_iterator with a const argument?
I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator.
That's because (among other things) a container of const T is illegal. And it's the wrong analogy anyway. The analogy would be container<T> const::iterator if such a syntax were legal. Accessing nested data types directly is usually wrong for generic code anyway, so I'm not sure that makes such a great precedent to follow. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Eric Niebler -
Peter Dimov -
Thorsten Ottosen