Const VS Defines
-
I was wondering what is the best way to set constanta in C/C++. Using a header file with all constants set as #defines? Kind of like:
#define pi (3.1416f)
#define gravity_m_div_sqrt_secs (9.81f)Or, set as static members of a class?
// Common.h
#ifndef __COMMON__
#define __COMMON__class Common{
public:
static float k_pi;
static float k_gravity_m_div_sqrt_secs;};
// Common.cpp
#include "Common.h"float Common::k_pi = 3.1416f;
float Common::k_gravity_m_div_sqrt_secs = 9.81f;It think is better to set 'em as a class, because sometimes you need to access them in any part of the code. And if you modify any one of them, the compilation time will be faster. But then I think how much RAM will these constants will be use, so in that case #defines are useful. I really want to know your opinion.
I would go the second way, mostly for not polluting the global namespace. Also you should set the types to static const float, assuming they are not supposed to change during runtime. I like to name constants in all upper case, but that's just a personal preferrence.
The good thing about pessimism is, that you are always either right or pleasently surprised.
-
I was wondering what is the best way to set constanta in C/C++. Using a header file with all constants set as #defines? Kind of like:
#define pi (3.1416f)
#define gravity_m_div_sqrt_secs (9.81f)Or, set as static members of a class?
// Common.h
#ifndef __COMMON__
#define __COMMON__class Common{
public:
static float k_pi;
static float k_gravity_m_div_sqrt_secs;};
// Common.cpp
#include "Common.h"float Common::k_pi = 3.1416f;
float Common::k_gravity_m_div_sqrt_secs = 9.81f;It think is better to set 'em as a class, because sometimes you need to access them in any part of the code. And if you modify any one of them, the compilation time will be faster. But then I think how much RAM will these constants will be use, so in that case #defines are useful. I really want to know your opinion.
-
Enums aren't useful for anything but integer constants.
-
Enums aren't useful for anything but integer constants.
-
I was wondering what is the best way to set constanta in C/C++. Using a header file with all constants set as #defines? Kind of like:
#define pi (3.1416f)
#define gravity_m_div_sqrt_secs (9.81f)Or, set as static members of a class?
// Common.h
#ifndef __COMMON__
#define __COMMON__class Common{
public:
static float k_pi;
static float k_gravity_m_div_sqrt_secs;};
// Common.cpp
#include "Common.h"float Common::k_pi = 3.1416f;
float Common::k_gravity_m_div_sqrt_secs = 9.81f;It think is better to set 'em as a class, because sometimes you need to access them in any part of the code. And if you modify any one of them, the compilation time will be faster. But then I think how much RAM will these constants will be use, so in that case #defines are useful. I really want to know your opinion.
Don't use #define for constants. If you want to keep things tidy, use a dedicated namespace, and a separate definition.
// constants.h
namespace constants
{
extern const float pi;
}// constants.cpp
#include "constants.h"namespace constants
{
const float pi = 3.141593;
}// application.cpp
...
int i = 5;
float angle = constants::pi * i;
// the code below won't work if you use #define
int* pi = &i;
...This also demonstrates why using #defines will break your code
-
Don't use #define for constants. If you want to keep things tidy, use a dedicated namespace, and a separate definition.
// constants.h
namespace constants
{
extern const float pi;
}// constants.cpp
#include "constants.h"namespace constants
{
const float pi = 3.141593;
}// application.cpp
...
int i = 5;
float angle = constants::pi * i;
// the code below won't work if you use #define
int* pi = &i;
...This also demonstrates why using #defines will break your code
When using namespaces (in Visual Studio) you get the added benefit of IntelliSense helping you out. I personally think it is overkill to put the definition in a cpp file as long as we are talking about simple constants. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
-
When using namespaces (in Visual Studio) you get the added benefit of IntelliSense helping you out. I personally think it is overkill to put the definition in a cpp file as long as we are talking about simple constants. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
SoMad wrote:
I personally think it is overkill to put the definition in a cpp file as long as we are talking about simple constants.
I'd second that... plus if someone is tracking a value of a constant, it's getting hidden away a bit (unnecessarily) by putting it in a source file.
-
I was wondering what is the best way to set constanta in C/C++. Using a header file with all constants set as #defines? Kind of like:
#define pi (3.1416f)
#define gravity_m_div_sqrt_secs (9.81f)Or, set as static members of a class?
// Common.h
#ifndef __COMMON__
#define __COMMON__class Common{
public:
static float k_pi;
static float k_gravity_m_div_sqrt_secs;};
// Common.cpp
#include "Common.h"float Common::k_pi = 3.1416f;
float Common::k_gravity_m_div_sqrt_secs = 9.81f;It think is better to set 'em as a class, because sometimes you need to access them in any part of the code. And if you modify any one of them, the compilation time will be faster. But then I think how much RAM will these constants will be use, so in that case #defines are useful. I really want to know your opinion.
Although using the statics is a way to keep your namespace cleaner, the macros are used A LOT... and they allow your code to be compiled as C OR C++. If you use class/namespace enclosed statics you're pretty much C++ compliant only.
-
When using namespaces (in Visual Studio) you get the added benefit of IntelliSense helping you out. I personally think it is overkill to put the definition in a cpp file as long as we are talking about simple constants. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
The benefit of having the definition in a cpp file is more apparent when the constant isn't a universal physical/mathematical one, but one that could conceivably change during development. Should this happen, there's no need to recompile all files that refer to it, which would be required if the definition is in the header file.
-
Although using the statics is a way to keep your namespace cleaner, the macros are used A LOT... and they allow your code to be compiled as C OR C++. If you use class/namespace enclosed statics you're pretty much C++ compliant only.
In my experience, very few projects have a requirement that they be compilable as both C and C++. Many libraries must be accessible from both C and C++, but a well-designed C-style interface will take care of that. For example, instead of:
#define MAX_SIZE 42
write a function,
int GetMaxSize()
which returns the value of the constant from your library. This has the further advantage of decoupling the library from the constant - any changes to MAX_SIZE won't require the client's code to be recompiled (possibly relinked, if we are talking about a static library).
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
In my experience, very few projects have a requirement that they be compilable as both C and C++. Many libraries must be accessible from both C and C++, but a well-designed C-style interface will take care of that. For example, instead of:
#define MAX_SIZE 42
write a function,
int GetMaxSize()
which returns the value of the constant from your library. This has the further advantage of decoupling the library from the constant - any changes to MAX_SIZE won't require the client's code to be recompiled (possibly relinked, if we are talking about a static library).
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
Well in my experience, there's A LOT of code that exists from the C days, so you still see macros a lot. And yes, most people use C style interfaces for libraries. Important to note that the original question specified C AND C++. I was simply pointing out that namespace/class enclosed statics aren't C compliant.
Quote:
I was wondering what is the best way to set constanta in C/C++
-
Well in my experience, there's A LOT of code that exists from the C days, so you still see macros a lot. And yes, most people use C style interfaces for libraries. Important to note that the original question specified C AND C++. I was simply pointing out that namespace/class enclosed statics aren't C compliant.
Quote:
I was wondering what is the best way to set constanta in C/C++
Perhaps I expressed myself poorly. I was referring to the case where the library is written in C / C++ / <whatever>, but must be callable from a C-style interface (e.g. the MS-Windows SDK). I believe that it is poor practice to expose _#define_d constants in the library's header file, because it introduces tight coupling between the caller and the library - any change in the constant requires recompiling the client. Having said that, I recognize that standard C practice is to define such constants, so that code such as below may be written: header.h:
#define MAX_SIZE 42
...code.c:
#include "header.h"
void foo(void)
{
int array[MAX_SIZE];...
}C99 and later support variable-length arrays. As developers transition to compilers supporting this feature, I suspect that the need for such constants may decrease.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
Although using the statics is a way to keep your namespace cleaner, the macros are used A LOT... and they allow your code to be compiled as C OR C++. If you use class/namespace enclosed statics you're pretty much C++ compliant only.
You still could use a const struct in ANSI C like this:
const extern struct {
double pi;
int answer;
} constants = { 3.14, 42 };constis part of ANSI C, as are struct initializer lists. So no need to resort to#definesand cluttering the global namespace. Of course, you could also just define each individual constant asconst, or you could skip theconstand the initialization if you prefer initializing the values in a .c file.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Perhaps I expressed myself poorly. I was referring to the case where the library is written in C / C++ / <whatever>, but must be callable from a C-style interface (e.g. the MS-Windows SDK). I believe that it is poor practice to expose _#define_d constants in the library's header file, because it introduces tight coupling between the caller and the library - any change in the constant requires recompiling the client. Having said that, I recognize that standard C practice is to define such constants, so that code such as below may be written: header.h:
#define MAX_SIZE 42
...code.c:
#include "header.h"
void foo(void)
{
int array[MAX_SIZE];...
}C99 and later support variable-length arrays. As developers transition to compilers supporting this feature, I suspect that the need for such constants may decrease.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
You still can use the
constkeyword. In case of constants being used for array bounds, you could instead declare anenum(sinceconst ints in C cannot be used for array bounds, unfortunately):enum {
MAX_SIZE = 42
};
const struct {
double pi;
int size;
} constants = { 3.14, 42 };
double arr1[MAX_SIZE]; // ok in C and C++
double arr2[constants.size]; // ok in C++, error in CGOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
You still can use the
constkeyword. In case of constants being used for array bounds, you could instead declare anenum(sinceconst ints in C cannot be used for array bounds, unfortunately):enum {
MAX_SIZE = 42
};
const struct {
double pi;
int size;
} constants = { 3.14, 42 };
double arr1[MAX_SIZE]; // ok in C and C++
double arr2[constants.size]; // ok in C++, error in CGOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
1. Your solution, while removing the problems with #define, still has the problem of tight coupling of the caller's code with the library. 2. In C99 or later, variable-length arrays are perfectly legal, but IIRC - not as static variables.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
I was wondering what is the best way to set constanta in C/C++. Using a header file with all constants set as #defines? Kind of like:
#define pi (3.1416f)
#define gravity_m_div_sqrt_secs (9.81f)Or, set as static members of a class?
// Common.h
#ifndef __COMMON__
#define __COMMON__class Common{
public:
static float k_pi;
static float k_gravity_m_div_sqrt_secs;};
// Common.cpp
#include "Common.h"float Common::k_pi = 3.1416f;
float Common::k_gravity_m_div_sqrt_secs = 9.81f;It think is better to set 'em as a class, because sometimes you need to access them in any part of the code. And if you modify any one of them, the compilation time will be faster. But then I think how much RAM will these constants will be use, so in that case #defines are useful. I really want to know your opinion.
I usually use consts or better still enums. The main problem I came to find with defines is namespace pollution - in many places you'd have constants named MAX_FILENAME_LENGHT and it is possible, depending on the use you make of this constant, that they differ. Using a define you'd probably end up with a redefine or nasty bug somewhere, using constants and enums you can keep them enclosed in a class, which is often what is needed. Enums are still better as they build another inner namespace, further reducing namespace pollution. For the same reason I often enclose the data members that makes sense only when taken together into inner structs inside the definition of the classes, this way you have an easy way to pass an entire block of information between functions and can reuse common names (as Length used with different meanings in different places, avoiding C-like horrors like DataPadLenght, DataPayloadLenght, DataReservedAllocationLength, FileNameLenght...).
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
1. Your solution, while removing the problems with #define, still has the problem of tight coupling of the caller's code with the library. 2. In C99 or later, variable-length arrays are perfectly legal, but IIRC - not as static variables.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
1. you are free to move the initialization of the struct elsewhere within your library code. I just did it like this to have a compact example. (and I didn't want to bother finding out how and where to place qualifiers) 2. True, but that didn't help in the example code I gave. The compiler still issued an error (VS 2010, compiled "as C"). The reason I pointed out the alternative (defining an enum) is that sometimes you do want a symbol to be recognized and treated as constant (e. g. to prevent typos such as
if (MAX_SIZE=10)), but at the same time you want to use these same constants in situations that specifically require constants, such as in array definitions. C unfortunately doesn't allow you to use aconst intas array bounds, in spite of VLAs! But it does let you use enum values.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)