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