const correctness

[mandydhaliwal]

Hi Guys,


I was going through a product's source code. They never use const
function arguments with default value.
for instance

Never noticed following type of declaration

foo ( const int param1, const bool = false) const;

instead
of this
foo ( const int param1, bool = false) const; is used widely.

I there any drawback of using default argument with const keyword?

 

[Alf P. Steinbach]

* (e-mail address removed):

I was going through a product's source code. They never use const
function arguments with default value.
for instance

Never noticed following type of declaration

foo ( const int param1, const bool = false) const;

instead
of this
foo ( const int param1, bool = false) const; is used widely.

I there any drawback of using default argument with const keyword?

No, the two declarations are equivalent (and by that I mean, they would
specify exactly the same function signature, if a return type was added).

 

[David White]

Hi Guys,


I was going through a product's source code. They never use const
function arguments with default value.
for instance

Never noticed following type of declaration

foo ( const int param1, const bool = false) const;

instead
of this
foo ( const int param1, bool = false) const; is used widely.

I there any drawback of using default argument with const keyword?

I don't think there's any point in making any pass-by-value parameter const,
default or not. The const only affects how the function can use the
parameter and makes no difference to the caller. Why should the public
interface declare that a function will not modify its own private copy of an
argument? IMO such consts clutter up the public interface with junk that is
really none of the caller's business.

DW

 

[Aleksey Loginov]

I don't think there's any point in making any pass-by-value parameter const,
default or not. The const only affects how the function can use the
parameter and makes no difference to the caller. Why should the public
interface declare that a function will not modify its own private copy of an
argument? IMO such consts clutter up the public interface with junk that is
really none of the caller's business.

it's makes difference when your const object behave not like no-const:

struct test {
void operator () () { }
void operator () () const { /* terrible things here */ }
};

 

[Risto Lankinen]

I don't see how that relates to my post. If a function declares a
pass-by-value parameter const, you are free to pass either a const or
non-const value to it, since it's only the copy received by the function,
not the original, that is declared const.

void foo( test t )
{
t();
}

void foo( test const t )
{
t(); /* those terrible things now happen */
}

 

[David White]

it's makes difference when your const object behave not like no-const:

struct test {
void operator () () { }
void operator () () const { /* terrible things here */ }
};

I don't see how that relates to my post. If a function declares a
pass-by-value parameter const, you are free to pass either a const or
non-const value to it, since it's only the copy received by the function,
not the original, that is declared const.

DW

 

[David White]

void foo( test t )
{
t();
}

void foo( test const t )
{
t(); /* those terrible things now happen */
}

Well, that looks like a completely contrived and unrealistic example to me.
The only times I've ever had const and non-const versions of the same
function are when they do exactly the same thing with the exception of
const, e.g.,

class Point
{
public:
const double &X() const { return x; }
double &X() { return x; }
// ...
private:
double x;
// ...
};

In any case, you still don't have to make your parameter const:
void foo( test t )
{
const test &u = t;
u();
}

I maintain that what goes on inside foo is of no concern to the caller, and
so should not manifest itself in the declaration of the parameter the caller
sees. After all, the parameter will cease to exist once the function
returns.

DW

 

[mlimber]

David White wrote:
[snip]

I maintain that what goes on inside foo is of no concern to the caller, and
so should not manifest itself in the declaration of the parameter the caller
sees. After all, the parameter will cease to exist once the function
returns.

I agree with your point about cluttering up the interface, but I do
think that const pass-by-value parameters are useful. First, note that
one needn't put the const in the function prototype or class
declaration in order to use it in the definition since, as Alf notes
above, the const doesn't change the function signature:

struct Foo { Foo( int ); };

Foo::Foo( const int param )
{
const int magicNo = 42;
// ...
}

Applying const to param in the definition is no different than applying
it to the local constant magicNo, but making them both const makes the
function "easier to understand, track, and reason about" (_C++ Coding
Standards_, p. 30) because the programmer's intention is clear -- viz.,
neither magicNo or param will change throughout the function.

Of course there are cases where one might not want to make all
pass-by-value parameters const, but the general principle of
const-correctness is to make everything const that can be const. I
would apply that to pass-by-value parameters as well.

Cheers! --M

 

[Greg Comeau]

I was going through a product's source code. They never use const
function arguments with default value.
for instance

Never noticed following type of declaration

foo ( const int param1, const bool = false) const;

instead
of this
foo ( const int param1, bool = false) const; is used widely.

I there any drawback of using default argument with const keyword?

In and of itself, that should be neutral.

You will find shops/people who don't allow const at the
top level in general, as they take the signature, and hence
interface of the functions very seriously, and so feel that
the const has no place at the top level. So one issue is
philosphical/conceptual lieing But it can lead to physical
confusion, for instance:

void foo(const int arg);

Turns out that the const is tossed in the example,
since it is only a declaration. However, it would not
be tossed in the definition:

void foo(const int arg) { /* ... */ }

hence coming full circle to the opponents of such use.

Personally I don't like having to declare something only
then to make a const copy of it, or just ignore it (leaving
it non-const), but the above make sense too.

 

[Greg Comeau]

it's makes difference when your const object behave not like no-const:

struct test {
void operator () () { }
void operator () () const { /* terrible things here */ }
};

David is talking about const applied as a top level qualified,
not a const member fucnction. I realize you might be trying
to point of the benefits of const though; I doubt David
disagrees about their benefits, just how they sh/c/ould come about.

 

[Greg Comeau]

void foo( test t )
{
t();
}

void foo( test const t )
{
t(); /* those terrible things now happen */
}

That's an invalid overload, IOWs: you can't do that.

 

[Greg Comeau]

general principle of const-correctness is to make everything const
that can be const.

The problem is that can and should are different

 

[Aleksey Loginov]

David is talking about const applied as a top level qualified,
not a const member fucnction. I realize you might be trying
to point of the benefits of const though; I doubt David
disagrees about their benefits, just how they sh/c/ould come about.
--

I agree with mlimber point "to make everything const that can be
const".
People, who working with your code after you, may say "Thanks" for that.

 

[Risto Lankinen]

That's an invalid overload, IOWs: you can't do that.

Illustrates the point, though, does it not?

If you indeed have hard time seeing the point, please re-read
but replace "bar" for "foo" in one of the functions.

- Risto -

 

[Greg Comeau]

Illustrates the point, though, does it not?

If you indeed have hard time seeing the point, please re-read
but replace "bar" for "foo" in one of the functions.

This thread had a few "the point"s. If you think we disagree
somehow on one or more, just restate it instead of an editing session