Is there 'private' in namespace?

[Peng Yu]

Hi,

I'm wondering if there is something in namespace like the 'private'
keyword in class?

I want to define some class or function that can only be used within
that namespace.

Thanks,
Peng

 

[Yuhan Fang]

I want to define some class or function that can only be used within
that namespace.

I don't think it's possible to restrict access to a globally available
class. If you are looking for functions that can only be used within
namespaces, then use a class and static methods.

 

[James Kanze]

I'm wondering if there is something in namespace like the
'private' keyword in class?

I want to define some class or function that can only be used
within that namespace.

Namespaces are open (anyone can add a member to a namespace,
anywhere), so there's no point in private.

 

[Peng Yu]

Namespaces are open (anyone can add a member to a namespace,
anywhere), so there's no point in private.

I'd think a private in namespace might be useful.

For example, I'm code a class C in namespace N. To code C, I might
need define some classes or functions, which are not used by other
classes other than C. I would not want to defines these classes or
functions in side C, because if I do it this way, I would not be able
to separate them from C into two different files, which would make it
harder to test and understand the code.

Since these classes or functions are for C, I'd like to keep them in
the same namespace as C.

Since these classes or functions are not for other classes other than
C, ideally, I would like to specify somehow in C++ that they are for C
only. For now, what I can possibly think of is to add 'private' in
'namespace' such that at least classes outside N would not be able to
call these functions or classes.

Thanks,
Peng

 

[peter koch]

I'd think a private in namespace might be useful.

For example, I'm code a class C in namespace N. To code C, I might
need define some classes or functions, which are not used by other
classes other than C. I would not want to defines these classes or
functions in side C, because if I do it this way, I would not be able
to separate them from C into two different files, which would make it
harder to test and understand the code.

Since these classes or functions are for C, I'd like to keep them in
the same namespace as C.

Since these classes or functions are not for other classes other than
C, ideally, I would like to specify somehow in C++ that they are for C
only. For now, what I can possibly think of is to add 'private' in
'namespace' such that at least classes  outside N would not be able to
call these functions or classes.

Nothing prevents you from having code from one class reside in several
files. On a very few occasions (I remember only one, actually), I've
done exactly that.

/Peter

 

[Juha Nieminen]

Nothing prevents you from having code from one class reside in several
files. On a very few occasions (I remember only one, actually), I've
done exactly that.

The only problem is that the declaration of the class must contain
*everything* that belongs to that class declared in one single place,
while a namespace doesn't have that restriction.

 

[James Kanze]

I'd think a private in namespace might be useful.

You'll have to show what it might do that would be useful. It
certainly doesn't prevent anyone else from accessing it.

For example, I'm code a class C in namespace N. To code C, I
might need define some classes or functions, which are not
used by other classes other than C. I would not want to
defines these classes or functions in side C, because if I do
it this way, I would not be able to separate them from C into
two different files, which would make it harder to test and
understand the code.

I'm not following you. Typically, if you're writing library
code for concrete classes (no virtual functions), you'll have
each function in a separate file anyway.

Since these classes or functions are for C, I'd like to keep
them in the same namespace as C.

So put them in the same namespace as C. If they're not for
public consumation, I'll typically put them in a special
namespace, however, with a name indicating that they aren't for
public consumation.

Since these classes or functions are not for other classes
other than C, ideally, I would like to specify somehow in C++
that they are for C only. For now, what I can possibly think
of is to add 'private' in 'namespace' such that at least
classes outside N would not be able to call these functions
or classes.

Except that they would be able to. Given that namespaces are
open, making something private in a namespace would change
absolutely nothing.

 

[James Kanze]

The only problem is that the declaration of the class must
contain *everything* that belongs to that class declared in
one single place, while a namespace doesn't have that
restriction.

Which brings us back where we started: that's why private makes
no sense for namespaces.

 

[Peng Yu]

You'll have to show what it might do that would be useful. It
certainly doesn't prevent anyone else from accessing it.


I'm not following you. Typically, if you're writing library
code for concrete classes (no virtual functions), you'll have
each function in a separate file anyway.

What I meant was that a walkaround is to put these functions and
classes inside the class C and make them private.
This way make these functions and classes inaccessible by others, but
it also make it difficult to test them because you can not access them
from outside the class C. Therefore, this is not an viable option to
restrict the access of these class and functions. That is why I raised
the question whether there could be a 'private' keyword in
'namespace'.

