By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,130 Members | 1,359 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,130 IT Pros & Developers. It's quick & easy.

Static const variables within a namespace

P: n/a
Hi,

I'm trying to figure out if what I'm doing makes any sense. I created
a namespace that contains some functions as well as some constants.
Because these variables are constant, I have no need for there to be
more than one copy of them. Does it make sense to make these
variables static const, or do I just make them const? If this were a
class instead of a namespace, I would obviously want to make the
variables static, but this kind of reasoning doesn't seem to apply to
namespaces.

Thanks.
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
* Sehcra:

I'm trying to figure out if what I'm doing makes any sense. I created
a namespace that contains some functions as well as some constants.
Because these variables are constant, I have no need for there to be
more than one copy of them. Does it make sense to make these
variables static const, or do I just make them const?


At namespace scope a constant already has internal linkage by default, so
adding 'static' is only adding a deprecated feature that does nothing.

And if these definitions are in a header file, the result is any way the
opposite of the stated goal (to have only one copy of each).

You could add 'extern' to make the linkage external, if what you want is a
single copy of each constant in the whole program. Then you have only the
declarations in your header file, and definitions in an implementation file.
Or to avoid an implementation file you could define inline functions.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #2

P: n/a
Sehcra wrote:
Hi,

I'm trying to figure out if what I'm doing makes any sense. I created
a namespace that contains some functions as well as some constants.
Because these variables are constant, I have no need for there to be
more than one copy of them. Does it make sense to make these
variables static const, or do I just make them const? If this were a
class instead of a namespace, I would obviously want to make the
variables static, but this kind of reasoning doesn't seem to apply to
namespaces.

Thanks.

I think basically it doesn't make much sense to qualify an extra static
on to a constant, even in a class. A constant is just a constant, which
has nothing to do with static or "dynamic" (if it ever existed).
Actually, from some sort of perspective, you can think of a constant as
a static.

The use of "static" is generally not recommended unless inside functions
(statically allocated) or classes (part of the classes, rather than each
object).

Thanks.
Jul 23 '05 #3

P: n/a

Sehcra wrote:
Hi,

I'm trying to figure out if what I'm doing makes any sense. I created
a namespace that contains some functions as well as some constants.
Because these variables are constant, I have no need for there to be
more than one copy of them. Does it make sense to make these
variables static const, or do I just make them const? If this were a
class instead of a namespace, I would obviously want to make the
variables static, but this kind of reasoning doesn't seem to apply to
namespaces.

Thanks.


I wouldn't worry too much about declared constants. Unless the program
takes the address, or passes by reference, the constant, it's unlikely
that the compiler is even allocating even one instance of the constant,
let alone more than one.

Think of a const variable declaration with a constant expression as its
initializer, such as:

const int kOneDozen = 12;

as a more modern, type-safe replacement for the C practice of using
#define to create a constant value.

Greg

Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.