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.
Agreed.
> 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.
Thomas