Re: [boost] [range] How to extend Boost.Range?

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