Re: namespace local/private variable and functions
On Oct 6, 3:59 pm, Simon <b...@example.com> wrote:
consider the following
[code]
// header.h
namespace mynamespace{
void someFunction( ... );
}
...
// header.cpp
#include "someclass.h"
namespace mynamespace{
static someclass mSomePrivateClass;
void somePrivateFunction( ... )
{
// use mSomePrivateClass to do some more work
}
void someFunction( ... )
{
...
somePrivateFunction( ... )
...
}
}
[/code]
The above code is legal, (as far as I can tell), but it does
not look very 'clean' to me.
Is it bad practice to have a function in the namespace that is
not accessible to the rest of the code?
A function in a namespace is always accessible to the rest of
the code. There are no access specifiers in namespaces. If you
don't want the function to be accessible outside of the
translation unit, either put it in an unnamed namespace, or
declare it static (or both:-))---the unnamed namespace is the
generally preferred solution today.
And is there a better solution than using a static variable,
Hard to say, since you don't specify the problem. There are
certainly cases where variables with static lifetime are
justified---whether you choose to declare these static, or put
them in an unnamed namespace is generally a question of style
(but as I said, the current trend is to prefer the unnamed
namespace).
the problem in my case is that the class constructor is not
really slow and, as the data never changes, it would be
foolish to call it over and over simply to be cosmetically
correct.
In which case, the object should probably be declared const.
So, can a namespace have a locally/(private?) declared
function? Is the use of a static variable advisable?
A namespace can't have a private function; namespaces don't have
access control. But you can certainly declare a function
anywhere you please in a namespace. As for the variable with
static lifetime, it depends somewhat on what it is being used
for, and its type. Variables with static lifetime are subject
to order of initialization issues, but if you can guarantee that
the variable won't be used in the constructors of other objects
with static lifetime, or if you can arrange for it to have
static initialization (i.e. make it a struct, and use
agglomerate initialization, with only constant expressions),
then this is not a problem. Otherwise, it's probably
preferrable to use some variant of the singleton idiom.
--
James Kanze