Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2005-03-24 12:33:24


Thorsten Ottosen wrote:
> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:umzstxh18.fsf_at_boost-consulting.com...
> | "Eric Niebler" <eric_at_[hidden]> writes:
>
> | It's not an entirely different argument. Peter was saying that once
> | you publicize the customization point, it no longer "belongs" to the
> | library. Imagine what happens if some other library wanted to use the
> | same range concept, but not depend on Boost itself. Either they'd be
> | picking a new ugly name for a customization point with identical
> | semantics :( or they'd be using the name "boost_range_begin" in code
> | with no Boost relationship in sight :(.
> |
> | As my wife's co-worker says, "it's a two-headed sword" ;-)
> |
> | For that reason, it might be better to use something like
> | "iterator_range_begin" that has a hope of becoming lingua franca like
> | swap. At least that's how I understand Peter's argument.
>
> Hm.. yeah...I guess you're better at expressing my point than
> I myself :-)
>
> iterator_range_ seems to be a good prefix.
>
> What do you say, Eric, do you like
> iterator_range_begin() etc?
>

I'm finally beginning to grasp the full implications of Peter's comments
about customization points. Thanks for the clear explanation, Dave, and
Thorsten, I now understand what you were saying.

I have a couple of concerns with "iterator_range_begin". First, as Pavol
says, it suggests an association with the iterator_range<> type. But
also, in my understanding, the Range concept is a bit more inclusive
than merely "iterator ranges". A std container satisfies the Range
concept, doesn't it? Consider iterator_range_size(). I could have a
container that satisfies the range concept for which .size() is an O(1)
operation, but std::distance( .begin(), .end() ) is O(N). What Big-O is
suggested by "iterator_range_size()" when applied to one of those contaiers?

So, our concern here is that someone could borrow boost's Range concept
without using boost's Range code? But this is still boost's Range
concept, so I'm not sure I agree with Dave that there is "no Boost
relationship in sight". But I'll put that aside and plan for a future
when the Range concept is widely recognized outside Boost. Calling it
"range_begin()" leads to conflicts, but can they be resolved? Can we
move the conflicting template into a different namespace?

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

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