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

[thomas]

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

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

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

[Christian Meier]

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?

[Martin Eisenberg]

Christian Meier wrote:

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?

How about this?

enum { iValue = int(5) };
Martin

--
Quidquid latine scriptum est, altum videtur.

[Christian Meier]

"Martin Eisenberg" <ma**************@udo.eduwrote:

Christian Meier wrote:

>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?

How about this?

enum { iValue = int(5) };

Thanks for your answer!
Ok, you're right, that could be a solution for "int".
To tell a bit more of the truth, I have these constants for quite all
built-in types (double, long int, short...) and IIRC enum values must have
type int.

[James Kanze]

On Oct 2, 11:23 am, "Christian Meier" <chris@no_spam.comwrote:

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.

Maybe. Maybe not.

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?

Do you have some valid reason for wanting iValue to have the
same address in every translation unit? It seems strange to me
to give an int identity, especially if you're not going to
change it. And otherwise, what's the problem with what you have
written initially?

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

[Christian Meier]

"James Kanze" <ja*********@gmail.comwrote:

Do you have some valid reason for wanting iValue to have the
same address in every translation unit?

No...

It seems strange to me to give an int identity, especially if you're not
going to
change it.

What else would you use for a global integer constant? Would you use a
#define?

And otherwise, what's the problem with what you have written initially?

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.

[James Kanze]

On Oct 2, 5:33 pm, "Christian Meier" <chris@no_spam.comwrote:

"James Kanze" <[e-mail]:

Do you have some valid reason for wanting iValue to have the
same address in every translation unit?

No...

It seems strange to me to give an int identity, especially
if you're not going to change it.

What else would you use for a global integer constant? Would you use a
#define?

No. Just a static int const, like you did originally.

And otherwise, what's the problem with what you have written
initially?

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.

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

[Barry]

On 10ÔÂ2ÈÕ, ÏÂÎç5ʱ23·Ö, "Christian Meier" <chris@no_spam.comwrote:

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 copyof
"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?

IIRC, just

const int iValue = 5;

no 'static', no 'extern'

--
Best Regards
Barry

[Christian Meier]

"James Kanze" <ja*********@gmail.comwrote:

It seems strange to me to give an int identity, especially
if you're not going to change it.

What else would you use for a global integer constant? Would you use a
#define?

No. Just a static int const, like you did originally.

Ok thanks. Probably I will not change the code so it remains a static const
int.

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>

[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" <[e-mail]:

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 3, 4:56 am, Barry <[e-mail]:

[...]

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Christian Meier]

"James Kanze" <ja*********@gmail.comwrote:

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

"James Kanze" <[e-mail]:

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(staticConst);
return staticConst ;
}
$ g++ -o main main.cpp
$ nm main | grep staticConst
0000000000400938 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.hispeed.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(staticConst);
return staticConst ;
}
$ g++ -o main main.cpp
$ nm main | grep staticConst
0000000000400938 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(staticConst);
return staticConst ;
}

$ g++ -o main main.cpp
$ nm main | grep staticConst
0000000000400938 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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Christian Meier]

"James Kanze" <ja*********@gmail.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(staticConst);
return staticConst ;
}

$ g++ -o main main.cpp
$ nm main | grep staticConst
0000000000400938 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<intor std::vector<double>, 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 objektorientierter Datenverarbeitung
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<intor std::vector<double>, 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

[James Kanze]

On Oct 6, 5:41 pm, Hendrik Schober <[e-mail]:

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<intor std::vector<double>, 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?

Which argument? That it's premature optimization? Or that it
might actually be pessimization in some very frequent cases?

In all cases, of course, it depends on the machine. (On my
machine, the first five words of non-class types are passed in
registers.) And what you are doing; if you're passing a
literal, for example, the pass by reference means that the
compiler must first generate a temporary, and put the value
there; if you're passing four of them, the fact that a double
requires two registers on my machine (in 32 bit mode) means that
some spill into memory with pass by value, none of the addresses
do with pass by reference. That's all before the optimizer
kicks in, of course. Until you've done the actual measurements,
you don't know. (And of course, you won't bother doing them
unless you have an actual performance problem.)

Note too that I said explicitly "one can argue". What I've just
presented is only one side of the argument. The "premature
optimization" argument, for example, must be considered in view
of the fact that implementors can't change the interface
specified in the standard if they do have performance problems,
and because it's a library, probably can't even really measure
actual use, and have to make some guesses. And in this case,
pass by reference can maybe be viewed as legitimate dammage
control; regardless of the variation, it shouldn't kill you for
the basic types, and avoids an extra copy if the types are
expensive to copy. (I don't really buy this latter argument,
since std::vector will do a bit of copying anyway. Value
semantics should imply cheap to copy, or there's a problem with
the design.)

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

[Hendrik Schober]

James Kanze wrote:

[...]

> 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?

Which argument? That it's premature optimization? Or that it
might actually be pessimization in some very frequent cases?

Both. :^>

[reasoning snipped]

Thanks.

Schobi