So put them in the same namespace as C. If they're not for
public consumation, I'll typically put them in a special
namespace, however, with a name indicating that they aren't for
public consumation.

Your approach would work, but it is not convenient. Suppose you
construct a namespace N_private for the functions and classes that are
not for public access. To access a function or class in N_private from
N, you have to use the qualifier N_private::.

Adding 'private' in 'namespace' would make refactoring easier. Before
you do code refactoring, you may not know what code should be private.
Therefore, you tend to put all of them in the same namespace N. After
refactoring, you may find some classes or functions can be made
'private'. When there is no such keyword 'private', you need to cut
all the classes and functions that you want to make private and paste
them to the namespace N_private. You then have to prepend all the
references of these functions and classes in N with 'N_private::'. But
if you have such keyword 'private', it would be much easier, you just
need to add 'private' to the declaration of the function and classes.

Your approach is also not safe. You can not prevent anybody from
accessing functions or classes in N_private delibrately.

 

[tony_in_da_uk]

What I meant was that a walkaround is to put these functions and
classes inside the class C and make them private.
This way make these functions and classes inaccessible by others, but
it also make it difficult to test them because you can not access them
from outside the class C. Therefore, this is not an viable option to
restrict the access of these class and functions. That is why I raised
the question whether there could be a 'private' keyword in
'namespace'.



Your approach would work, but it is not convenient. Suppose you
construct a namespace N_private for the functions and classes that are
not for public access. To access a function or class in N_private from
N, you have to use the qualifier N_private::.

Adding 'private' in 'namespace' would make refactoring easier. Before
you do code refactoring, you may not know what code should be private.
Therefore, you tend to put all of them in the same namespace N. After
refactoring, you may find some classes or functions can be made
'private'. When there is no such keyword 'private', you need to cut
all the classes and functions that you want to make private and paste
them to the namespace N_private. You then have to prepend all the
references of these functions and classes in N with 'N_private::'. But
if you have such keyword 'private', it would be much easier, you just
need to add 'private' to the declaration of the function and classes.

Your approach is also not safe. You can not prevent anybody from
accessing functions or classes in N_private delibrately.

The "using" keyword avoids the need for explicit N_private::
prefixes. Anyway, when the private functions are only needed by one
implementation file, they can be put in an anonymous namespace
therein. If they're needed in the header you're out of luck. If
they're needed by multiple implementation files, you do need to put
them in a shared file and should use namespace "N_private", but it
doesn't have to be included from the N.h header, so is less exposed to
clients. C++ is not designed to make such restrictions totally
binding: after all, client code can reinterpret cast and access memory
directly so it's a losing battle. All you can do is make it obvious
that the client is doing something unsupported. N_private or
N_implementation is a clear indication.

Tony

 

[James Kanze]

What I meant was that a walkaround is to put these functions
and classes inside the class C and make them private. This
way make these functions and classes inaccessible by others,
but it also make it difficult to test them because you can not
access them from outside the class C.

So which is it: should they be accessible from outside the class
C, or not?

Therefore, this is not an viable option to restrict the access
of these class and functions. That is why I raised the
question whether there could be a 'private' keyword in
'namespace'.

And as I have pointed out, even if you could declare something
"private" in a namespace, it wouldn't change anything.

Your approach would work, but it is not convenient. Suppose
you construct a namespace N_private for the functions and
classes that are not for public access. To access a function
or class in N_private from N, you have to use the qualifier
N_private::.

Or in your implementation code (but not in the header), "using
namespace N_private;".

From experience, I can assure you that it's not really a
problem. I have one case where the class in question is a
template, which means that its implementation code is also in a
header, so I can't use "using namespace". And even most of the
time when I can, I don't (or else just in one or two functions).

Adding 'private' in 'namespace' would make refactoring easier.

How? That's what you've failed to show. As far as I can see,
private in a namespace would be completely meaningless.

Before you do code refactoring, you may not know what code
should be private.

What kind of silliness is that? At any point in time, you do
know (or you should) what should be private, and what shouldn't
be. (Of course, that can change in time; you might find in time
that it is useful to make some private function public, even to
the extent of locking you into a specific implementation. While
not a question of private/public, per se, see the recent
evolution of std::string for a good example of this.)

