Global const strings

[JKop]

Let's say you have a global const variable for the name of your application.

Which do you think is preferrable?:

A) char const g_application_name[] = "ChocolateCheese";

B) const char* const g_application_name = "ChocolateCheese";


A -> The only drawback I'm thinking of is that maybe the string will be in
memory twice, and that it would be copied into my "application_name" array
from somewhere else in memory.

B -> There's no worries about it being in memory twice, but still an extra
pointer may be allocated.


Whenever I make a global string like this, I always find myself pondering
for ~20 seconds over which I should go for, so I may aswell burry it once
and for all!


Also... can anyone summarize the rules for global const variables please? I
know there's some bullshit along the lines that they can't be accessed from
within another translation unit unless "extern" is applied to the
*definition*. How exactly does that work?

-JKop

 

[JKop]

Maybe even:

char const (&g_application_name)[sizeof("ChocolateCheese")] =
"ChocolateCheese";


-JKop

 

[John Harrison]

Let's say you have a global const variable for the name of your application.

Which do you think is preferrable?:

A) char const g_application_name[] = "ChocolateCheese";

B) const char* const g_application_name = "ChocolateCheese";


A -> The only drawback I'm thinking of is that maybe the string will be in
memory twice, and that it would be copied into my "application_name" array
from somewhere else in memory.

No

char const g_application_name[] = "ChocolateCheese";

is an abbreviation for

char const g_application_name[] = { 'C', 'h', 'o', ...

There is only one copy of the string, so I always go for A.

B -> There's no worries about it being in memory twice, but still an extra
pointer may be allocated.


Whenever I make a global string like this, I always find myself pondering
for ~20 seconds over which I should go for, so I may aswell burry it once
and for all!


Also... can anyone summarize the rules for global const variables please? I
know there's some bullshit along the lines that they can't be accessed from
within another translation unit unless "extern" is applied to the
*definition*. How exactly does that work?

extern char const g_application_name[] = "ChocolateCheese";

john

 

[Cy Edmunds]

Let's say you have a global const variable for the name of your application.

Which do you think is preferrable?:

A) char const g_application_name[] = "ChocolateCheese";

B) const char* const g_application_name = "ChocolateCheese";


A -> The only drawback I'm thinking of is that maybe the string will be
in
memory twice, and that it would be copied into my "application_name"
array
from somewhere else in memory.

No

char const g_application_name[] = "ChocolateCheese";

is an abbreviation for

char const g_application_name[] = { 'C', 'h', 'o', ...

More precisely, {'C', 'h', 'o', ... , 'e', '\0'}

There is only one copy of the string, so I always go for A.

I don't suppose it makes much difference, but I always go for B. The
functions in C and C++ which take C strings as arguments are generally
declared as const char *, so if you use the array notation you are always
depending on an array decaying to a pointer. Of course if you use a lot of
subscripting an array may be a better description, but I usually use pointer
arithmetic. I'll bet we both use std::string for almost all of our string
processing anyway.

B -> There's no worries about it being in memory twice, but still an
extra
pointer may be allocated.


Whenever I make a global string like this, I always find myself pondering
for ~20 seconds over which I should go for, so I may aswell burry it once
and for all!


Also... can anyone summarize the rules for global const variables please? I
know there's some bullshit along the lines that they can't be accessed from
within another translation unit unless "extern" is applied to the
*definition*. How exactly does that work?

extern char const g_application_name[] = "ChocolateCheese";

Right answer to the question or course, but it still looks like a hack to
me. I generally put my globals in an unnamed namespace and provide a
function for read access if necessary.

Yeah, I'm in the mood to split hairs tonight. doh

 

[Ioannis Vranos]

Let's say you have a global const variable for the name of your application.

Lets avoid the global topic now.

Which do you think is preferrable?:

A) char const g_application_name[] = "ChocolateCheese";

This creates an array on the stack of the needed size with those
characters including the terminating 0.

B) const char* const g_application_name = "ChocolateCheese";

This points to the string literal itself. The string literal in both
cases is stored in an implementation-defined storage area, in both cases.


The second occupies less space. However in most cases,


const string g_application_name = "ChocolateCheese";


would suffice.

A -> The only drawback I'm thinking of is that maybe the string will be in
memory twice, and that it would be copied into my "application_name" array
from somewhere else in memory.

B -> There's no worries about it being in memory twice, but still an extra
pointer may be allocated.


Whenever I make a global string like this, I always find myself pondering
for ~20 seconds over which I should go for, so I may aswell burry it once
and for all!


Also... can anyone summarize the rules for global const variables please? I
know there's some *pepper* along the lines that they can't be accessed from
within another translation unit unless "extern" is applied to the
*definition*. How exactly does that work?

Definitions of globals can be accessed from other translation unit,
unless they are defined as static (inherited from C) or in an anonymous
namespace (the C++ better way).


extern sometype someobj; is a declaration in a translation unit that
tells that this global is defined (and is accessible) in another
translation unit.

 

[Ioannis Vranos]

Definitions of globals can be accessed from other translation unit,
unless they are defined as static (inherited from C) or in an anonymous
namespace (the C++ better way).


extern sometype someobj; is a declaration in a translation unit that
tells that this global is defined (and is accessible) in another
translation unit.

I just realised that you had asked about const globals. Yes const
globals have local scope only (internal linkage).

Check the following from TC++PL on how you can make them with external
linkage:


"Global variables that are local to a single compilation unit are a
common source of confusion and are best avoided. To ensure consistency,
you should usually place global consts and inlines in header files only
(9.2.1).

A const can be given external linkage by an explicit declaration:


// file1.c:

extern const int a = 77;

// file2.c:

extern const int a;

void g()
{
cout << a << ´\n´;
}

Here, g() will print 77."

 

[JKop]

"Global variables that are local to a single compilation unit are a
common source of confusion and are best avoided. To ensure consistency,
you should usually place global consts and inlines in header files only
(9.2.1).

A const can be given external linkage by an explicit declaration:


// file1.c:

extern const int a = 77;

// file2.c:

extern const int a;

void g()
{
cout << a << ´\n´;
}

Here, g() will print 77."

Am I the only one that sees the blatant contradiction?

First it says "place global consts in header files only" (I'm assuming
"definition" is meant by this), then it gives an example in which the global
const is defined in a source file.


-JKop

 

[JKop]

The second occupies less space.

You're saying that


const char* const g_application_name = "ChocolateCheese";


occupies less space than:


char const g_application_name[] = "ChocolateCheese";


Can you please elaborate on that?


-JKop

 

[Ioannis Vranos]

Am I the only one that sees the blatant contradiction?

First it says "place global consts in header files only" (I'm assuming
"definition" is meant by this), then it gives an example in which the global
const is defined in a source file.

No, the book being complete, suggests placing them in the header file
and then provides the alternate solution.

 

[Ioannis Vranos]

The second occupies less space.

You're saying that


const char* const g_application_name = "ChocolateCheese";


occupies less space than:


char const g_application_name[] = "ChocolateCheese";


Can you please elaborate on that?

The string literal is stored in both cases in an implementation reserved
space (that is not in the stack or in the free store), in addition to
the array.

Of course a compiler may not store it in the second case.