470,841 Members | 1,050 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,841 developers. It's quick & easy.

Silly returning-an-object question

Hi,

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}
oogie_boogie() returns a reference to a Foo object, right? (so, when I
call oogie_boogie(), only one Foo object is created?)

Thanks,
Joe
May 15 '06 #1
13 1169
Joe Van Dyk wrote:
Hi,

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}
oogie_boogie() returns a reference to a Foo object, right? (so, when I
call oogie_boogie(), only one Foo object is created?)

It returns an instance of a Foo, not a reference.

The compiler will probably optimise away the extra copy.

--
Ian Collins.
May 15 '06 #2
Joe Van Dyk <jo********@boeing.com> wrote:
Hi,

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}
oogie_boogie() returns a reference to a Foo object, right?
No, it returns a Foo. If you wanted it to return a reference, you
would have had to declare the function:

Foo& oggie_boogie();
(so, when I call oogie_boogie(), only one Foo object is created?)


In theory, the "Foo a;" line will construct a Foo, and then the
"return a;" will copy-construct another Foo. In practice, almost any
compiler will optimize away the extra copy-construct and just create
the one object.
May 15 '06 #3

Roy Smith wrote:
Joe Van Dyk <jo********@boeing.com> wrote:
Hi,

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}
oogie_boogie() returns a reference to a Foo object, right?


No, it returns a Foo. If you wanted it to return a reference, you
would have had to declare the function:

Foo& oggie_boogie();


But of course we would never want to return a reference to a temporary,
would we? ;)

May 16 '06 #4
In article <11**********************@v46g2000cwv.googlegroups .com>,
in*************@gmail.com wrote:
Roy Smith wrote:
Joe Van Dyk <jo********@boeing.com> wrote:
Hi,

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}
oogie_boogie() returns a reference to a Foo object, right?


No, it returns a Foo. If you wanted it to return a reference, you
would have had to declare the function:

Foo& oggie_boogie();


But of course we would never want to return a reference to a temporary,
would we? ;)


It depends. We might want to be testing our memory corruption detection
system :-)
May 16 '06 #5
Ian Collins wrote:
Joe Van Dyk wrote:
Hi,

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}
oogie_boogie() returns a reference to a Foo object, right? (so, when I
call oogie_boogie(), only one Foo object is created?)


It returns an instance of a Foo, not a reference.

The compiler will probably optimise away the extra copy.


Ah, ok. That optimization is probably why I was thinking that a
reference was being returned.

If oogie_boogie() returned a reference to a Foo object, then would
Foo &f(oogie_boogie());
be ok?

Joe
May 16 '06 #6
In article <Iz********@news.boeing.com>,
Joe Van Dyk <jo********@boeing.com> wrote:
Ian Collins wrote:
Joe Van Dyk wrote:
Hi,

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}
oogie_boogie() returns a reference to a Foo object, right? (so, when I
call oogie_boogie(), only one Foo object is created?)


It returns an instance of a Foo, not a reference.

The compiler will probably optimise away the extra copy.


Ah, ok. That optimization is probably why I was thinking that a
reference was being returned.

If oogie_boogie() returned a reference to a Foo object, then would
Foo &f(oogie_boogie());
be ok?

Joe


OK for what? I'm not sure what you're trying to do here.
May 16 '06 #7
Joe Van Dyk wrote:
Ian Collins wrote:
Joe Van Dyk wrote:

struct Foo {};

Foo oogie_boogie()
{
Foo a;
return a;
}


If oogie_boogie() returned a reference to a Foo object, then would
Foo &f(oogie_boogie());
be ok?


It would compile correctly. But in order to run correctly you
would have to ensure that the returned object still existed
when you try and use 'f' (which is not the case in the above
version of oogie_boogie).

May 16 '06 #8
in*************@gmail.com wrote:
But of course we would never want to return a reference to a temporary,
would we? ;)


It's not a temporary, just a reference to an object whose lifetime
has ended.
May 21 '06 #9
Ron Natalie wrote:
in*************@gmail.com wrote:
But of course we would never want to return a reference to a temporary,
would we? ;)


It's not a temporary, just a reference to an object whose lifetime
has ended.

You have just now defined temporary -)-)
May 21 '06 #10
Sjouke Burry wrote:
Ron Natalie wrote:
in*************@gmail.com wrote:
But of course we would never want to return a reference to a
temporary, would we? ;)


It's not a temporary, just a reference to an object whose lifetime
has ended.

You have just now defined temporary -)-)


There has to be some difference between temporary and expired...
May 21 '06 #11
Sjouke Burry wrote:
Ron Natalie wrote:
in*************@gmail.com wrote:
But of course we would never want to return a reference to a temporary,
would we? ;)


It's not a temporary, just a reference to an object whose lifetime
has ended.

You have just now defined temporary -)-)


No, I haven't. A temporary object has a precise meaning in C++
which does not include automatic variables. No object in C++
has an infinite lifetime. It behooves you to understand this
and when you can use them.
May 22 '06 #12
Ron Natalie wrote:
Sjouke Burry wrote:
Ron Natalie wrote:
in*************@gmail.com wrote:

But of course we would never want to return a reference to a temporary,
would we? ;)
It's not a temporary, just a reference to an object whose lifetime
has ended.


You have just now defined temporary -)-)

No, I haven't. A temporary object has a precise meaning in C++
which does not include automatic variables. No object in C++
has an infinite lifetime. It behooves you to understand this
and when you can use them.

You can choose whatever name you want for an
object which just has died(gone out of scope,
or whatever),as long as you dont use it ,reference
it or treat it as if it still existed.
If you dont call that a temporary existence,
you are welcome to any other definition,just as
long at it means the same.
I have seen to many applications just sort of
working because the reference seemed still to be
valid,depending on what you (or your interrupt
software)did.
May 22 '06 #13
Sjouke Burry wrote:
Ron Natalie wrote:
Sjouke Burry wrote:
Ron Natalie wrote:
It's not a temporary, just a reference to an object whose lifetime
has ended.

You have just now defined temporary -)-)
No, I haven't. A temporary object has a precise meaning in C++
which does not include automatic variables. No object in C++
has an infinite lifetime. It behooves you to understand this
and when you can use them.


You can choose whatever name you want for an
object which just has died(gone out of scope,
or whatever),as long as you dont use it ,reference
it or treat it as if it still existed.
If you dont call that a temporary existence,
you are welcome to any other definition,just as
long at it means the same.


Sjouke, you're not going to get very far (except into pointless
arguments) by picking fights over terminology, especially when the C++
standard is on one side and you are on the other. The sort of
reasoning you just gave could be used to justify introducing
pointlessly confusing alternate definitions of technical terms which
already possess clear and unambiguous meanings. For example, I could
rationalize using the term "public" to describe private member
functions in code that exists in the public domain, but it would be
perverse and misleading to do so.

The standard specifies different behavior for temporaries, distinct
from other kinds of variables. Obfuscatory and misleading language
based on what you *want* the word to mean only serves to obscure this
distinction, which is a disservice to all.
I have seen to many applications just sort of
working because the reference seemed still to be
valid,depending on what you (or your interrupt
software)did.


Nobody's advocating using objects which no longer exist. A thorough
understanding of object lifetime rules and their implications is
crucial to writing good C++, as is clear use of the proper terminology
so you can communicate with your peers and continue to advance your
knowledge.

Luke

May 23 '06 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Salve Håkedal | last post: by
1 post views Thread by Bkr | last post: by
6 posts views Thread by Generic Usenet Account | last post: by
10 posts views Thread by randomtalk | last post: by
6 posts views Thread by EvilOldGit | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.