Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-06-22 17:29:29


"David Abrahams" <dave_at_[hidden]> wrote in message
news:u7jgm77rf.fsf_at_boost-consulting.com...
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
|
| > "David Abrahams" <dave_at_[hidden]> wrote in message
| > news:u64w6a66h.fsf_at_boost-consulting.com...
| > | "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
| > |
| > | > 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.
|
| Bad idea IMO; it means nobody can adapt a 3rd party type or a builtin
| to make it fit the Range concept. It's the same reason we use traits
| instead of requiring nested type names.

yeah, seems bad. I don't understand how you would define
std::iterator::value<T>::type etc then?

| > | 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
| > | advantage.
| >
| > I'm not sure what beside Erics et al.s range_ex you want
| > to stabilize that hasn't already been discussed extensively.
|
| It doesn't matter how extensively it has been discussed if it
| hasn't been implemented and used widely.
|
| > Anyway, I plan to write the proposal in several "levels" s.t. the
| > committee can stop at whatever level it feels is appropriate.
|
| Not a great idea either, IMO. If you give the committee too many
| options, people tend to either get confused, or get mired in arguments
| about which one to choose. A simple proposal stands a much better
| chance.

perhaps. At the Lillehammer meeting Walter Brown presented his
idea of adding const_begin() member to the containers and the
possibility of having free-standing begin()/end() functions.
So apparently experience was not an issue with this stuff.

People liked the idea even though he didn't even mentioned the more elaborate
boost.range. Then I said that I would like to work with Walter on this because
of my experience from boost with this stuff. It turned out that I became more
or less the
sole proposer.

| I have been trying to help you, but I'm feeling rather discouraged
| now. Unless you tell me you want more of this kind of input, I'll
| just stop now.

Sorry if I sounded arrogant (as usual). I've quite stressed at the moment.

I always appreciate any feedback, even if I don't agree with the feedback.

best regards

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk