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]

Re: const in argument

>[color=blue]
> 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[/color]
of[color=blue]
> func certainly is interested if calling func will modify a.
>[/color]

I mean of course.

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

john

[Russell Hanneken]

Re: const in argument

"Matthew Monopole" <mathfield@hotm ail.com> wrote in message
news:zkoZa.4940 $M6.361566@news read1.prod.itd. earthlink.net.. .[color=blue]
>
> When we declare something like:
> func(const class a)
>
> we protect the variable a from being modified during func...right?[/color]

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

void func (const Foo a);
[color=blue]
> first question: if a is passed by value, who care if it's modified??!![/color]

Probably no one. There isn't much point in making a parameter const if it's
a copy of the caller's argument.
[color=blue]
> 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?[/color]

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
rhanneken@pobox .com

[John Harrison]

Re: const in argument

>[color=blue]
> 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[/color]
of[color=blue]
> func certainly is interested if calling func will modify a.
>[/color]

I mean of course.

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

john

[Matthew Monopole]

Re: const in argument

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.opera tor+(const
class2&)? I used to thought it was for commutivity between classes, for
example, when we want class1obj+class 2obj=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?

"John Harrison" <john_andronicu s@hotmail.com> wrote in message
news:bh54n5$tjb ik$1@ID-196037.news.uni-berlin.de...[color=blue][color=green]
> >
> > But a is the pointer. What is being protected is the object that a[/color][/color]
points[color=blue][color=green]
> > (or refers) to. This is a very important consideration because the[/color][/color]
caller[color=blue]
> of[color=green]
> > func certainly is interested if calling func will modify a.
> >[/color]
>
> I mean of course.
>
> if calling func will modify the object that a points (or refers) to.
>
> john
>
>[/color]

[Russell Hanneken]

Re: const in argument

"Matthew Monopole" <mathfield@hotm ail.com> wrote in message
news:zkoZa.4940 $M6.361566@news read1.prod.itd. earthlink.net.. .[color=blue]
>
> When we declare something like:
> func(const class a)
>
> we protect the variable a from being modified during func...right?[/color]

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

void func (const Foo a);
[color=blue]
> first question: if a is passed by value, who care if it's modified??!![/color]

Probably no one. There isn't much point in making a parameter const if it's
a copy of the caller's argument.
[color=blue]
> 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?[/color]

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
rhanneken@pobox .com

[Ivan Vecerina]

Re: const in argument

"Matthew Monopole" <mathfield@hotm ail.com> wrote in message
news:zkoZa.4940 $M6.361566@news read1.prod.itd. earthlink.net.. .[color=blue]
> When we declare something like:
> func(const class a)[/color]
I assume you intend to use a type such as 'int' or 'MyStruct'
instead of 'class'.
[color=blue]
> 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??!![/color]

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.c om/groups?selm=3c6 472fa%241%40new s.swissonline.c h
[color=blue]
> now, what about we do
> func(const class& a) or[/color]

'a' is passed by reference -- and the const protects it from
being changed.
[color=blue]
> func(const class* a)
> then, in either case, is a begin protected? or a pointer that points to a?[/color]

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, Dr. med. <> http://www.post1.com/~ivec
Brainbench MVP for C++ <> http://www.brainbench.com

[Matthew Monopole]

Re: const in argument

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.opera tor+(const
class2&)? I used to thought it was for commutivity between classes, for
example, when we want class1obj+class 2obj=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?

"John Harrison" <john_andronicu s@hotmail.com> wrote in message
news:bh54n5$tjb ik$1@ID-196037.news.uni-berlin.de...[color=blue][color=green]
> >
> > But a is the pointer. What is being protected is the object that a[/color][/color]
points[color=blue][color=green]
> > (or refers) to. This is a very important consideration because the[/color][/color]
caller[color=blue]
> of[color=green]
> > func certainly is interested if calling func will modify a.
> >[/color]
>
> I mean of course.
>
> if calling func will modify the object that a points (or refers) to.
>
> john
>
>[/color]

[Ivan Vecerina]

Re: const in argument

"Matthew Monopole" <mathfield@hotm ail.com> wrote in message
news:10pZa.4946 $M6.362893@news read1.prod.itd. earthlink.net.. .[color=blue]
> Is there a reason why would one prefer friend over[/color]
class1obj.opera tor+(const[color=blue]
> class2&)? I used to thought it was for commutivity between classes, for
> example, when we want class1obj+class 2obj=class2obj+ class1obj, but this
> turns out to be not true. I still have to overload the operator twice with
> the argument order reversed....[/color]

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
}
[color=blue]
> 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[/color]
copying[color=blue]
> the object?[/color]

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


hth
--
Ivan Vecerina, Dr. med. <> http://www.post1.com/~ivec
Brainbench MVP for C++ <> http://www.brainbench.com

[Ivan Vecerina]

Re: const in argument

