const in argument

[Matthew Monopole]

hi:

When we declare something like:
func(const class a)

we protect the variable a from being modified during func...right? okay
first question: if a is passed by value, who care if it's modified??!!

now, what about we do
func(const class& a) or
func(const class* a)
then, in either case, is a begin protected? or a pointer that points to a?

thankx!

 

[John Harrison]

But a is the pointer. What is being protected is the object that a points
(or refers) to. This is a very important consideration because the caller of
func certainly is interested if calling func will modify a.

I mean of course.

if calling func will modify the object that a points (or refers) to.

john

 

[Russell Hanneken]

When we declare something like:
func(const class a)

we protect the variable a from being modified during func...right?

What you wrote isn't legal C++, but I assume you mean something like this:

void func (const Foo a);

first question: if a is passed by value, who care if it's modified??!!

Probably no one. There isn't much point in making a parameter const if it's
a copy of the caller's argument.

now, what about we do
func(const class& a) or
func(const class* a)
then, in either case, is a begin protected? or a pointer that points to a?

In the first case, a is a reference to an object passed by the caller.
Here, the "const" means that you can't use a to modify that object.

In the second case, a is a pointer which holds a copy of an address passed
by the caller. Here "const" means that you can't modify the object to which
a points if you access it through a. a itself is not const; you can modify
its value if you want. Since a holds a copy of the caller's pointer, the
caller's pointer is not modified when you change a.

Regards,

Russell Hanneken
(e-mail address removed)

 

[Matthew Monopole]

I read somewhere that when overloading operator, it is best to use friend
and declare like this:
friend operator+(const class1&, const class2&);

Is there a reason why would one prefer friend over class1obj.operator+(const
class2&)? I used to thought it was for commutivity between classes, for
example, when we want class1obj+class2obj=class2obj+class1obj, but this
turns out to be not true. I still have to overload the operator twice with
the argument order reversed....

and (relating to earlier post) why do we (have to) use this const class&,
instead of just class? my guess is that you don't want to waste time copying
the object?

 

[Ivan Vecerina]

When we declare something like:
func(const class a)

I assume you intend to use a type such as 'int' or 'MyStruct'
instead of 'class'.

we protect the variable a from being modified during func...right? okay
first question: if a is passed by value, who care if it's modified??!!

The point is: you protect the copy of the parameter used by func
from being modified within func. Which is just as useful as
using const with any other local variable declaration.

However, this const is NOT part of the function's signature -- and does
not belong to the function's interface.
So the style I would personally recommend is:

//file.h
void func(int a);

//file.cpp
void func(int const a)
{
....
}

See also the following post for info on what the standard says:
groups.google.com/groups?selm=3c6472fa%241%40news.swissonline.ch

now, what about we do
func(const class& a) or

'a' is passed by reference -- and the const protects it from
being changed.

func(const class* a)
then, in either case, is a begin protected? or a pointer that points to a?

f(const int* a) is equivalent to f(int const* a): the value being
pointed to is protected from any modifications. Which is
meaningful to the caller.

Note that one could use:
//file.h
void func(int const* a); // func does not modify *a

//file.cpp
void func(int const* const a)
{ // func does not modify *a, and 'a' itself is const here too
....
}



hth,

 

[Ivan Vecerina]

Is there a reason why would one prefer friend over class1obj.operator+(const
class2&)? I used to thought it was for commutivity between classes, for
example, when we want class1obj+class2obj=class2obj+class1obj, but this
turns out to be not true. I still have to overload the operator twice with
the argument order reversed....

NB: What does this have to do with the topic of this thread (const usage) ?

The point of using 'friend' is that it allows implicit conversions on
both sides of the operator.
For example, if you have a complex number class with a non-explicit
constructor such as:
complex(float f) : r(f), i(0) {}

And try to call it as follows:
void f(complex a, complex b, float f)
{
complex c0 = a+b; // ok anyway
complex c1 = a+f; // ok anyway
complex c2 = f+a; // only works if operator+ is a friend
}

and (relating to earlier post) why do we (have to) use this const class&,
instead of just class? my guess is that you don't want to waste time copying
the object?

Yes: it helps prevent unnecessary object copies when copies are expensive.


hth

 

[John Harrison]

NB: What does this have to do with the topic of this thread (const usage) ?

The point of using 'friend' is that it allows implicit conversions on
both sides of the operator.

Which also means in cases where you don't want an implicit conversion on the
left hand side, you should the non-friend form. This is usually the case
with assignment operators +=, *= etc.

john

 

[Rolf Magnus]

I read somewhere that when overloading operator, it is best to use
friend and declare like this:
friend operator+(const class1&, const class2&);

Only make it a friend if it really needs to access private members.

Is there a reason why would one prefer friend over
class1obj.operator+(const class2&)? I used to thought it was for
commutivity between classes, for example, when we want
class1obj+class2obj=class2obj+class1obj, but this turns out to be not
true. I still have to overload the operator twice with the argument
order reversed....

But you can put both at the same place. If they were members, you would
need to put one into class1, the other one into class2.

and (relating to earlier post) why do we (have to) use this const
class&, instead of just class? my guess is that you don't want to
waste time copying the object?

Yes.