Boost logo

Boost :

From: Thomas Witt (witt_at_[hidden])
Date: 2005-09-12 11:55:12

David Abrahams wrote:
> Unfortunately, no. But what can you do when such a major compiler as
> GCC makes it impossible to use a simpler name without stomping on
> another Boost library?

Point taken.

> Yeah, they sure do, and -- at least from one valid perspective --
> appropriately so. The begin semantics you're interested in when you
> call boost::begin(x) are those that have been defined by Boost.Range,
> and not some other idea of what "begin" means.

Given this "narrow" (no belittlement intended) view I tend to agree. Is
it correct to say that this view does not lead to the idea of "public
domain" customization points as expressed below?

>>> 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.
> What should the name be?

A suitable name for a "public domain" customization point as I see it
would be begin(). That being said it's not necessarily the right
solution in this case.

>> They will likely always be warts in an interface.
> Why do you think of them as part of the interface, if, as you say,
> they're not intended to be used directly by end-users? The fact that
> they appear in the header file, or even in the same namespace with
> public interface elements, doesn't automatically make them interface
> elements. To be an interface element, a function must be documented
> as such. These hooks have the same role as a class template
> specialization in the library namespace would.

As much as I sympathize with this view. My experience shows this is not
the way it works in practice.

>>>> 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.
> Well, it's not useless if it makes my component work with
> BOOST_FOREACH. So I still don't understand your question.

When I say 'useless' I mean useless in this specific usage scenario.
I.e. somebody uses library A but not boost. In this case boost hooks in
library A are 'useless'.

> Clearly. All I'm hearing from you are complaints, without a proposal
> for an alternative that works.

My main concern is that the proposed solution using specific ADL hooks
does not scale.

I would prefer an approach where a Range concept is specified that any
type can model without ever referring to boost. The role of boost.range
would be to provide a range interface for often used types that
otherwise won't have one.

> The problem of building customization points for generic C++ libraries
> has no really satisfying solution at the moment. Any approach we
> choose will be a compromise.


> It isn't clear to me why this particular
> compromise should be deemed worse than any of the others.

The reason I think it's worse is that I think it does not scale. That
being said, I'll stop complaining now and we'll see what time will tell.
It might well prove me wrong.


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