"Matthew Monopole" <mathfield@hotm ail.com> wrote in message
news:zkoZa.4940 $M6.361566@news read1.prod.itd. earthlink.net.. .[color=blue]
> When we declare something like:
> func(const class a)[/color]
I assume you intend to use a type such as 'int' or 'MyStruct'
instead of 'class'.
[color=blue]
> 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??!![/color]

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.c om/groups?selm=3c6 472fa%241%40new s.swissonline.c h
[color=blue]
> now, what about we do
> func(const class& a) or[/color]

'a' is passed by reference -- and the const protects it from
being changed.
[color=blue]
> func(const class* a)
> then, in either case, is a begin protected? or a pointer that points to a?[/color]

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, Dr. med. <> http://www.post1.com/~ivec
Brainbench MVP for C++ <> http://www.brainbench.com

[John Harrison]

Re: const in argument


"Ivan Vecerina" <ivecATmyrealbo xDOTcom> wrote in message
news:3f3623ea$1 @news.swissonli ne.ch...[color=blue]
> "Matthew Monopole" <mathfield@hotm ail.com> wrote in message
> news:10pZa.4946 $M6.362893@news read1.prod.itd. earthlink.net.. .[color=green]
> > Is there a reason why would one prefer friend over[/color]
> class1obj.opera tor+(const[color=green]
> > class2&)? I used to thought it was for commutivity between classes, for
> > example, when we want class1obj+class 2obj=class2obj+ class1obj, but this
> > turns out to be not true. I still have to overload the operator twice[/color][/color]
with[color=blue][color=green]
> > the argument order reversed....[/color]
>
> NB: What does this have to do with the topic of this thread (const usage)[/color]
?[color=blue]
>
> The point of using 'friend' is that it allows implicit conversions on
> both sides of the operator.[/color]

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

[Ivan Vecerina]

Re: const in argument

"Matthew Monopole" <mathfield@hotm ail.com> wrote in message
news:10pZa.4946 $M6.362893@news read1.prod.itd. earthlink.net.. .[color=blue]
> Is there a reason why would one prefer friend over[/color]
class1obj.opera tor+(const[color=blue]
> class2&)? I used to thought it was for commutivity between classes, for
> example, when we want class1obj+class 2obj=class2obj+ class1obj, but this
> turns out to be not true. I still have to overload the operator twice with
> the argument order reversed....[/color]

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
}
[color=blue]
> 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[/color]
copying[color=blue]
> the object?[/color]

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


hth
--
Ivan Vecerina, Dr. med. <> http://www.post1.com/~ivec
Brainbench MVP for C++ <> http://www.brainbench.com

[Rolf Magnus]

Re: const in argument

Matthew Monopole wrote:
[color=blue]
> I read somewhere that when overloading operator, it is best to use
> friend and declare like this:
> friend operator+(const class1&, const class2&);[/color]

Only make it a friend if it really needs to access private members.
[color=blue]
> Is there a reason why would one prefer friend over
> class1obj.opera tor+(const class2&)? I used to thought it was for
> commutivity between classes, for example, when we want
> class1obj+class 2obj=class2obj+ class1obj, but this turns out to be not
> true. I still have to overload the operator twice with the argument
> order reversed....[/color]

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.
[color=blue]
> 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?[/color]

Yes.

[John Harrison]

Re: const in argument


"Ivan Vecerina" <ivecATmyrealbo xDOTcom> wrote in message
news:3f3623ea$1 @news.swissonli ne.ch...[color=blue]
> "Matthew Monopole" <mathfield@hotm ail.com> wrote in message
> news:10pZa.4946 $M6.362893@news read1.prod.itd. earthlink.net.. .[color=green]
> > Is there a reason why would one prefer friend over[/color]
> class1obj.opera tor+(const[color=green]
> > class2&)? I used to thought it was for commutivity between classes, for
> > example, when we want class1obj+class 2obj=class2obj+ class1obj, but this
> > turns out to be not true. I still have to overload the operator twice[/color][/color]
with[color=blue][color=green]
> > the argument order reversed....[/color]
>
> NB: What does this have to do with the topic of this thread (const usage)[/color]
?[color=blue]
>
> The point of using 'friend' is that it allows implicit conversions on
> both sides of the operator.[/color]

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]

Re: const in argument

Matthew Monopole wrote:
[color=blue]
> I read somewhere that when overloading operator, it is best to use
> friend and declare like this:
> friend operator+(const class1&, const class2&);[/color]

Only make it a friend if it really needs to access private members.
[color=blue]
> Is there a reason why would one prefer friend over
> class1obj.opera tor+(const class2&)? I used to thought it was for
> commutivity between classes, for example, when we want
> class1obj+class 2obj=class2obj+ class1obj, but this turns out to be not
> true. I still have to overload the operator twice with the argument
> order reversed....[/color]

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.
[color=blue]
> 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?[/color]

Yes.