From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-06-22 09:07:12
"David Abrahams" <dave_at_[hidden]> wrote in message
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
| > "David Abrahams" <dave_at_[hidden]> wrote in message
| > news:ufyvh59yx.fsf_at_boost-consulting.com...
| > | "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
| > | > This came up in the long discussion we had some time ago about ADL and
| > | > names like begin()/end().
| > | >
| > | > I think the consensus was to use the form
| > | >
| > | > range::iterator<T>::type
| > | > range::value<T>::type
| > | > iterator::value<T>::type
| > | > iterator::difference<T>::type
| > |
| > | So I take it you just haven't had the time to make the change yet?
| > correct.
| > | > The only sorry thing about this is that in namespace std we already
| > | > have a class called iterator.
| > | ^
| > | template ;-)
| > |
| > | Yep, especially sorry because it's so useless ;-)
| > |
| > | OTOH we could give it an additional default argument so that when it
| > | is used as a unary metafunction it has the new semantics :-)
| > yeah, ok. I guess we could also demand that the range:: or iterator::
| > prefix is the name of a class.
| I don't understand what you're getting at here.
make value<T>::type etc nested classes of the iterator/range class.
| > | Ideally, you should have the semantic changes working in Boost well
| > | before you submit the proposal. Remember "standardize existing
| > | practice?"
| > Ideally yes. Do you find the standard process ideal? :-)
| No. I'm just trying to help you get your proposal accepted, Thorsten.
| > Anyway, I feel we have enough experience and that a C++0x standard
| > library without range support is going to hurt idiomatic C++0x.
| Unfortunately, it doesn't matter what you think in this case.
| The range idiom isn't in widespread use yet, and I'm not convinced we
| know the right design for a range library yet. More importantly, I
| think many committee members will take the same point of view. On the
| other hand, if you have a good stable interface well before the
| meeting, there's at least a chance some committee members will have
| experience with it by the time we vote, and that would be a huge
I'm not sure what beside Erics et al.s range_ex you want
to stabilize that hasn't already been discussed extensively.
Anyway, I plan to write the proposal in several "levels" s.t. the committee
stop at whatever level it feels is appropriate.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk