Modifying the arguments to a function is a bad idea

[David Resnick]

Me neither.

I'm not a big fan of debuggers, my tools of choice are debugging
statements (which we build into our deployed code anyway for enabling
at customer sites to investigate issues) for functional problems and
valgrind/purify for memory corruption. I haven't needed or wanted to
step through code with a debugger in years, hasn't been relevant to
the programming I've been doing. But I use debuggers on a regular
basis to open and analyze core files. I gather those of you who don't
use debuggers have no need to crack open cores? i.e. work on systems
that don't dump them, or use other means?

-David

 

[Anand Hariharan]

On Thu, 30 Jul 2009 02:59:41 +0000, Richard Heathfield

The way I see it, this is (largely) what const is for - to protect your
parameters when you know you *don't* want to modify them.

Unless one deals with pointer types and the const qualifies the
dereferenced value, I see little value in qualifying parameters with
const considering they are all pass-by-value anyway.

Taking Jacob's example, I will only be confused if I were to see the
prototype of fn as
int fn(const int a);
rather than what Jacob originally had viz.,
int fn(int a);
only because the implementor wanted to remind himself not to modify 'a'
within fn.

'const' should be used because it is part of the interface (and the
implementation is driven by the interface) rather than the implementation.

- Anand

 

[Keith Thompson]

On Thu, 30 Jul 2009 02:59:41 +0000, Richard Heathfield


Unless one deals with pointer types and the const qualifies the
dereferenced value, I see little value in qualifying parameters with
const considering they are all pass-by-value anyway.

Taking Jacob's example, I will only be confused if I were to see the
prototype of fn as
int fn(const int a);
rather than what Jacob originally had viz.,
int fn(int a);
only because the implementor wanted to remind himself not to modify 'a'
within fn.

'const' should be used because it is part of the interface (and the
implementation is driven by the interface) rather than the implementation.

Well, you can always write:

int fn(int a); /* callers don't care whether it's modified */

/* ... */

int fn(const int a)
{
/* code that doesn't modify a */
}

My personal preference is to declare each object as "const" by
default, omitting the "const" only if I need to modify it after its
initialization. It makes it easier to reason about the behavior of
the code if I can be sure that the current value is the same as the
initial value without having to search for something that might have
modified it. But for parameters, this requires either making the
"const" uselessly visible in the prototype, or making the prototype
and the definition inconsistent.

 

[Anand Hariharan]

Well, you can always write:

int fn(int a); /* callers don't care whether it's modified */

/* ... */

int fn(const int a)
{
/* code that doesn't modify a */
}

My personal preference is to declare each object as "const" by default,
omitting the "const" only if I need to modify it after its
initialization. (...)
But for parameters, this requires either making the "const"
uselessly visible in the prototype, or making the prototype and the
definition inconsistent.

I admit I was not aware that the language allowed this inconsistency
between prototype and definition.

- Anand

 

[Antoninus Twink]

What common and well accepted environment for reading usenet strips
subject lines from posts?

None, I'd wager.

What's that got to do with it?

It's pure Asperger's - just because noone heard the sound, Kiki *just
knows* that the tree falling made a noise, and he can't help himself
complaining about it.

 

[Chris M. Thomasson]

What's that got to do with it?

It's pure Asperger's - just because noone heard the sound, Kiki *just
knows* that the tree falling made a noise, and he can't help himself
complaining about it.

There are a whole lot of very super smart people who have engineers disease.

 

[lawrence.jones]

Unless one deals with pointer types and the const qualifies the
dereferenced value, I see little value in qualifying parameters with
const considering they are all pass-by-value anyway.

Although it's mostly off-topic, one place this is very valuable is when
doing multi-language programming where the other languages are *not*
pass by value. Changing a parameter's value when the caller is written
in such a language rather than C can cause horrible problems.