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_n ame[] = "ChocolateChees e";

B) const char* const g_application_n ame = "ChocolateChees e";


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_na me" 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]

Re: Global const strings


Maybe even:

char const (&g_application _name)[sizeof("Chocola teCheese")] =
"ChocolateChees e";


-JKop

[John Harrison]

Re: Global const strings


"JKop" <NULL@NULL.NULL > wrote in message
news:Aeqfd.4004 7$Z14.14464@new s.indigo.ie...[color=blue]
>
> Let's say you have a global const variable for the name of your[/color]
application.[color=blue]
>
> Which do you think is preferrable?:
>
> A) char const g_application_n ame[] = "ChocolateChees e";
>
> B) const char* const g_application_n ame = "ChocolateChees e";
>
>
> 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_na me" array
> from somewhere else in memory.[/color]

No

char const g_application_n ame[] = "ChocolateChees e";

is an abbreviation for

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

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

[color=blue]
>
> 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?[/color]
I[color=blue]
> know there's some bullshit along the lines that they can't be accessed[/color]
from[color=blue]
> within another translation unit unless "extern" is applied to the
> *definition*. How exactly does that work?
>[/color]

extern char const g_application_n ame[] = "ChocolateChees e";

john

[Cy Edmunds]

Re: Global const strings

"John Harrison" <john_andronicu s@hotmail.com> wrote in message
news:2u6qkfF26i 6heU1@uni-berlin.de...[color=blue]
>
> "JKop" <NULL@NULL.NULL > wrote in message
> news:Aeqfd.4004 7$Z14.14464@new s.indigo.ie...[color=green]
>>
>> Let's say you have a global const variable for the name of your[/color]
> application.[color=green]
>>
>> Which do you think is preferrable?:
>>
>> A) char const g_application_n ame[] = "ChocolateChees e";
>>
>> B) const char* const g_application_n ame = "ChocolateChees e";
>>
>>
>> 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_na me"
>> array
>> from somewhere else in memory.[/color]
>
> No
>
> char const g_application_n ame[] = "ChocolateChees e";
>
> is an abbreviation for
>
> char const g_application_n ame[] = { 'C', 'h', 'o', ...[/color]

More precisely, {'C', 'h', 'o', ... , 'e', '\0'}
[color=blue]
>
> There is only one copy of the string, so I always go for A.[/color]

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.
[color=blue]
>
>[color=green]
>>
>> 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?[/color]
> I[color=green]
>> know there's some bullshit along the lines that they can't be accessed[/color]
> from[color=green]
>> within another translation unit unless "extern" is applied to the
>> *definition*. How exactly does that work?
>>[/color]
>
> extern char const g_application_n ame[] = "ChocolateChees e";[/color]

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
[color=blue]
>
> john
>
>[/color]

[Ioannis Vranos]

Re: Global const strings

JKop wrote:
[color=blue]
> Let's say you have a global const variable for the name of your application.[/color]


Lets avoid the global topic now. :-)


[color=blue]
> Which do you think is preferrable?:
>
> A) char const g_application_n ame[] = "ChocolateChees e";[/color]


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


[color=blue]
> B) const char* const g_application_n ame = "ChocolateChees e";[/color]




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_n ame = "ChocolateChees e";


would suffice.



[color=blue]
>
>
> 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_na me" 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?[/color]


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

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Re: Global const strings

Ioannis Vranos wrote:
[color=blue]
> 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.[/color]


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."



--
Ioannis Vranos

http://www23.brinkster.com/noicys

[JKop]

Re: Global const strings

[color=blue]
> "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."[/color]


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]

Re: Global const strings

[color=blue]
> The second occupies less space.[/color]

You're saying that


const char* const g_application_n ame = "ChocolateChees e";


occupies less space than:


char const g_application_n ame[] = "ChocolateChees e";


Can you please elaborate on that?


-JKop

[Ioannis Vranos]

Re: Global const strings

JKop wrote:
[color=blue]
> 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.[/color]


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



--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Re: Global const strings

JKop wrote:
[color=blue][color=green]
>>The second occupies less space.[/color]
>
>
> You're saying that
>
>
> const char* const g_application_n ame = "ChocolateChees e";
>
>
> occupies less space than:
>
>
> char const g_application_n ame[] = "ChocolateChees e";
>
>
> Can you please elaborate on that?[/color]


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.



--
Ioannis Vranos

http://www23.brinkster.com/noicys