Connecting Tech Pros Worldwide Forums | Help | Site Map

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

Guest
 
Posts: n/a
#1: Jan 26 '06
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
Guest
 
Posts: n/a
#2: Jan 26 '06

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


dontspam@_dylan_.gov wrote:[color=blue]
> 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!) ?
>
>[/color]

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);
[color=blue]
> 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! ;-)
>
>
>[/color]
Shark
Guest
 
Posts: n/a
#3: Jan 26 '06

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


Mark P wrote:[color=blue]
> dontspam@_dylan_.gov wrote:[color=green]
> > 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!) ?
> >
> >[/color]
>
> 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);
>[color=green]
> > 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! ;-)[/color][/color]

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
Guest
 
Posts: n/a
#4: Jan 26 '06

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


Shark wrote:
[color=blue]
>
> 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.[/color]

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
Guest
 
Posts: n/a
#5: Jan 26 '06

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


dontspam@_dylan_.gov wrote:
[color=blue]
> 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!) ?[/color]

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.
[color=blue]
> 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! ;-)[/color]

Yes, it is ;-)

Marcus Kwok
Guest
 
Posts: n/a
#6: Jan 26 '06

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


Mark P <fall2005@removefall2005.capsfastmail.fm> wrote:[color=blue]
> dontspam@_dylan_.gov wrote:[color=green]
>> 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!) ?[/color]
>
> 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.[/color]

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
Guest
 
Posts: n/a
#7: Jan 26 '06

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


On Thu, 26 Jan 2006 14:46:03 +0000 (UTC), ricecake@gehennom.net
(Marcus Kwok) wrote:[color=blue]
>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[/color]
<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
Guest
 
Posts: n/a
#8: Jan 26 '06

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


Marcus Kwok wrote:[color=blue]
> Mark P <fall2005@removefall2005.capsfastmail.fm> wrote:
>[color=green]
>>dontspam@_dylan_.gov wrote:
>>[color=darkred]
>>>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!) ?[/color]
>>
>>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.[/color]
>
>
> 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
>[/color]

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
Guest
 
Posts: n/a
#9: Jan 26 '06

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



"Rolf Magnus" <ramagnus@t-online.de> skrev i meddelandet
news:drai6e$elm$01$1@news.t-online.com...[color=blue]
> dontspam@_dylan_.gov wrote:
>[color=green]
>> 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!) ?[/color]
>
> 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.[/color]

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


Bo Persson


David Harmon
Guest
 
Posts: n/a
#10: Jan 27 '06

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


On Thu, 26 Jan 2006 08:12:14 -0500 in comp.lang.c++, Pete Becker
<petebecker@acm.org> wrote,[color=blue]
>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.[/color]

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

Closed Thread