Passing by reference... is it safe in this case?

Hi, quick question:

I have a function which takes a reference to an object as an argument.

void foo( vect3 & v );

This works fine:
vect3 v1(0.0, 0.0, 0.0);
foo(v1);

This also works fine, in VC++ .NET:
foo(vect3(0.0, 0.0, 0.0))

g++ has a fit with the second one though. I can see why it might, since the vect3() constructed object won't last very long. But my question is, does the C++ standard state somewhere that the object will last long enough for the function to evaluate it (by referencing it!) ?
Thanks!

P.S. I've posted here a lot in the past, and as far as I can remember, every post, someone has pointed out that's my post belongs in another group. I think this question is finally on-topic! ;-)

[Mark P]

dontspam@_dylan_.gov wrote:

Hi, quick question:

I have a function which takes a reference to an object as an argument.

void foo( vect3 & v );

This works fine:
vect3 v1(0.0, 0.0, 0.0);
foo(v1);

This also works fine, in VC++ .NET:
foo(vect3(0.0, 0.0, 0.0))

g++ has a fit with the second one though. I can see why it might, since the vect3() constructed object won't last very long. But my question is, does the C++ standard state somewhere that the object will last long enough for the function to evaluate it (by referencing it!) ?


g++ is correct in identifying this as an error. Had you declared foo
instead as:

void foo (vect3& const v);

then this would be permissible.

Likewise you could pass by value rather than by reference:

void foo (vect3 v);
Thanks!

P.S. I've posted here a lot in the past, and as far as I can remember, every post, someone has pointed out that's my post belongs in another group. I think this question is finally on-topic! ;-)

[Shark]

Mark P wrote:

dontspam@_dylan_.gov wrote:

Hi, quick question:

I have a function which takes a reference to an object as an argument.

void foo( vect3 & v );

This works fine:
vect3 v1(0.0, 0.0, 0.0);
foo(v1);

This also works fine, in VC++ .NET:
foo(vect3(0.0, 0.0, 0.0))

g++ has a fit with the second one though. I can see why it might, since the vect3() constructed object won't last very long. But my question is, does the C++ standard state somewhere that the object will last long enough for the function to evaluate it (by referencing it!) ?

g++ is correct in identifying this as an error. Had you declared foo
instead as:

void foo (vect3& const v);

then this would be permissible.

Likewise you could pass by value rather than by reference:

void foo (vect3 v);

Thanks!

P.S. I've posted here a lot in the past, and as far as I can remember, every post, someone has pointed out that's my post belongs in another group. I think this question is finally on-topic! ;-)

You should not pass temporary objects by reference unless the reference
is a const. Because by the time the code gets to look at the non const
temporary object that was referenced, the temporary object may or may
not exists. This will wipe out your hard drive or cause you to burst
into flames. Demons may also fly out of your nose.

[Pete Becker]

Shark wrote:

You should not pass temporary objects by reference unless the reference
is a const. Because by the time the code gets to look at the non const
temporary object that was referenced, the temporary object may or may
not exists.

The temporary object lasts until the end of the full statement in which
it was created. There is no problem with the lifetime of temporary
objects passed to functions. The issue is that making changes to a
temporary object might not make sense, since it's going to go away very
shortly.

--

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

[Rolf Magnus]

dontspam@_dylan_.gov wrote:

Hi, quick question:

I have a function which takes a reference to an object as an argument.

void foo( vect3 & v );

This works fine:
vect3 v1(0.0, 0.0, 0.0);
foo(v1);

This also works fine, in VC++ .NET:
foo(vect3(0.0, 0.0, 0.0))

g++ has a fit with the second one though. I can see why it might, since
the vect3() constructed object won't last very long. But my question is,
does the C++ standard state somewhere that the object will last long
enough for the function to evaluate it (by referencing it!) ?
Yes, it will. However, the reason why g++ complains is that the C++ standard
says that you can't bind a temporary to a non-const reference.
P.S. I've posted here a lot in the past, and as far as I can remember,
every post, someone has pointed out that's my post belongs in another
group. I think this question is finally on-topic! ;-)

Yes, it is ;-)

[Marcus Kwok]

Mark P <fa******@removefall2005.capsfastmail.fm> wrote:

dontspam@_dylan_.gov wrote:

Hi, quick question:

I have a function which takes a reference to an object as an argument.

void foo( vect3 & v );

This works fine:
vect3 v1(0.0, 0.0, 0.0);
foo(v1);

This also works fine, in VC++ .NET:
foo(vect3(0.0, 0.0, 0.0))

g++ has a fit with the second one though. I can see why it might, since the vect3() constructed object won't last very long. But my question is, does the C++ standard state somewhere that the object will last long enough for the function to evaluate it (by referencing it!) ?

g++ is correct in identifying this as an error. Had you declared foo
instead as:

void foo (vect3& const v);

then this would be permissible.

Actually, this should be

void foo(vect3 const& v);

What you wrote says that v is a const reference to a vect3, which is
nonsense since all references are const. Mine says that v is a
reference to a const vect3.

http://www.parashift.com/c++-faq-lit....html#faq-18.7

--
Marcus Kwok

[JustBoo]

On Thu, 26 Jan 2006 14:46:03 +0000 (UTC), ri******@gehennom.net
(Marcus Kwok) wrote:

What you wrote says that v is a const reference to a vect3, which is
nonsense since all references are const. Mine says that v is a
reference to a const vect3.

http://www.parashift.com/c++-faq-lit....html#faq-18.7

<quote>
[18.7] Does "Fred& const x" make any sense?
No, it is nonsense.
</quote>

Thank you. I'm sitting here reading about non-const references in this
thread and I was befuddled. "Did they change the way references work?"
I thought. I didn't want to look "stoopid" so I didn't respond. I was
going to go look it up and you did that. Thanks again. :-)

"If you go flying back through time, and you see somebody else flying
forward into the future, it's probably best to avoid eye contact."
- Jack Handey

[Mark P]

Marcus Kwok wrote:

Mark P <fa******@removefall2005.capsfastmail.fm> wrote:

dontspam@_dylan_.gov wrote:

Hi, quick question:

I have a function which takes a reference to an object as an argument.

void foo( vect3 & v );

This works fine:
vect3 v1(0.0, 0.0, 0.0);
foo(v1);

This also works fine, in VC++ .NET:
foo(vect3(0.0, 0.0, 0.0))

g++ has a fit with the second one though. I can see why it might, since the vect3() constructed object won't last very long. But my question is, does the C++ standard state somewhere that the object will last long enough for the function to evaluate it (by referencing it!) ?

g++ is correct in identifying this as an error. Had you declared foo
instead as:

void foo (vect3& const v);

then this would be permissible.

Actually, this should be

void foo(vect3 const& v);

What you wrote says that v is a const reference to a vect3, which is
nonsense since all references are const. Mine says that v is a
reference to a const vect3.

http://www.parashift.com/c++-faq-lit....html#faq-18.7

Ah, yes, of course and thank you. I ordinarily write this as (const
vect3& v) but my brain appears to have flickered off last night.

[Bo Persson]

"Rolf Magnus" <ra******@t-online.de> skrev i meddelandet
news:dr*************@news.t-online.com...

dontspam@_dylan_.gov wrote:

Hi, quick question:

I have a function which takes a reference to an object as an
argument.

void foo( vect3 & v );

This works fine:
vect3 v1(0.0, 0.0, 0.0);
foo(v1);

This also works fine, in VC++ .NET:
foo(vect3(0.0, 0.0, 0.0))

g++ has a fit with the second one though. I can see why it might,
since
the vect3() constructed object won't last very long. But my
question is,
does the C++ standard state somewhere that the object will last
long
enough for the function to evaluate it (by referencing it!) ?

Yes, it will. However, the reason why g++ complains is that the C++
standard
says that you can't bind a temporary to a non-const reference.

And so will the other compiler, if you set the switches correctly (/Za
in particular).
Bo Persson

[David Harmon]

On Thu, 26 Jan 2006 08:12:14 -0500 in comp.lang.c++, Pete Becker
<pe********@acm.org> wrote,

The temporary object lasts until the end of the full statement in which
it was created. There is no problem with the lifetime of temporary
objects passed to functions. The issue is that making changes to a
temporary object might not make sense, since it's going to go away very
shortly.

So let us remove from C++ everything else that can be used in a way
that "might not make sense".