Boost logo

Boost Users :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-05 06:38:15


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.

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.

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

Namespaces do not address this issue. 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+.

>>> 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_.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net