[algorithm][hex] function hex_char_to_int in unnamed namespace in header file
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. Regards, -- Felipe Magno de Almeida
On Nov 27, 2012, at 9:55 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> 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. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Tue, Nov 27, 2012 at 5:41 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 27, 2012, at 9:55 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> 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). So, the solution to being used by multiple translation units should be to declare it inline, and not use an unnamed namespace.
-- Marshall
Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Regards, -- Felipe Magno de Almeida
On Nov 27, 2012, at 11:53 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Tue, Nov 27, 2012 at 5:41 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 27, 2012, at 9:55 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> 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. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Mon, Dec 3, 2012 at 3:24 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 27, 2012, at 11:53 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Tue, Nov 27, 2012 at 5:41 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 27, 2012, at 9:55 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> 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-... 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
On Dec 3, 2012, at 9:43 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Mon, Dec 3, 2012 at 3:24 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 27, 2012, at 11:53 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Tue, Nov 27, 2012 at 5:41 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 27, 2012, at 9:55 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> 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-...
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@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Mon, Dec 3, 2012 at 5:58 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 3, 2012, at 9:43 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
[snip]
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.
Yes. The problem is not the call. Is that the definition of the inline function and/or template are different from each other. Because they refer to different functions in each TU. And that is a ODR violation. Let me try to illustrate: -- foo.h namespace { void foo() {} } -- bar.h #include "foo.h" template <typename T> void bar(T object) { foo(); } -- file1.cpp #include "bar.h" bar(5); -- file2.cpp #include "bar.h" bar(5); -- The template bar is defined differently for file1.cpp and file2.cpp because each identifier do not represent the same entity. Which is a ODR violation, since their definitions must equal to each other. The same would apply just as well for an inline function.
My mental model for unnamed namespaces is "a namespace with a unique compiler-generated name"
Yes, the same here. The problem is when a function,outside a unnamed namespace, uses something defined in a unnamed namespace, its definition can't be equal across multiple TUs anymore, because the namespace has a different "unique compiler-generated name".
-- Marshall
Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Regards, -- Felipe Magno de Almeida
Ping? On Mon, Dec 3, 2012 at 6:09 PM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Mon, Dec 3, 2012 at 5:58 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 3, 2012, at 9:43 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
[snip]
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.
Yes. The problem is not the call. Is that the definition of the inline function and/or template are different from each other. Because they refer to different functions in each TU. And that is a ODR violation.
Let me try to illustrate:
-- foo.h namespace { void foo() {} }
-- bar.h #include "foo.h" template <typename T> void bar(T object) { foo(); }
-- file1.cpp #include "bar.h"
bar(5);
-- file2.cpp #include "bar.h"
bar(5);
--
The template bar is defined differently for file1.cpp and file2.cpp because each identifier do not represent the same entity. Which is a ODR violation, since their definitions must equal to each other. The same would apply just as well for an inline function.
My mental model for unnamed namespaces is "a namespace with a unique compiler-generated name"
Yes, the same here. The problem is when a function,outside a unnamed namespace, uses something defined in a unnamed namespace, its definition can't be equal across multiple TUs anymore, because the namespace has a different "unique compiler-generated name".
-- Marshall
Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Regards, -- Felipe Magno de Almeida
-- Felipe Magno de Almeida
On December 3, 2012 11:58:54 PM Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 3, 2012, at 9:43 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
http://boost.2283326.n4.nabble.com/Boost-inspection-notification-2007-06-09-...
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.
Exactly, and that's what makes ODR violated. Imagine an inline function in a header, the function depends on the entity in an unnamed namespace. The function will be defined differently in each TU that includes the header, and that's UB.
participants (3)
-
Andrey Semashev -
Felipe Magno de Almeida -
Marshall Clow