Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-14 15:20:57

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

> Gennaro Prota wrote:
>> On Thu, 14 Sep 2006 07:00:26 -0400, David Abrahams
>> <dave_at_[hidden]> wrote:
>>> Gennaro Prota <gennaro_prota_at_[hidden]> writes:
>>>> On Wed, 13 Sep 2006 22:00:09 +0200, Thorsten Ottosen
>>>> <thorsten.ottosen_at_[hidden]> wrote:
>>>>> What is the problem with an unnamed namespace in a header anyway?
>>>>> Is it illegal according to the standard?
>>>> Thorsten, this is not addressed to you, but I find shameful that so
>>>> many boosters don't know this C++ 101.
>>> Now, now, Genny. I don't recall anyone ever talking about the
>>> problem until I raised it a year or two ago.
>> And here's the ego I was talking about. You may feel like the first
>> man who brought the light on all us, but that light is common advice
>> for any comp.lang.c++.moderated regular.
> Not quite... the general advice against putting unnamed namespaces in
> headers is one thing, explaining how the constant variable (unnamed)::_1
> technically causes ODR violations is another.
> In practice, Bind is getting away with this kind of a technical ODR
> violation on every supported compiler.

Yes, and let me support that assertion by saying it's probably going
to continue to work on every C++ compiler we ever encounter. Maybe
some fancy lint tool would be able to detect it. It's really only a
technical violation of the standard. But that said, I don't like the
idea of, entrapment even if the crime commited is victimless... or
something. I hope y'all see my point.

> But my question wasn't about ODR violations or egos. I asked what is the
> proper course of action for a library developer whose library has been
> flagged by the report. And it seems that nobody knows. I can remove the
> unnamed namespace (at some cost) but this is a potentially destabilizing
> change and not suited for 1.34, against which the report is being run.

I agree. I think you should put the report silencing directive in the
RC_1_34_0 branch only, with a note saying that we will address it in
the next release. How does that sound to you?

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at