At any rate, the *only* evolution along these lines I've ever
seen is from private to public, not the other way around.

Therefore, you tend to put all of them in
the same namespace N. After refactoring, you may find some
classes or functions can be made 'private'. When there is no
such keyword 'private', you need to cut all the classes and
functions that you want to make private and paste them to the
namespace N_private. You then have to prepend all the
references of these functions and classes in N with
'N_private::'. But if you have such keyword 'private', it
would be much easier, you just need to add 'private' to the
declaration of the function and classes.

You're avoiding the basic question: what does it mean to make
something private in a namespace. Nothing, as far as I can see.

And as I said, in a class, the evolution is in the opposite
sense: the public parts are your constraining contract, and you
start with them as small as possible, only opening things up
when experience shows that 1) the actual implementation works,
so you won't have to change it, and 2) some client code can
possibly take advantage of it.

Your approach is also not safe. You can not prevent anybody
from accessing functions or classes in N_private delibrately.

And? What does private in a namespace do that this doesn't?

 

[James Kanze]

On Jul 25, 7:23 am, Peng Yu <[email protected]> wrote:

[...]

The "using" keyword avoids the need for explicit N_private::
prefixes.

In my experience, the need for them isn't very bothersome
anyway. But unless you're dealing with a template class (whose
implementation must be in a header), "using namespace" is a
solution if it does become a bother.

Anyway, when the private functions are only needed
by one implementation file, they can be put in an anonymous
namespace therein. If they're needed in the header you're out
of luck. If they're needed by multiple implementation files,
you do need to put them in a shared file and should use
namespace "N_private", but it doesn't have to be included from
the N.h header, so is less exposed to clients.

In my own code, it's fairly standard practice in such cases to
define a .lhh file for this. Which isn't exported by my
makefiles (nor considered by Doxygen), so client code never sees
it.

 

[Joe Greer]

Adding 'private' in 'namespace' would make refactoring easier. Before
you do code refactoring, you may not know what code should be private.
Therefore, you tend to put all of them in the same namespace N. After
refactoring, you may find some classes or functions can be made
'private'. When there is no such keyword 'private', you need to cut
all the classes and functions that you want to make private and paste
them to the namespace N_private. You then have to prepend all the
references of these functions and classes in N with 'N_private::'. But
if you have such keyword 'private', it would be much easier, you just
need to add 'private' to the declaration of the function and classes.

Your approach is also not safe. You can not prevent anybody from
accessing functions or classes in N_private delibrately.

What it sounds like you really want is modules. Anything short of that
is going look like a hack. Adding private to namespace isn't
sufficient. A namespace is just a space for names, not a compilation
scope (like a class). One problem is that if I declared something as
private in a namespace, that would imply that I had access to that
anywhere I was in that namespace. This wouldn't be true in anything
close to the current c++ idea of namespace. For example:

t.cpp
=====

namespace blotto {

private:
int f() { return 5; }

public:

int fn() { return f(); } // ok
}


t1.cpp
======

namespace blotto {
public:

int f3() { return f(); } // Bzzzt no idea what f() is

}



namespaces just don't have the same requirements as classes in terms of
their definitions. You don't have to include a header to access them
currently. To make them work the way one would expect, you would have
to come close to turning them into classes, possibly without the ability
to instantiate them. In fact, you can actually use classes for this
today. All you really lose is the using namespace statement.

What it sounds like you really want (or maybe its just what I really
want and I am putting that on you) is the ability to expose a set of
functionality that is implemented by a possibly larger set of classes.
And you want to do it in a fairly straight forward way (rather than
nested classes etc). In other words, modules. They were working on
this for C++0x but time got away from them and they dropped it for now.
I sure hope it comes back at somepoint though.

joe

 

[Peng Yu]

(e-mail address removed):





What it sounds like you really want is modules. Anything short of that
is going look like a hack. Adding private to namespace isn't
sufficient. A namespace is just a space for names, not a compilation
scope (like a class). One problem is that if I declared something as
private in a namespace, that would imply that I had access to that
anywhere I was in that namespace. This wouldn't be true in anything
close to the current c++ idea of namespace. For example:

t.cpp
=====

namespace blotto {

private:
int f() { return 5; }

public:

int fn() { return f(); } // ok

}

t1.cpp
======

