From: Richard Day (richardvday_at_[hidden])
Date: 2007-06-14 11:31:07
Sebastian Redl wrote:
> Arkadiy Vertleyb wrote:
>> The main problem of unnamed namespaces in headers is the possibility of ODR
>> violation. Has anyone seen any compiler complain about this?
> Not this case specifically, although I've seen complaints about more
> obvious violations of the ODR, e.g. when you try to link against two
> versions of the CRT in Visual C++. (Typically because you specify one
> and a static library you include has another in its dependencies.)
The reason it detects this is #defines not actual ODR code violations.
The tools are not there yet sadly.
This would require work on the linkers to detect ODR problems, I do not
see how the compiler could detect them.
At least not in a single pass, perhaps not even with multiple passes ?
>> Now, I don't know if this is an appropriate topic here, but I would question
>> the usefullness of the ODR itself.
> The ODR is a logical necessity, not a feature that may be useful or not.
> If the compiler generates two differing definitions of a symbol, how can
> the linker possibly know which one to use? And if it doesn't know which
> one to use, how can the program have defined behaviour?
> A better question would be whether to relax the ODR such that
> "equivalent" (under specific rules) multiple definitions do not cause
> the ODR to be violated, similar to what is already done for template
>> My main problem with it -- it
>> contradicts to quite useful, IMO, idiom, where a library author defines a
>> main template in his/her library as a customization point, and the users
>> provide specializations of this template (similar to virtual functions in
>> runtime world).
> What does this have to do with the ODR?
> Sebastian Redl
His last point is very unclear to me.
Perhaps he could clarify so we understand.
I think the point here is that it is very possible to introduce bugs
and/or side effects from using these unnamed namespaces in headers..
Like any other language construct it has its uses but is also easily abused.
Anonymous namespaces need to only be used after careful consideration of
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk