namespace local/private variable and functions

  • Follow


Hi,

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?

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
0
Reply bad (60) 10/6/2009 1:59:26 PM

Simon wrote:
> Hi,
> 
> 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?

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
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
0
Reply v.Abazarov (13255) 10/6/2009 2:21:52 PM


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

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?

-- 
Bets regards,
Andrey Tarasevich
0
Reply andreytarasevich (1531) 10/6/2009 5:04:46 PM

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


0
Reply james.kanze (9594) 10/7/2009 9:46:43 PM

3 Replies
42 Views

(page loaded in 0.048 seconds)

Similiar Articles:













7/22/2012 12:33:15 AM


Reply: