Re: [boost] [algorithm][hex] function hex_char_to_int in unnamed namespace in header file

Subject: Re: [boost] [algorithm][hex] function hex_char_to_int in unnamed namespace in header file
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2012-12-03 12:43:19

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

> -- Marshall

Regards,
-- 
Felipe Magno de Almeida