Boost logo

Boost :

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
>>see fit.
> 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
> point-of-definition.

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
for that.


Boost list run by bdawes at, gregod at, cpdaniel at, john at