extern const variable in case label

[Christian Meier]

Hello NG

I have the following code:
file1.h:

static const int iValue = 5;

<EOF>
file2.cpp

#include <iostream>
#include "file1.h"

int main(int args, char* argv[])
{
switch(args) {
case iValue:
std::cout << "Hello\n";
}
}

<EOF>

This works fine as the value of the constant "iValue" is known when
compiling the main()-function in file2.cpp.
I have some more cpp-files which include file1.h. Therefore I have a copy of
"iValue" in each translation unit as it has internal linkage. In the
executable which is made with these object files (translation units) I have
several copies of that variable; all having the same value.

Now, I would like to change the linkage of "iValue" to extern so that there
is only one symbol for this constant in my executable.
When I change the keyword "static" to "extern" I have the problem that the
symbol is more than once defined in my executable.
When I only declare the variable "iValue" in file1.h with external linkage
("extern const int iValue;") and define it in a new file called file1.cpp
("extern const iValue = 5;"), then I have no problem with multiple
definitions but I have a new problem in my function main() because the value
of "iValue" is not known when compiling file2.cpp.

Do you have any suggestions how I can compile all my code without having
more than one symbol for "iValue" in my program? Or is it not possible what
I am trying to reach?
Thanks for all your answers in advance,
Chris

[Christian Meier]

IIRC, just

const int iValue = 5;
no 'static', no 'extern'

IIRC, constants in the file scope have internal linkage (in C++).

[James Kanze]

On Oct 3, 7:49 am, "Christian Meier" <chris@no_spam. comwrote:

"James Kanze" <james.ka...@gm ail.comwrote:

With my compiler and linker I have these symbols over 10
000 times in my executable and I was able to reduce the
program size a bit with changing these constants to extern
which are not used in case labels.

That is strange. I've yet to see a compiler where they'd
take any space at all, as long as their address wasn't
taken.

Eventually my assumption was wrong about the more than 10 000
symbols for this variable.... And I have not checked whether
the address is taken.

<Offtopic: UNIX Commands and Compiler version>

But the command "nm MyExecutable | grep iValue | wc -l" has
the output "11059" at this moment.
We use GCC 4.1.0...

</Offtopic>

Interesting. I would have thought 0 occurances (or at most,
only for those where the address was being taken). It's
possible that in debug mode, g++ would generate them, since you
could presumable modify the value with a debugger, but a quick
check with a single module on my system (g++ 4.1.0 under Solaris
and Linux) didn't reveal them. Even in debug mode: "nm a.out |
grep staticConst" (where the actual variable was named
staticConst) didn't have any output. Sun CC did generate the
object in debug mode (as a global, no less, but with a funny
prefix added to the name, presumably to make it distinct), but
not when optimizing was turned on.

I'm curious. If you compile the following program:

static int const staticConst = 42 ;

int
main()
{
return staticConst ;
}

then do "nm a.out | grep staticConst", what do you get (with and
without optimizing)?

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 3, 4:56 am, Barry <dhb2...@gmail. comwrote:

[...]

const int iValue = 5;

no 'static', no 'extern'

Both:
int const iValue = 5 ;
and
static int const iValue = 5 ;
mean exactly the same thing to the compiler. The choice of
which one to use is largely an issue of style; some people
prefer making the internal linkage explicit.

This is also one point where C and C++ are not compatible. If
the code is to be used in a header used in both languages, then
the static is necessary.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Christian Meier]

"James Kanze" <ja*********@gm ail.comwrote:

On Oct 3, 7:49 am, "Christian Meier" <chris@no_spam. comwrote:

"James Kanze" <james.ka...@gm ail.comwrote:

With my compiler and linker I have these symbols over 10
000 times in my executable and I was able to reduce the
program size a bit with changing these constants to extern
which are not used in case labels.
That is strange. I've yet to see a compiler where they'd
take any space at all, as long as their address wasn't
taken.

Eventually my assumption was wrong about the more than 10 000
symbols for this variable.... And I have not checked whether
the address is taken.

<Offtopic: UNIX Commands and Compiler version>

But the command "nm MyExecutable | grep iValue | wc -l" has
the output "11059" at this moment.
We use GCC 4.1.0...

</Offtopic>

Interesting. I would have thought 0 occurances (or at most,
only for those where the address was being taken).

I don't know in which cases the address is needed. I suppose there are many
other situations than "&iValue".
What about passing it to a function which takes a "const int&" as parameter?
If references are implemented as pointers than the address is needed for
this.
Using this variable in such a way is not unusual in our project. Could this
be the reason for all (or at least almost) the symbols in my executable?

It's possible that in debug mode, g++ would generate them, since you
could presumable modify the value with a debugger, but a quick
check with a single module on my system (g++ 4.1.0 under Solaris
and Linux) didn't reveal them. Even in debug mode: "nm a.out |
grep staticConst" (where the actual variable was named
staticConst) didn't have any output. Sun CC did generate the
object in debug mode (as a global, no less, but with a funny
prefix added to the name, presumably to make it distinct), but
not when optimizing was turned on.

I'm curious. If you compile the following program:

static int const staticConst = 42 ;

int
main()
{
return staticConst ;
}

then do "nm a.out | grep staticConst", what do you get (with and
without optimizing)?

I don't get any output for this.

But for an extended version of your code, I got an indication:

$ cat main.cpp
#include <iostream>

static int const staticConst = 42;

void func(const int& ri)
{
std::cout << ri << '\n';
}

int main()
{
func(staticCons t);
return staticConst ;
}
$ g++ -o main main.cpp
$ nm main | grep staticConst
000000000040093 8 r staticConst
$ g++ -O3 -o main main.cpp
$ nm main | grep staticConst
$

Compiling this code without an explicit optimization level results in having
1 symbol staticConst. However, we are compiling everything with -O3.

[Joe Greer]

"Christian Meier" <chris@no_spam. comwrote in
news:bb******** *************** ***@news.hispee d.ch:

>
But for an extended version of your code, I got an indication:

$ cat main.cpp
#include <iostream>

static int const staticConst = 42;

void func(const int& ri)
{
std::cout << ri << '\n';
}

int main()
{
func(staticCons t);
return staticConst ;
}
$ g++ -o main main.cpp
$ nm main | grep staticConst
000000000040093 8 r staticConst
$ g++ -O3 -o main main.cpp
$ nm main | grep staticConst
$

Compiling this code without an explicit optimization level results in
having 1 symbol staticConst. However, we are compiling everything with
-O3.

In its simplest form, the reference takes the address of the variable and
thus you get a symbol. With the optimizer turned on, it probably inlines
the function and you no longer need the variable, thus you don't see it
with -O3.

joe

[thomas]

On Oct 2, 6:05*pm, "Christian Meier" <chris@no_spam. comwrote:

well. I think you should keep in mind that the case value can only be
constant integral values.

What do you exactly mean with this? Isn't "extern const int iValue" a
constant integral value?

