By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,804 Members | 1,666 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,804 IT Pros & Developers. It's quick & easy.

const on primitive type parameters

P: n/a
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.
Jun 22 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
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
Jun 22 '06 #2

P: n/a
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
Jun 22 '06 #3

P: n/a
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';
}

Jun 22 '06 #4

P: n/a
On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.dude> 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
Jun 22 '06 #5

P: n/a
Roland Pibinger wrote:
On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.dude> 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.
Jun 22 '06 #6

P: n/a
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.
Jun 23 '06 #7

P: n/a
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;
}
Jun 23 '06 #8

P: n/a
red floyd wrote:
Roland Pibinger wrote:
On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.dude> 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.

Jun 23 '06 #9

P: n/a
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.
Jun 23 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.