question about constants in C++

[john smith]

I have a question about the best way to use constants in C++. There seem to
be variations in the way that they are used, and I am confused as to what I
should be using. Basically since the constant is used in only one class,
should I try to scope it to just that class? to the file?
what are the thoughts out there.

1.)

I have seen people declare in their .h file

static const int myVariable;

And then in their .cpp put the definition.

myVariable = 10;

2.) Is it appropriate if the variable is only to be used in a class to put
that definition in the class so as to scope it to that class only?
umm, but then should it be private with an accessor?

So for example,

class MyClass {

public:
static const int myVariable = 10;

private:

}

3.)

Is it best to put it in a blank namespace in the .cpp file to keep the scope
to that file only?

So for example,

namespace {

static const int myVariable = 10;

}

I appreciate comments on this matter.
thanks for your help.

[Jonathan Mcdougall]

john smith wrote:

I have a question about the best way to use constants in C++. There seem to
be variations in the way that they are used, and I am confused as to what I
should be using. Basically since the constant is used in only one class,
should I try to scope it to just that class? to the file?
what are the thoughts out there.

If a constant is part of the class :

1. if the constant will be the same for all objects of that class (PI
for a class Math for example), make it a static constant member.

// my_math.h
class Math
{
private:
const float PI;
};

// my_math.cpp
float Math::PI = 3.1416;

Whether the constant is public or not depends on your design.

2. if the constant will change depending on the instances, make it a
constant member :

// car.h
class Car
{
private:
const int max_speed;

public:
Car(int ms);
};

// car.cpp
Car::Car(int ms)
: max_speed(ms)
{
}

If the constant is not part of a class, make it part of a namespace if
possible to avoid name clashes.

In general, always try to keep scopes as small as possible. For
example, it is possible for the constant Math::PI to be declared at file
scope, but it is a better design to make it part of the class it is
meant to be used with.
Jonathan

[Matthias Käppler]

john smith wrote:

class MyClass {

public:
static const int myVariable = 10;

private:

}

AFAIK this is not supported by all compilers, in fact initializing an object
inside the class body.

[Method Man]

"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:uF*********************@wagner.videotron.net. ..

john smith wrote:

I have a question about the best way to use constants in C++. There seem to be variations in the way that they are used, and I am confused as to what I should be using. Basically since the constant is used in only one class, should I try to scope it to just that class? to the file?
what are the thoughts out there.

If a constant is part of the class :

1. if the constant will be the same for all objects of that class (PI
for a class Math for example), make it a static constant member.

// my_math.h
class Math
{
private:
const float PI;
};

[snip]

I assume you meant "static const float PI;"?

[Rob Williscroft]

Matthias Käppler wrote in news:co*************@news.t-online.com in
comp.lang.c++:

john smith wrote:

class MyClass {

public:
static const int myVariable = 10;

private:

}

AFAIK this is not supported by all compilers, in fact initializing an
object inside the class body.

Initializing a static intergral constant member (such as the above)
in the body of its class is supported by *all* Standard conforming
C++ compilers.

If you have a "c++" compiler that doesn't allow this:

- It was probably writen prior to the first C++ Standard (1998).
- Get a better (newer) compiler.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Matthias Käppler]

Rob Williscroft wrote:

Initializing a static intergral constant member (such as the above)
in the body of its class is supported by *all* Standard conforming
C++ compilers.

If you have a "c++" compiler that doesn't allow this:

- It was probably writen prior to the first C++ Standard (1998).
- Get a better (newer) compiler.

Rob.

From Bjarne Stroustrup's C++ Technical FAQ:

"I tend to use the "enum trick" because it's portable and doesn't tempt me
to use non-standard extensions of the in-class initialization syntax."

Sounds pretty clear to me.

Regards,
Matthias

[Matthias Käppler]

Rob Williscroft wrote:

Matthias Käppler wrote in news:co*************@news.t-online.com in
comp.lang.c++:

john smith wrote:

class MyClass {

public:
static const int myVariable = 10;

private:

}

It's also problematic because it only works with static constant integers.
For e.g. a float you'd have to use the classic syntax.

[Matthias Käppler]

Matthias Käppler wrote:

"I tend to use the "enum trick" because it's portable and doesn't tempt me
to use non-standard extensions of the in-class initialization syntax."

Sounds pretty clear to me.

Regards,
Matthias

I think I misinterpreted the sentence. What he probably meant was that
non-standard extensions exist, which may lead to many people using them
(which is generally a bad thing).

So don't mind my last post, it was incorrect.

Regards,
Matthias

[Victor Bazarov]

"Rob Williscroft" <rt*@freenet.co.uk> wrote...

[..]
Initializing a static intergral constant member (such as the above)
in the body of its class is supported by *all* Standard conforming
C++ compilers.
Oh, yeah. Just like all other things the Standard prescribes.
If you have a "c++" compiler that doesn't allow this:

- It was probably writen prior to the first C++ Standard (1998).
- Get a better (newer) compiler.

Such statements are not constructive. (a) There is no such thing in the
world as a "Standard conforming C++ compiler". Every compiler has some
quirks (and bugs) in it and the Standard keeps changing. And (b) getting
"a better (newer) compiler" is not always possible in the current (or any
for that matter) market conditions; it doesn't just cost money (which is
often so), it costs time, it costs customers who don't want to change.

V