I guess the compiler will complain because ("extern const int
iValue;") is not known until linking while you should specify its
value in compile time because the "case" statement needs it.

I think you can just declare "const int iValue = 5;" in file1.h, and
use the "#ifndef .. #define.. #endif" thing to avoid multiple
inclusion.

In other files where "iValue" is used, you can just include "file1.h"
and it should work.

[James Kanze]

On Oct 3, 1:33 pm, "Christian Meier" <chris@no_spam. comwrote:

Interesting. I would have thought 0 occurances (or at most,
only for those where the address was being taken).

I don't know in which cases the address is needed. I suppose
there are many other situations than "&iValue". What about
passing it to a function which takes a "const int&" as
parameter? If references are implemented as pointers than the
address is needed for this. Using this variable in such a way
is not unusual in our project. Could this be the reason for
all (or at least almost) the symbols in my executable?

Technically, the rule is that an instance of the variable is
needed if the variable is used in any context where there is not
an immediate lvalue to rvalue conversion. Practically, in the
case of const values, that means taking its address or using it
to initialize a reference. (I can't think of any other cases
which would be legal with a const variable, but I could have
forgotten some.)

A second rule sometimes comes into play: the "as if" rule.
Basically, given a legal program, the compiler can do anything
it wants, as long as the observable behavior of the program is
"as if" it followed the abstract semantics. Thus, if you pass
the value by reference to an inline function, the compiler is
likely able to optimize away the use of the reference, and not
generate the instance. The observable behavior of your code
would not change. I expect that most compilers do this as well,
if they actually inline the function.

And just curious, but why are you passing int's by const
references?

It's possible that in debug mode, g++ would generate them, since you
could presumable modify the value with a debugger, but a quick
check with a single module on my system (g++ 4.1.0 under Solaris
and Linux) didn't reveal them. Even in debug mode: "nm a.out |
grep staticConst" (where the actual variable was named
staticConst) didn't have any output. Sun CC did generate the
object in debug mode (as a global, no less, but with a funny
prefix added to the name, presumably to make it distinct), but
not when optimizing was turned on.

I'm curious. If you compile the following program:

static int const staticConst = 42 ;

int
main()
{
return staticConst ;
}

then do "nm a.out | grep staticConst", what do you get (with and
without optimizing)?

I don't get any output for this.

But for an extended version of your code, I got an indication:

$ cat main.cpp
#include <iostream>

static int const staticConst = 42;

void func(const int& ri)
{
std::cout << ri << '\n';
}

int main()
{
func(staticCons t);
return staticConst ;
}

$ g++ -o main main.cpp
$ nm main | grep staticConst
000000000040093 8 r staticConst
$ g++ -O3 -o main main.cpp
$ nm main | grep staticConst
$

Compiling this code without an explicit optimization level
results in having 1 symbol staticConst. However, we are
compiling everything with -O3.

That's what I explained above. When optimization is turned on,
g++ will inline simple functions anytime it sees the definition.
Even if the function is not declared inline. With the result
that it doesn't ever actually need the instance, and won't
generate it.

In most cases, about the only time you'll have references to a
const int is as a result of template instantiation (and even
then, one could argue that having things like
std::vector<>:: push_back take a T const&, rather than simply a
T, is poor design). Because g++ doesn't implement export, that
means that the implementation of the function will be visible.
And because the function has to be in a header file, it should
be small enough that g++ can inline it with -O3.

That's for the theory. In practice, implementations of things
like std::vector<>:: push_back often involve enough levels of
indirection that it's quite possible that g++ doesn't manage to
inline them completely, which could result in what you are
seeing. (The obvious answer then is to get a better compiler
and a better implementation of the library. Easier said than
done---all of the other implementations I know have the same
problems:-).)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Christian Meier]

"James Kanze" <ja*********@gm ail.comwrote:

On Oct 3, 1:33 pm, "Christian Meier" <chris@no_spam. comwrote:

Interesting. I would have thought 0 occurances (or at most,
only for those where the address was being taken).

I don't know in which cases the address is needed. I suppose
there are many other situations than "&iValue". What about
passing it to a function which takes a "const int&" as
parameter? If references are implemented as pointers than the
address is needed for this. Using this variable in such a way
is not unusual in our project. Could this be the reason for
all (or at least almost) the symbols in my executable?

Technically, the rule is that an instance of the variable is
needed if the variable is used in any context where there is not
an immediate lvalue to rvalue conversion. Practically, in the
case of const values, that means taking its address or using it
to initialize a reference. (I can't think of any other cases
which would be legal with a const variable, but I could have
forgotten some.)

A second rule sometimes comes into play: the "as if" rule.
Basically, given a legal program, the compiler can do anything
it wants, as long as the observable behavior of the program is
"as if" it followed the abstract semantics. Thus, if you pass
the value by reference to an inline function, the compiler is
likely able to optimize away the use of the reference, and not
generate the instance. The observable behavior of your code
would not change. I expect that most compilers do this as well,
if they actually inline the function.

Ok, thanks a lot! I think this is the explanation I was looking for.

And just curious, but why are you passing int's by const
references?

I can't tell you for sure but I think the people in this company do it
because it was in the coding guidelines some years ago. The rule was removed
in the meantime but many people still write it this way...

It's possible that in debug mode, g++ would generate them, since you
could presumable modify the value with a debugger, but a quick
check with a single module on my system (g++ 4.1.0 under Solaris
and Linux) didn't reveal them. Even in debug mode: "nm a.out |
grep staticConst" (where the actual variable was named
staticConst) didn't have any output. Sun CC did generate the
object in debug mode (as a global, no less, but with a funny
prefix added to the name, presumably to make it distinct), but
not when optimizing was turned on.

I'm curious. If you compile the following program:

static int const staticConst = 42 ;

int
main()
{
return staticConst ;
}

then do "nm a.out | grep staticConst", what do you get (with and
without optimizing)?

I don't get any output for this.

But for an extended version of your code, I got an indication:

$ cat main.cpp
#include <iostream>

static int const staticConst = 42;

void func(const int& ri)
{
std::cout << ri << '\n';
}

int main()
{
func(staticCons t);
return staticConst ;
}

$ g++ -o main main.cpp
$ nm main | grep staticConst
000000000040093 8 r staticConst
$ g++ -O3 -o main main.cpp
$ nm main | grep staticConst
$

Compiling this code without an explicit optimization level
results in having 1 symbol staticConst. However, we are
compiling everything with -O3.

That's what I explained above. When optimization is turned on,
g++ will inline simple functions anytime it sees the definition.
Even if the function is not declared inline. With the result
that it doesn't ever actually need the instance, and won't
generate it.

In most cases, about the only time you'll have references to a
const int is as a result of template instantiation (and even
then, one could argue that having things like
std::vector<>:: push_back take a T const&, rather than simply a
T, is poor design).

Why is this said to be a poor design? Do you have a link to a document or a
c++-group discussion?

[James Kanze]

On Oct 6, 8:28 am, "Christian Meier" <chris@no_spam. comwrote:

[...]

In most cases, about the only time you'll have references to
a const int is as a result of template instantiation (and
even then, one could argue that having things like
std::vector<>:: push_back take a T const&, rather than simply
a T, is poor design).

Why is this said to be a poor design? Do you have a link to a
document or a c++-group discussion?

I didn't say that it was poor design, or that it was generally
considered poor design (although IMHO... I'm not sure), but that
one could make an argument that it was poor design. Basically,
it's an optimization; what std::vector<>:: push_back needs is an
object. It's passed as a const reference, rather than by value,
for purely optimization reasons. One could argue that 1) this
is premature optimization, and 2) in the case of things like
std::vector<int or std::vector<dou ble>, it's pessimization, and
that statistically, these are probably the most likely cases
when performance is an issue.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Hendrik Schober]

James Kanze wrote:

[...] Basically,
it's an optimization; what std::vector<>:: push_back needs is an
object. It's passed as a const reference, rather than by value,
for purely optimization reasons. One could argue that 1) this
is premature optimization, and 2) in the case of things like
std::vector<int or std::vector<dou ble>, it's pessimization, and
that statistically, these are probably the most likely cases
when performance is an issue.

Since this question came up just a few hours ago:
On my platform (Win32) 'double' is bigger than a 'double&'.
We were discussing whether having to pass less bits to a
function would outweigh the additional indirection. So far
I had assumed that, in general, passing built-in types by
value is the best bet.
What's the foundation of your argument above?

Schobi