[inspection] Unnamed namespaces in include files [was: Boost inspection notifications (RC_1_34_0)]

On Tue, 25 Jul 2006 16:02:46 -0500, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> wrote:
Rene Rivera wrote:
|wave| boost/wave/cpplexer/validate_universal_char.hpp: *U* unnamed namespace at line 39 boost/wave/util/cpp_iterator.hpp: *U* unnamed namespace at line 1253 *U* unnamed namespace at line 1654 *U* unnamed namespace at line 414 *U* unnamed namespace at line 799
This puzzles me a bit because I thought, that unnamed namespaces in headers are problematic only if these are in the global namespace. The unnamed namespaces above are inside the boost::wave namespace, I can't see any harm in that.
But what is the benefit? I think that's the key question. If they don't have any they are just misleading. I'd say there are very few exceptions to this (in truth the only one which comes to mind is the nifty counter idiom). -- [ Gennaro Prota, C++ developer for hire ]

Gennaro Prota wrote:
Rene Rivera wrote:
|wave| boost/wave/cpplexer/validate_universal_char.hpp: *U* unnamed namespace at line 39 boost/wave/util/cpp_iterator.hpp: *U* unnamed namespace at line 1253 *U* unnamed namespace at line 1654 *U* unnamed namespace at line 414 *U* unnamed namespace at line 799
This puzzles me a bit because I thought, that unnamed namespaces in headers are problematic only if these are in the global namespace. The unnamed namespaces above are inside the boost::wave namespace, I can't see any harm in that.
But what is the benefit? I think that's the key question. If they don't have any they are just misleading. I'd say there are very few exceptions to this (in truth the only one which comes to mind is the nifty counter idiom).
It's just an easy way to move a helper function 'out of the way'. But as always it's a matter of taste and personal style so I'm not going to argue with you :-P The mentioned problems are fixed now. Regards Hartmut

On Tue, 25 Jul 2006 19:25:04 -0500, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> wrote:
But what is the benefit? I think that's the key question. If they don't have any they are just misleading. I'd say there are very few exceptions to this (in truth the only one which comes to mind is the nifty counter idiom).
It's just an easy way to move a helper function 'out of the way'. But as always it's a matter of taste and personal style so I'm not going to argue with you :-P
Why not :-P Not sure what do you mean by 'out of the way' here. The whole unnamed namespace is still subject to an implicit using declaration: namespace { void my_helper(); } behaves the same as namespace name_unique_to_the_translation_unit {} using name_unique_to_the_translation_unit; namespace name_unique_to_the_translation_unit { void my_helper(); } Thus: // a.hpp // namespace wave { namespace { void my_helper(); } } // a.cpp // #include "a.hpp" namespace wave { int my_helper(); void f() { my_helper(); // oops! } } Comparing this with the version without unnamed namespace it seems to me it only allows the error to go undetected longer (i.e. until you attempt the function call)
The mentioned problems are fixed now.
Thanks, but please only fix things if you are convinced that they need to be fixed. There's no authority here :-) -- [ Gennaro Prota, C++ developer for hire ]

Gennaro Prota wrote:
The mentioned problems are fixed now.
Thanks, but please only fix things if you are convinced that they need to be fixed. There's no authority here :-)
Sure, but it doesn't hurt to fix them :-P Regards Hartmut
participants (2)
-
Gennaro Prota
-
Hartmut Kaiser