Boost logo

Boost :

Subject: Re: [boost] [algorithm][hex] function hex_char_to_int in unnamed namespace in header file
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2012-12-03 14:58:54


On Dec 3, 2012, at 9:43 AM, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> wrote:

> On Mon, Dec 3, 2012 at 3:24 PM, Marshall Clow <mclow.lists_at_[hidden]> wrote:
>> On Nov 27, 2012, at 11:53 AM, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> wrote:
>>
>>> On Tue, Nov 27, 2012 at 5:41 PM, Marshall Clow <mclow.lists_at_[hidden]> wrote:
>>>> On Nov 27, 2012, at 9:55 AM, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> AFAIK, unnamed namespaces are dangerous in headers. There is a
>>>>> commentary just above the function definition:
>>>>>
>>>>> // this needs to be in an un-named namespace because it is not a template
>>>>> // and might get included in several compilation units. This could cause
>>>>> // multiple definition errors at link time.
>>>>>
>>>>> But it seems the better thing would be to define it inline. It is
>>>>> exactly because it can be used in several
>>>>> translation units that it can cause an ODR violation if defined
>>>>> in a unnamed namespace AFAIK.
>>>>
>>>> I have no problem with declaring it inline, but that's just a suggestion.
>>>> The compiler is completely free to generate code for it out-of-line.
>>>
>>> I didn't meant I want the function to be inlined by the compiler. What I mean
>>> is that putting it in a unnamed namespace causes undefined behavior(AFAIK).
>>
>> I don't believe that's true, but I'm willing to be convinced.
>
> http://boost.2283326.n4.nabble.com/Boost-inspection-notification-2007-06-09-RC-1-34-0-X-tt2628426.html#a2628478
>
> AFAIK, an unnamed namespace creates different entities for each
> translation on which it is defined (by #inclusion,
> for example).

Yes.

> If any entity defined in a unnamed namespace is used in
> an external linkage definition, such as a
> inline function or a template definition and this definition is used
> in multiple TUs it causes ODR violations, because
> it is defined differently (uses different entities) in each TU.

And No. Because the call to it (in each TU) will call the entity in the specific unnamed namespace that was part of that translation unit.

My mental model for unnamed namespaces is "a namespace with a unique compiler-generated name"

-- Marshall

Marshall Clow Idio Software <mailto:mclow.lists_at_[hidden]>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk