From: Thomas Witt (witt_at_[hidden])
Date: 2005-09-07 15:44:17
David Abrahams wrote:
> Thomas Witt <witt_at_[hidden]> writes:
>>David Abrahams wrote:
> The second half of that sentence sounds rather sweeping and extreme.
Please don't read to much into it. It's just that I have serious doubts.
> It me took about 10 re-readings of this email to guess that us == the
> library developer and the component is, e.g. a pre-existing component
> like std::vector or builtin arrays. Did I get that right?
Sorry for not being more clear. You are basically right. Us means boost
or boost::range in particular.
>>In order to have our cake and eat it we move our
>>interface in our own namespace where we are free to do whatever we
> I don't see it that way. If we're using the strategy discussed here
> -- which I'm not claiming is ideal -- we do that part just to keep
> other authors of generic code from having to remember to write ugly
> using declarations.
I would not want to describe using declarations as ugly. They clearly
describe the intent of the programmer. Though I do agree that forgetting
about them is a very likely cause of error.
> In other words, aside from that ugly using declaration, which is
> needed to make the interface truly generic, the interface lives in the
> "global ADL space."
The point that I am concerned with is _which_ interface adds up in the
"global ADL space". IIUC the ADL hooks boost_range_begin etc. end up
there. AFAICS these are not meant to be used by a user of a library, are
> I guess if you view the using declaration as a
> kind of namespace qualification, you could see this as moving the
> interface into our namespace.
I was talking about functions like begin(), end() those end up in the
boost namespace, don't they.
>>The problem being that we cannot provide the interface for all types
>>out there but we still want this to be extensible. Furtheremore we
>>sure don't want anybody to invade our namespace
> I don't think we care about that last part, provided they do it in a
> way prescribed by us. Certainly, specialization is a kind of
> invasion, and that's no problem. The problem becomes that inviting
> the user to invade our namespace with _overloads_ just doesn't work
> because ordinary lookup is limited to what's visible at the
I got carried away in my writing. I am aware of the issue, if only for
the reason of getting bitten by ignorance in the past.
>>So what does that mean for the other libraries out there? They have
>>to clutter their interface with these hooks that are meant only for
>>communication with the boost library and that are useless if the
>>user of the other library does not use boost.
> Not if you buy Peter Dimov's argument that many customization points
> become "public domain" and are no longer the property of any library.
> Read that part of the thread carefully. Once people start supplying
> begin() hooks, other library authors may start making interfaces that
> work with Boost.Range compatible types.
I've read through his argument at least twice in the past. That being
said I might still not get the point. I do agree with the names
becomming public domain. What I disagree with is that names like
boost_range_begin are suitable for this. They will likely always be
warts in an interface.
>>Apart from the fact that the hook strategy is unlikely to scale well
>>(how many potentially useless hooks do you want in your library?)
> In my library? Useless? I'm confused. Am "I" the author of a
> library component who is trying to get it to work with other libraries
> like Boost.Range?
Just assume you are.
> Something like begin(x), if I'm the author of a container type, seems
> useful to me!
Yes begin() but not boost_range_begin()
> It might be used by anyone wanting to write composable generic
> algorithms over sequences. One of the problems with the STL interface
> is that composing the algorithms is more cumbersome than it should be.
I am all for a range concept. I am at odds with the proposed solution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk