What does the passage mean on const Parameters?

[fl]

Hi,
I am learning C++ with "C++ primer" Fourth edition by Stanley B.
Lippman, Josee Lajoie and Barbara E. Moo.
I have a difficuty when I learn Chapter 7. Funtions. More
specifically, 7.2.1. Nonreference Parameters.
In passage on "const Parameters", it first gives an example:

const int i = 3, j = 6;
int k = gcd(3, 6); // ok: k initialized to 3

It says that it works no matter int or const int for gcd's argument.



My problem is the following. I copy the detail contents here. I type
these words as possible as the original text except I cannot type
italic font here. I don't understand the meaning of these paragraphs.
What is the implication of the two void fcn function? Does these
paragraphs tell me that

void fcn(const int i) { /* fcn can read butnot write to i */ }

is not supported by C++?

Could you explain it to me? Thanks.


The most puzzled me is the except from below:
---------------------------------
What may be surprising, is that although the parameter is a const
inside the function, the compiler otherwise treats the definition of
fcn as if we had defined the parameter as a plain int:

void fcn(const int i) { /* fcn can read but not write to i */ }
void fcn(int i) { /* .........*/ } // error:
redefines fcn(int)
---------------------------------




.............
If we make the parameter a const nonreference type:

void fcn(const int i) { /* fcn can read butnot write to i */ }

then the function cannot change its local copy of the argument. The
argument is still passed as a copy so we can pass fcn either a const
or nonconst object.

What may be surprising, is that although the parameter is a const
inside the function, the compiler otherwise treats the definition of
fcn as if we had defined the parameter as a plain int:

void fcn(const int i) { /* fcn can read but not write to i */ }
void fcn(int i) { /* .........*/ } // error:
redefines fcn(int)

This usage exists to support compatibility with the C language, which
makes no distinction between functions taking const or nonconst
parameters.

.......................................................

 

[Alf P. Steinbach]

* fl, on 15.06.2010 05:59:

Hi,
I am learning C++ with "C++ primer" Fourth edition by Stanley B.
Lippman, Josee Lajoie and Barbara E. Moo.
I have a difficuty when I learn Chapter 7. Funtions. More
specifically, 7.2.1. Nonreference Parameters.
In passage on "const Parameters" [...}:

OK. This is about whether two declarations of a function refer to the same
function or not. And they do refer to the same function if the names are the
same and the *function type* is the same in both declarations.

The function type is deduced from your declaration by sort of rewriting the
formal argument types, including that

* top level 'const' for a formal argument is removed, e.g.
'int const a' -> 'int a',

* function types are converted to function pointer types, e.g.
'void callback( int x )' -> 'void (*callback)( int x )', and

* arrays (but not references to arrays) are converted to pointers,
completely losing and disregarding any stated array size, e.g.
'int weights[42]' -> 'int* weights'.

So when you write

void foo( int x ) {}
void foo( int const x ) {}

the compiler sees the function types, which together with the names *identify*
them, as

void foo( int );
void foo( int );

and complains that you have two or more definitions of the same function, which
effectively means that you cannot overload solely on top-level 'const'.

The 'const' is honored within the function definition, but it's not part of the
identifying type.

Almost the same would happen with e.g.

void foo( int weights[42] );
void foo( int* age );

where all that the compilers sees wrt. identification is

void foo( int* );
void foo( int* );

However, unlike the 'const' the formal argument's array size is not effective
within the function definition. With 'const' the only effect of the rewriting is
for identification of the function. With array and function-type arguments the
effect is as if the rewriting had been performed on the source code: the result
after the rewriting is all that you have inside the function definition.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* Alf P. Steinbach, on 15.06.2010 06:19:

* fl, on 15.06.2010 05:59:

Hi,
I am learning C++ with "C++ primer" Fourth edition by Stanley B.
Lippman, Josee Lajoie and Barbara E. Moo.
I have a difficuty when I learn Chapter 7. Funtions. More
specifically, 7.2.1. Nonreference Parameters.
In passage on "const Parameters" [...}:

OK. This is about whether two declarations of a function refer to the
same function or not. And they do refer to the same function if the
names are the same and the *function type* is the same in both
declarations.

The function type is deduced from your declaration by sort of rewriting
the formal argument types, including that

* top level 'const' for a formal argument is removed, e.g.
'int const a' -> 'int a',

* function types are converted to function pointer types, e.g.
'void callback( int x )' -> 'void (*callback)( int x )', and

* arrays (but not references to arrays) are converted to pointers,
completely losing and disregarding any stated array size, e.g.
'int weights[42]' -> 'int* weights'.

So when you write

void foo( int x ) {}
void foo( int const x ) {}

the compiler sees the function types, which together with the names
*identify* them, as

void foo( int );
void foo( int );

and complains that you have two or more definitions of the same
function, which effectively means that you cannot overload solely on
top-level 'const'.

The 'const' is honored within the function definition, but it's not part
of the identifying type.

Almost the same would happen with e.g.

void foo( int weights[42] );
void foo( int* age );

where all that the compilers sees wrt. identification is

void foo( int* );
void foo( int* );

However, unlike the 'const' the formal argument's array size is not
effective within the function definition. With 'const' the only effect
of the rewriting is for identification of the function. With array and
function-type arguments the effect is as if the rewriting had been
performed on the source code: the result after the rewriting is all that
you have inside the function definition.

Oh, I should add, before someone else does, that return types are disregarded
with respect to function identity. Sorry for forgetting to mention that. It
means that you cannot overload solely on return type, either.


Cheers,

- Alf