const &

[Marcin Vorbrodt]

I understand that compiler may optimize better, if as parameters to my
functions i pass:

const Object &o

instead of

Object &o

All the implicit type conversion and all sounds good (Effective C++ rules).

But, does it make any difference if i do simillar thing for primitive types:

function(int x) vs function(const int x)

and i know that x will not be assigned to in the body of the function.
Is there any advantage at all in putting the const qualifier for primitives?

Thanks,
Martin

[Kevin Goodsell]

Marcin Vorbrodt wrote:

I understand that compiler may optimize better, if as parameters to my
functions i pass:

const Object &o

instead of

Object &o
I don't know about that. But it does make the function more flexible
since you can pass temporaries and constant objects. There's also no
good reason to /not/ use const here, if you don't intend to change the
object.

All the implicit type conversion and all sounds good (Effective C++ rules).

But, does it make any difference if i do simillar thing for primitive types:

function(int x) vs function(const int x)

and i know that x will not be assigned to in the body of the function.
Is there any advantage at all in putting the const qualifier for primitives?

I don't think so.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Josh Sebastian]

On Sun, 07 Sep 2003 15:16:31 -0400, Marcin Vorbrodt wrote:

I understand that compiler may optimize better, if as parameters to my
functions i pass:

const Object &o

instead of

Object &o

No, you (might) get better performance if you use

const Object& o

instead of

Object o

Josh

[Pete Becker]

"Oliver S." wrote:

In the unlikely case using the const qualifier does help performance
don't expect a big boost.

The called code is allowed to cast to a non-const reference if the
underlying object has only logical (as opposed to physical) constness.
So the compiler can assume that the object's non-mutable elements are
not changed only if the object has physical constness - which is very
unusual.

The true rule is that you can cast away const if the original object
isn't const. Otherwise you get undefined behavior. A common example is:

int main()
{
const int i = 3;
int& ir = const_cast<int&)(i);
ir = 4;
printf("%d\n", i);
return 0;
}

With some compilers this prints 3, with others 4. Both answers are
acceptable, because the behavior of the program is undefined.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

"Oliver S." wrote:

The true rule is that you can cast away const if the original
object isn't const.

That's only one of the rules which describe objects that have
logical constness.

Maybe. The obvious implication is that "logical constness" isn't the
test for casting away const.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)