need help on coding grammar about reference / pointer /instance.

[key9]

Hi All

On coding , I think I need some basic help about how to write member
function .

I've readed the FAQ, but I am still confuse about it when coding(reference /
pointer /instance) , so I think I need some "template".
Sorry for my coding experience in c++

Suppose we have

class FooClass{

public:

/*
foo() // this is what I want to ask below
*/

private:
string str;
}
What I need "template" is:

1. Use a outside string (string*,string&) to replace string content in class
string* outp;
string outi;
string& outr;
how to write these three foo()?
2. 1 outside will get string content inside of class, but outside can not
change it, (return a copy/return const pointer)
2. 2 outside will get string content inside of class, but outside can change
it, (return a point/reference)

3. outside can get string which have processed in foo()
string* foo(){
string* temp;
temp = processof(str);
return temp*
}
how to use autoptr to void mem leak? if I forgot delete temp* outside?
your help will save my life:-)

key9

keep trying ......

[Erik Wikström]

On 2006-05-27 10:06, key9 wrote:

Hi All

On coding , I think I need some basic help about how to write member
function .

I've readed the FAQ, but I am still confuse about it when coding(reference /
pointer /instance) , so I think I need some "template".
Sorry for my coding experience in c++
You should be careful when talking about templates in here since there
is something called templates in C++, but it's not what you want.
Suppose we have

class FooClass{

public:

/*
foo() // this is what I want to ask below
*/

private:
string str;
}
What I need "template" is:

1. Use a outside string (string*,string&) to replace string content in class
string* outp;
string outi;
string& outr;
how to write these three foo()?
If I understand you correctly what you are asking for is something lika
this:

// Using a pointer
FooClass::foo(string* s)
{
srt = *s;
}

// Using a reference
FooClass::foo(string& s)
{
str = s;
}

// Using a copy
FooClass::foo(string s)
{
str = s;
}

Whenever possible it is preferable to use a reference instead of a
pointer, and often instead of using a copy too.
2. 1 outside will get string content inside of class, but outside can not
change it, (return a copy/return const pointer)
2. 2 outside will get string content inside of class, but outside can change
it, (return a point/reference)

3. outside can get string which have processed in foo()
string* foo(){
string* temp;
temp = processof(str);
return temp*
}
how to use autoptr to void mem leak? if I forgot delete temp* outside?

Supposing str already has some value it can be returned like this:

// Using a pointer
string* FooClass::foo2()
{
return &str;
}

// Using a reference
string& FooClass::foo2()
{
return str;
}

// Using a copy
string FooClass::foo2()
{
return str;
}

When returning a pointer or reference the user can later change the vlue
of str without calling foo() since it can manipulate the pointer/
reference directly, thus it's often a good idea to return a copy (unless
you want this behaviour).

Notice also that you should never return a pointer or reference to a
object declared inside the function returning it since the object will
no exist after the function has returned but the pointer/reference will
still point to it.

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

[Steve Pope]

Erik Wikström <Er***********@telia.com> wrote:

If I understand you correctly what you are asking for is something lika
this:

// Using a pointer
FooClass::foo(string* s)
{
srt = *s;
}

// Using a reference
FooClass::foo(string& s)
{
str = s;
}

// Using a copy
FooClass::foo(string s)
{
str = s;
} Whenever possible it is preferable to use a reference instead of a
pointer, and often instead of using a copy too.

Okay, this is a point of C++ style I don't understand. (One of
many, I expect.) Why would one use a reference argument to a
function, unless one wanted the function to modify the referent?
I frequently see this in people's code. Is a copy argument
less efficient? (Seems unlikely to me.)

thanks,

Steve

[Jonathan Mcdougall]

Steve Pope wrote:

Okay, this is a point of C++ style I don't understand. (One of
many, I expect.) Why would one use a reference argument to a
function, unless one wanted the function to modify the referent?
I frequently see this in people's code. Is a copy argument
less efficient? (Seems unlikely to me.)

The rule is: don't copy when you don't have to. Most of the times,
you'll want to pass objects by const reference.
Jonathan

[Erik Wikström]

On 2006-05-27 19:19, Steve Pope wrote:

Erik Wikström <Er***********@telia.com> wrote:

If I understand you correctly what you are asking for is something lika
this:

// Using a pointer
FooClass::foo(string* s)
{
srt = *s;
}

// Using a reference
FooClass::foo(string& s)
{
str = s;
}

// Using a copy
FooClass::foo(string s)
{
str = s;
}

Whenever possible it is preferable to use a reference instead of a
pointer, and often instead of using a copy too.

Okay, this is a point of C++ style I don't understand. (One of
many, I expect.) Why would one use a reference argument to a
function, unless one wanted the function to modify the referent?
I frequently see this in people's code. Is a copy argument
less efficient? (Seems unlikely to me.)

A copy can be very inefficient if the object passed is large, in that
case it's better to pass a const reference, since you then don't have to
copy the object. Imagine for example passing a collection (vector, list
etc.) as a copy, with many objects in the collection the operation will
be very slow compared with a reference.

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

[Steve Pope]

Erik Wikström <Er***********@telia.com> wrote:

Steve Pope wrote:

Okay, this is a point of C++ style I don't understand. (One of
many, I expect.) Why would one use a reference argument to a
function, unless one wanted the function to modify the referent?
I frequently see this in people's code. Is a copy argument
less efficient? (Seems unlikely to me.)

A copy can be very inefficient if the object passed is large,
in that case it's better to pass a const reference, since you
then don't have to copy the object. Imagine for example passing
a collection (vector, list etc.) as a copy, with many objects
in the collection the operation will be very slow compared with
a reference.

But surely for arguments that are not scalars, only a pointer
gets passed even if it is not a reference argument. I cannot
picture the compiler pushing a copy of a huge object onto the
stack. This is why I say it is unlikely to be less efficient.

Steve

[Erik Wikström]

On 2006-05-27 20:32, Steve Pope wrote:

Erik Wikström <Er***********@telia.com> wrote:

Steve Pope wrote:

Okay, this is a point of C++ style I don't understand. (One of
many, I expect.) Why would one use a reference argument to a
function, unless one wanted the function to modify the referent?
I frequently see this in people's code. Is a copy argument
less efficient? (Seems unlikely to me.)

A copy can be very inefficient if the object passed is large,
in that case it's better to pass a const reference, since you
then don't have to copy the object. Imagine for example passing
a collection (vector, list etc.) as a copy, with many objects
in the collection the operation will be very slow compared with
a reference.

But surely for arguments that are not scalars, only a pointer
gets passed even if it is not a reference argument. I cannot
picture the compiler pushing a copy of a huge object onto the
stack. This is why I say it is unlikely to be less efficient.

That's the power of C++, it lets you decide how to handle things, if you
pass a copy and make changes to it it is guaranteed that those changes
will not apply to the object you made a copy of. So even if the compiler
should optimize so that just a pointer/reference is passed it will still
have to make a copy.

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

[Steve Pope]

Erik Wikström <Er***********@telia.com> wrote:

On 2006-05-27 20:32, Steve Pope wrote:

But surely for arguments that are not scalars, only a pointer
gets passed even if it is not a reference argument. I cannot
picture the compiler pushing a copy of a huge object onto the
stack. This is why I say it is unlikely to be less efficient.

That's the power of C++, it lets you decide how to handle things, if you
pass a copy and make changes to it it is guaranteed that those changes
will not apply to the object you made a copy of. So even if the compiler
should optimize so that just a pointer/reference is passed it will still
have to make a copy.

Yes, I agree. I suppose the compiler could deal with this by
only creating the copy if the argument is either is used as a lhs, or
has its address taken within the function.

In any case I think you've explained the programming practice of
using reference arguments and then not modifying them. Thanks.

Steve

[Jonathan Mcdougall]

Steve Pope wrote:

Erik Wikström <Er***********@telia.com> wrote:

On 2006-05-27 20:32, Steve Pope wrote:

But surely for arguments that are not scalars, only a pointer
gets passed even if it is not a reference argument. I cannot
picture the compiler pushing a copy of a huge object onto the
stack. This is why I say it is unlikely to be less efficient.

