namespace local/private variable and functions

[Simon]

Hi,

consider the following

// 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( ... )
     ...
   }
}

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?

And is there a better solution than using a static variable, 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.

So, can a namespace have a locally/(private?) declared function?
Is the use of a static variable advisable?

Many thanks

Simon

 

[Victor Bazarov]

Hi,

consider the following

// 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( ... )
...
}
}

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?

By no means. You make available whatever you deem as such. Namespace
or not, some functions and objects are going to be "private".

And is there a better solution than using a static variable, 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.

You use what you have to.

So, can a namespace have a locally/(private?) declared function?
Is the use of a static variable advisable?

It's either a static (having internal linkage) or a class static or a
member of unnamed namespace... It doesn't really matter. There are
different ways to implement singletons (whether they are const or not)
and you just pick the one that's easy for you to maintain.

V

 

[Andrey Tarasevich]

consider the following

// 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( ... )
...
}
}

The above code is legal, (as far as I can tell), but it does not look
very 'clean' to me.

It doesn't look very clean to me either.

Is it bad practice to have a function in the namespace that is not
accessible to the rest of the code?

Actually, it is technically "accessible" to the rest of the code, since
it is declared with external linkage. However, at the same you failed to
provide an author-supplied declaration for this function in the header
file. This makes it appear as if your function is hanging between the
two worlds of "public" functions and "private" functions, tempting other
users to declare this function by themselves (which they can do, but
which is definitely not a good practice), if they decide that they need
it for some reason.

And is there a better solution than using a static variable, 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.

So, can a namespace have a locally/(private?) declared function?

If you really intended this function to be "private", I's suggest that
in order to make the code cleaner, you should either give your function
internal linkage or put it into an anonymous namespace. This should make
it perfectly clear to other users that this function is not intended to
be used by anyone else.

Is the use of a static variable advisable?

That depends on your intent. Static variables are generally not
thread-safe, for example. Static variables might suffer from
initialization-order dependencies. Does any of that matter in your case?

 

[James Kanze]

consider the following

// header.h
namespace mynamespace{
void someFunction( ... );
}[/QUOTE]
[QUOTE]
...
// header.cpp
#include "someclass.h"[/QUOTE]
[QUOTE]
namespace mynamespace{
static someclass mSomePrivateClass;[/QUOTE]
[QUOTE]
void somePrivateFunction( ... )
{
// use mSomePrivateClass to do some more work
}[/QUOTE]
[QUOTE]
void someFunction( ... )
{
...
somePrivateFunction( ... )
...
}
}

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.