const int Foo in paramater list? Question of style

[Jim Langston]

In my function/method paramater list I try to keep constant correctness.
I.E. I would use:
int Foo( const char* a, int b )
instead of
int Foo( char* a, int b )

My question reguards int b. Would it be more correct to make it
int Foo( const char* a, const int b )
instead? I do know the effect of this would be that I can't change b in the
function, which I normally never do anyway.

Can anyone think of a compelling reason to use one over the other? Or is it
just a matter of style?

Thanks.

 

[Mark P]

In my function/method paramater list I try to keep constant correctness.
I.E. I would use:
int Foo( const char* a, int b )
instead of
int Foo( char* a, int b )

My question reguards int b. Would it be more correct to make it
int Foo( const char* a, const int b )
instead? I do know the effect of this would be that I can't change b in the
function, which I normally never do anyway.

Can anyone think of a compelling reason to use one over the other? Or is it
just a matter of style?

I doubt there's a compelling reason to prefer either, but I find that it
decreases readability slightly. Personally I leave it off unless I have
a reason to be especially emphatic about the immutability of that
parameter. I think I have done so in very rare circumstances, but
nothing specific comes to mind.

 

[Craig Scott]

In my function/method paramater list I try to keep constant correctness.
I.E. I would use:
int Foo( const char* a, int b )
instead of
int Foo( char* a, int b )

My question reguards int b. Would it be more correct to make it
int Foo( const char* a, const int b )
instead? I do know the effect of this would be that I can't change b in the
function, which I normally never do anyway.

Can anyone think of a compelling reason to use one over the other? Or is it
just a matter of style?

As far as the compiler is concerned, the following have the same
function signature:

void foo(int a);
void foo(const int a);

The compiler essentially ignores the "const" (except inside the
function body, as you already noted). This can be surprising to some
people, so my vote is to not use const on non-pointer/non-reference
types. If you want to enforce const within your function body, you can
use a const reference to the parameter and any decent compiler should
optimize so that there is no difference.

 

[James Kanze]

In my function/method paramater list I try to keep constant correctness.
I.E. I would use:
int Foo( const char* a, int b )
instead of
int Foo( char* a, int b )

My question reguards int b. Would it be more correct to make it
int Foo( const char* a, const int b )
instead? I do know the effect of this would be that I can't change b in the
function, which I normally never do anyway.

Can anyone think of a compelling reason to use one over the
other? Or is it just a matter of style?

It's largely a matter of style. As Craig Scott pointed out, top
level const is ignored in the declaration. And since the
argument is passed by value, you have a local copy; whether you
modify it or not is irrelevant to the client, since he won't see
any of the modifications anyway.

I think most programmers just ignore const completely here. For
those who want the const in the definition (where it is
significant, and can provide information to whoever reads the
function body), there are two schools of thought:
-- only use it in the definition, since it is irrelevant (and
an implementation detail, which may change) to the user, or
-- use it in the declarations as well, so that the declarations
and the definitions are identical.
(I rather prefer the first, but in practice, like most people I
know, I don't use const here.)