"const int" and "const char*" in header (.h) files

[C. J. Clegg]

A month or so ago I read a discussion about putting const ints in
header files, and how one shouldn't put things in header files that
allocate memory, etc. because they will generate multiple definition
errors if the header file is #include'd in more than one code file.

The answer was that constants have internal linkage unless declared
extern, so it's OK.

So, you can put something like...

const int abc = 123;

.... in a header file and be fine (in C++, not in C).

I have run into a related problem.

In one of my header files I have:

const int maxLen = 128;

const char* theMsg = "Hello, world";

This header file is #include'd in about eleventy-gazillion places
throughout the system.

When I compile, the compilerand linker is perfectly happy with the
const int, but generates a slew of "multiple definition" errors at
link time for the const char*.

What's the difference between const int and const char* that would
make one work and the other not?

 

[Ian Collins]

A month or so ago I read a discussion about putting const ints in
header files, and how one shouldn't put things in header files that
allocate memory, etc. because they will generate multiple definition
errors if the header file is #include'd in more than one code file.

The answer was that constants have internal linkage unless declared
extern, so it's OK.

Do they?

So, you can put something like...

const int abc = 123;

.... in a header file and be fine (in C++, not in C).

What happens if you take its address in more than one source file?

I have run into a related problem.

In one of my header files I have:

const int maxLen = 128;

const char* theMsg = "Hello, world";

This header file is #include'd in about eleventy-gazillion places
throughout the system.

When I compile, the compilerand linker is perfectly happy with the
const int, but generates a slew of "multiple definition" errors at
link time for the const char*.

What's the difference between const int and const char* that would
make one work and the other not?

My guess is that the const int does not require a memory location,
unless you take its address.

The const char* is a string literal that will be duplicated.

I always use extern for constant declarations, with the definition in a
appropriate source file.

 

[Daniel T.]

A month or so ago I read a discussion about putting const ints in
header files, and how one shouldn't put things in header files that
allocate memory, etc. because they will generate multiple definition
errors if the header file is #include'd in more than one code file.

The answer was that constants have internal linkage unless declared
extern, so it's OK.

So, you can put something like...

const int abc = 123;

... in a header file and be fine (in C++, not in C).

I have run into a related problem.

In one of my header files I have:

const int maxLen = 128;

const char* theMsg = "Hello, world";

Try this:

const char* const theMsg = "Hello, world";

See if that gets rid of the errors.

This header file is #include'd in about eleventy-gazillion places
throughout the system.

When I compile, the compilerand linker is perfectly happy with the
const int, but generates a slew of "multiple definition" errors at
link time for the const char*.

What's the difference between const int and const char* that would
make one work and the other not?

The difference is that "const int" is const, whereas "const char*" is
mutable (even if that to which it points is not.)

 

[red floyd]

Try this:

const char* const theMsg = "Hello, world";

See if that gets rid of the errors.

That should. In the OP's version, theMsg isn't a const, it just points
to const data, and therefore theMsg has external linkage.

In Daniel's version, in addition to pointing at const data, the pointer
itself is a const, and therefore should have internal linkage.

 

[C. J. Clegg]

Try this:

const char* const theMsg = "Hello, world";

See if that gets rid of the errors.

Yup, that did it, thanks!