That's the power of C++, it lets you decide how to handle things, if you
pass a copy and make changes to it it is guaranteed that those changes
will not apply to the object you made a copy of. So even if the compiler
should optimize so that just a pointer/reference is passed it will still
have to make a copy.

Yes, I agree. I suppose the compiler could deal with this by
only creating the copy if the argument is either is used as a lhs, or
has its address taken within the function.

No, it cannot do that. An optimizer could discard unused parameters in
some circumstances, but usually the compiler cannot (and should not)
assume the side effects of copying an object are trivial. When you pass
arguments by value, you must assume they will always be copied.
Jonathan

[Phlip]

Jonathan Mcdougall wrote:

No, it cannot do that. An optimizer could discard unused parameters in
some circumstances, but usually the compiler cannot (and should not)
assume the side effects of copying an object are trivial. When you pass
arguments by value, you must assume they will always be copied.

I thought "return value optimization" applied there.

Even if it doesn't, side-effects in copy methods are Bad Things, anyway...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!l

[Steve Pope]

Jonathan Mcdougall <jo***************@gmail.com> wrote:

Steve Pope wrote:

Yes, I agree. I suppose the compiler could deal with this by
only creating the copy if the argument is either is used as a lhs, or
has its address taken within the function.

No, it cannot do that.

Sure it can. By textual analysis, a compiler could rule out
some such instances.

Steve

[Jonathan Mcdougall]

Steve Pope wrote:

Jonathan Mcdougall <jo***************@gmail.com> wrote:

Steve Pope wrote:

Yes, I agree. I suppose the compiler could deal with this by
only creating the copy if the argument is either is used as a lhs, or
has its address taken within the function.

No, it cannot do that.

Sure it can. By textual analysis, a compiler could rule out
some such instances.

Would you care to provide an example where "textual analysis" could
allow a compiler to do something else than copying an argument passed
by value?
Jonathan

[kwikius]

Phlip wrote:

Jonathan Mcdougall wrote:

No, it cannot do that. An optimizer could discard unused parameters in
some circumstances, but usually the compiler cannot (and should not)
assume the side effects of copying an object are trivial. When you pass
arguments by value, you must assume they will always be copied.

I thought "return value optimization" applied there.

Return value optimisation refers to the case when the return is by
value, whereas the return of an input argument can only logically be by
reference.

regards
Andy Little

[Steve Pope]

Jonathan Mcdougall <jo***************@gmail.com> wrote:

Steve Pope wrote:

Jonathan Mcdougall <jo***************@gmail.com> wrote:

>Steve Pope wrote:

>> the compiler could deal with this by
>>only creating the copy if the argument is either is used as a
>>lhs, or has its address taken within the function. >No, it cannot do that.

Sure it can. By textual analysis, a compiler could rule out
some such instances.

Would you care to provide an example where "textual analysis" could
allow a compiler to do something else than copying an argument passed
by value?

Geez.
int func(std::vector<double> x, int a) {
std::printf("%f\n",x[0]);
return(2*a);
}

S.

[Jonathan Mcdougall]

Steve Pope wrote:

Jonathan Mcdougall <jo***************@gmail.com> wrote:

Steve Pope wrote:

Jonathan Mcdougall <jo***************@gmail.com> wrote:Steve Pope wrote:

>> the compiler could deal with this by
>>only creating the copy if the argument is either is used as a
>>lhs, or has its address taken within the function.No, it cannot do that. Sure it can. By textual analysis, a compiler could rule out
some such instances.

Would you care to provide an example where "textual analysis" could
allow a compiler to do something else than copying an argument passed
by value?

Geez.

int func(std::vector<double> x, int a) {
std::printf("%f\n",x[0]);
return(2*a);
}

I don't understand exactly. Can the vector be passed by something else
than by value here? If so, why? You may answer "because we know we're
not modifying x", but the compiler has no way to know that. A non-const
operator[] is called on the vector and it returns a non-const
reference.

What's more, replace std::vector<double> by T and all bets are off.
Jonathan