[boost] Re: range_result_iterator

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-04 11:37:01

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message 
> news:uk6mga3yb.fsf_at_boost-consulting.com...
> | "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> |
> | > "David Abrahams" <dave_at_[hidden]> wrote in message
> | > news:u1x8pceqw.fsf_at_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