const on primitive type parameters

[red floyd]

Anybody have any preferences as to declaring primitive type parameter as
const, if the function body doesn't change it?

e.g.:

int f(int x)
{
return x+2;
}

versus

int f(const int x)
{
return x + 2;
}

I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style.

[Victor Bazarov]

red floyd wrote:

Anybody have any preferences as to declaring primitive type parameter
as const, if the function body doesn't change it?

e.g.:

int f(int x)
{
return x+2;
}

versus

int f(const int x)
{
return x + 2;
}

I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style.

Have you tried asking them?

To asnwer your question, I prefer the latter. Adding a 'const' there
changes nothing for a function like that, except requires 6 characters
to be typed.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Andrey Tarasevich]

red floyd wrote:

Anybody have any preferences as to declaring primitive type parameter as
const, if the function body doesn't change it?

e.g.:

int f(int x)
{
return x+2;
}

versus

int f(const int x)
{
return x + 2;
}

I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style.

I'd say that it would make more sense if the logic was "reversed". I
have seen some style guides that suggested that function parameter
values should never be changed inside the function. Whenever it is
necessary to "play" with the value, it should be copied to a local
variable first. I don't follow this rule myself, but I'd agree that it
makes certain sense. For a programmer who follows such style guide, it
would be perfectly logical to _always_ declare all function parameters
as 'const' (apart from situations when it is impossible or makes no
sense, like references and arrays).

The logic that you propose ("declare it as const iff it is not changed")
doesn't appear to be very useful to me. Maybe it is just me, though...

--
Best regards,
Andrey Tarasevich

[Frederick Gotham]

red floyd posted:

Anybody have any preferences as to declaring primitive type parameter as const, if the function body doesn't change it?

e.g.:

int f(int x)
{
return x+2;
}

versus

int f(const int x)
{
return x + 2;
}

I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style.

I use the second whenever I won't be altering the object. However,
there's times when I do the likes of the following:

void Func( char *p )
{
for( ; *p; ++p ) *p = 'a';
}

[Roland Pibinger]

On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.d ude> wrote:

Anybody have any preferences as to declaring primitive type parameter as
const, if the function body doesn't change it?

e.g.:

int f(int x)
{
return x+2;
}

versus

int f(const int x)
{
return x + 2;
}
Changes to the copy of a value in the 'function body' are an
implementation detail that should not affect the interface. I see no
advantage for version 2.
I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style.

At least, the first version is written in the usual style.

Best wishes,
Roland Pibinger

[red floyd]

Roland Pibinger wrote:

On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.d ude> wrote:

Anybody have any preferences as to declaring primitive type parameter as
const, if the function body doesn't change it?

e.g.:

int f(int x)
{
return x+2;
}

versus

int f(const int x)
{
return x + 2;
}

Changes to the copy of a value in the 'function body' are an
implementation detail that should not affect the interface. I see no
advantage for version 2.

I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style.

At least, the first version is written in the usual style.

For once, Roland, I agree with you. I was overruled by TPTB on my
project however. If a function doesn't tweak a parameter, then it's
const. If it changes (as the loop example someone else posted does),
then it's non-const.

Ugh.

[I V]

On Thu, 22 Jun 2006 21:48:48 +0000, Roland Pibinger wrote:

Changes to the copy of a value in the 'function body' are an
implementation detail that should not affect the interface. I see no
advantage for version 2.

Does declaring a by-value argument const affect the interface, though?
Consider:

void f(int i)
{
return;
}

void f(const int i)
{
return;
}

G++ and Comeau, at least, complain that the second is a redefinition of
the function, which makes sense to me. If that's the correct behavior, it
then presumably the const-ness of the arguments is not part of the
function signature. Thus, when you're declaring the interface, you can
omit the const, but in the function definition, you add the const, if it's
appropriate, for the same reason you would declare a local variable const.

[Roland Pibinger]

On Thu, 22 Jun 2006 22:18:34 -0700, I V <wr******@gmail .com> wrote:

On Thu, 22 Jun 2006 21:48:48 +0000, Roland Pibinger wrote:

Changes to the copy of a value in the 'function body' are an
implementation detail that should not affect the interface. I see no
advantage for version 2.

Does declaring a by-value argument const affect the interface, though?
Consider:

void f(int i)
{
return;
}

void f(const int i)
{
return;
}

G++ and Comeau, at least, complain that the second is a redefinition of
the function, which makes sense to me. If that's the correct behavior, it
then presumably the const-ness of the arguments is not part of the
function signature. Thus, when you're declaring the interface, you can
omit the const, but in the function definition, you add the const, if it's
appropriate, for the same reason you would declare a local variable const.

You are right from the syntactical point of view. But shall the
following functions really be different WRT the constness of the
parameter?

int f1 (const int i) {
return i+2;
}

int f2 (int i) {
return i+=2;
}

[Markus Schoder]

red floyd wrote:

Roland Pibinger wrote:

On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.d ude> wrote:

Anybody have any preferences as to declaring primitive type parameter as
const, if the function body doesn't change it?

e.g.:

int f(int x)
{
return x+2;
}

versus

int f(const int x)
{
return x + 2;
}

Changes to the copy of a value in the 'function body' are an
implementation detail that should not affect the interface. I see no
advantage for version 2.

I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style.

At least, the first version is written in the usual style.

For once, Roland, I agree with you. I was overruled by TPTB on my
project however. If a function doesn't tweak a parameter, then it's
const. If it changes (as the loop example someone else posted does),
then it's non-const.

I clearly prefer version 2. What can be const should be const. For trivial
examples like the one above it may not make a difference but for more
complex functions it improves code readability because you can rely on the
value of the variable not changing throughout the function. I actually try
to avoid updating variables to preserve their constness e.g. instead of

int f(int x)
{
// use x
++x;
// use x
}

I write

int f(const int x)
{
// use x
const int x1 = x + 1;
// use x1
}

also helpful is the ?: operator to initialize const variables.

I think this style of programming captures some of the advantages of (pure)
functional languages.

[I V]

On Fri, 23 Jun 2006 19:58:46 +0000, Roland Pibinger wrote:

You are right from the syntactical point of view. But shall the
following functions really be different WRT the constness of the
parameter?

int f1 (const int i) {
return i+2;
}

int f2 (int i) {
return i+=2;
}

Why not? Should these two function differ as to the constness of the local
variable?

int f1()
{
const int i = get_value();
return i+2;
}

int f2()
{
int i = get_value();
return i+=2;
}

Obviously, for small, pointless example functions it doesn't really
matter. But, if there are advantages to making local variables const,
surely the same advantages apply to making parameters const. After all a
parameter _is_ a local variable; some features of it are also part of the
interface, but constness isn't one of these, so wrt const, the same rules
should apply to parameters as to any other local variable, I would think.