namespace blotto {
public:

int f3() { return f(); } // Bzzzt no idea what f() is

}

namespaces just don't have the same requirements as classes in terms of
their definitions. You don't have to include a header to access them
currently. To make them work the way one would expect, you would have
to come close to turning them into classes, possibly without the ability
to instantiate them. In fact, you can actually use classes for this
today. All you really lose is the using namespace statement.

What it sounds like you really want (or maybe its just what I really
want and I am putting that on you) is the ability to expose a set of
functionality that is implemented by a possibly larger set of classes.
And you want to do it in a fairly straight forward way (rather than
nested classes etc). In other words, modules. They were working on
this for C++0x but time got away from them and they dropped it for now.
I sure hope it comes back at somepoint though.

joe

Hi Joe,

You completely understand me. I didn't know the appropriate word
should be 'module' before you told me.

What I need is to refactor my code a more or less mechanical way,
which can be automated easily or with minimalist manual editing. As
there is not such support for 'module', to mimic 'module', I'll have
to use a nested class, which makes the refactoring process much
harder. Therefore, a practical resolution is just not to refactor in
this aspect, right?

Thanks,
Peng

 

[Peng Yu]

The "using" keyword avoids the need for explicit N_private::
prefixes. Anyway, when the private functions are only needed by one
implementation file, they can be put in an anonymous namespace
therein. If they're needed in the header you're out of luck. If
they're needed by multiple implementation files, you do need to put
them in a shared file and should use namespace "N_private", but it
doesn't have to be included from the N.h header, so is less exposed to
clients. C++ is not designed to make such restrictions totally
binding: after all, client code can reinterpret cast and access memory
directly so it's a losing battle. All you can do is make it obvious
that the client is doing something unsupported. N_private or
N_implementation is a clear indication.

Tony

Hi Tony,

I'm using templates. So everything has to be in header files for now.

Thanks,
Peng

 

[Peng Yu]

So which is it: should they be accessible from outside the class
C, or not?


And as I have pointed out, even if you could declare something
"private" in a namespace, it wouldn't change anything.


Or in your implementation code (but not in the header), "using
namespace N_private;".

From experience, I can assure you that it's not really a
problem. I have one case where the class in question is a
template, which means that its implementation code is also in a
header, so I can't use "using namespace". And even most of the
time when I can, I don't (or else just in one or two functions).

Unfortunately, I'm using templates.

How? That's what you've failed to show. As far as I can see,
private in a namespace would be completely meaningless.


What kind of silliness is that? At any point in time, you do
know (or you should) what should be private, and what shouldn't
be. (Of course, that can change in time; you might find in time
that it is useful to make some private function public, even to
the extent of locking you into a specific implementation. While
not a question of private/public, per se, see the recent
evolution of std::string for a good example of this.)

At any rate, the *only* evolution along these lines I've ever
seen is from private to public, not the other way around.

In the post by Joe, he mentioned 'module', which is what I really
meant (I didn't know the appropriate word should be 'module', before
Joe told me).

 

[James Kanze]

In the post by Joe, he mentioned 'module', which is what I
really meant (I didn't know the appropriate word should be
'module', before Joe told me).

Modules are something very different; they actually do
something. I'm not up to date with the actual proposal in C++,
but presumably, once you've delivered a compiled module
interface file, the client code cannot add to the module. In
other words, modules are closed, like classes (except that they
are closed later in the development process---a class is closed
as soon as you write the closing brace).

Not that that affects my comment: you never evolve from public
to private (which would break the interface), but from private
to public.

 

[Joe Greer]

Hi Joe,

You completely understand me. I didn't know the appropriate word
should be 'module' before you told me.

What I need is to refactor my code a more or less mechanical way,
which can be automated easily or with minimalist manual editing. As
there is not such support for 'module', to mimic 'module', I'll have
to use a nested class, which makes the refactoring process much
harder. Therefore, a practical resolution is just not to refactor in
this aspect, right?

Yes, this would be correct. There really isn't a mechanical way to get the
protections you desire. There are, of course, ways to specify your
interfaces such that getting access to classes outside the way they are
supposed to be used is obviously wrong. This wouldn't fit under the
category of 'mechanical with minimal manual intervention' though. I think
your best bet is to add some comments to classes that shouldn't be used by
end users. Most end users aren't really out to hurt themselves.

joe