[Boost-users] Re: [Foreach]TroubleiteratingoverBoost.MultiIndexcontainers

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-05 08:19:09

"Peter Dimov" <pdimov_at_[hidden]> writes:

> Ian McCulloch wrote:
>> Peter Dimov wrote:
>>
>>> Right. And if they did not collide, nothing would become a de-facto
>>> standard, because people could keep using their own versions. There
>>> would be no pressure to resolve these collisions.
>>
>> So even on boost, such collisions occur - what about libraries that
>> are developed completely independently?  Which politburo is to decide
>> how each name is supposed to be used?  How is it to be enforced?
>
> It is unenforceable, of course. But this doesn't mean that it can't
> happen.  Library authors are, in general, reasonable people; they do
> cooperate and do respond to issues.

I don't know about that.  The various placeholders in Boost still have
usability problems when #included together.  And the bind placeholders
are still causing ODR violations.  It's all very well that library
writers may adjust eventually, but users can't always upgrade, or they
can't always upgrade quickly.  There ought to be a mechanism for
staying out of one another's way.

> This isn't really specific to ADL customization points. Consider, for 
> example, container requirements, where a.begin() must return A::iterator or 
> A::const_iterator. What happens if another library has its own requirements 
> table that specifies different semantics for a.begin()? Can I make my 
> container conform to these requirements as well? Of course not.

That's why generic library writers have developed a guideline to write
concept requirements that don't depend on member functions.

>> And wern't namespaces supposed to solve these issues anyway?
>
> The central question is: can we, the C++ community, decide on a common 
> vocabulary for the primitive operations a type supports? If we can, there is 
> no problem.

I disagree most strongly.  

One problem is that not all operations are going to be considered
"primitive."  More importantly, there should be a way to develop
software with confidence that it has a future and scales well, without
having to worry that all customizable names are "pending the
community's verdict on common meaning."

> Namespaces do not address this issue. 

Because of ADL.

> They are a way to partition identifiers that belong to a specific
> library. Inter-library communication, by its nature, touches two or
> more different namespaces. No library "owns" swap, or operator+.

It would be much better if every one of those was "owned" by a library
-- if only we had the language mechanisms to make it work.  When these
things become part of the "common vocabulary" they can be added to the
common list of using-declarations and used without qualification.  Of
course operator+ (the one that adds, and the one that concatenates
strings) would have been in the common list from the get-go, and we'd
have put swap there by now too.

>>>> Just consider the widespread use of numeric types in all kinds of
>>>> domain-specific applications.  Is every library going to pick the
>>>> same meaning for
>>>>
>>>>        zero(x)
>>>>
>>>> ??
>>>
>>> Yes, I hope so. I also hope that they would pick the same meaning
>>> for x+y.
>>
>> Ok, quick (but serious) question: What are the semantics of zero(x) ?
>
> I don't know; this is Dave's example. Whatever the community decides, as 
> long as it's consistent. The user should learn what it means _once_.

It could take many years for a name like that to settle down,
especially if two major libraries with strong user base and
backward-compatibility considerations pick competing definitions.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com