468,505 Members | 2,006 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

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

return reference to local variable, good code?

Hello everyone,
I am reading some code from other people, there are some code like
this,

Expand|Select|Wrap|Line Numbers
  1. class Foo {
  2.  
  3. };
  4.  
  5. Foo& func()
  6. {
  7. Foo foo;
  8. return foo;
  9. }
  10.  
  11. int main()
  12. {
  13. Foo& foo = func();
  14.  
  15. return 0;
  16. }
  17.  
I want to confirm with you that it is not good code, since we return a
reference to local object instance, right? Even if the code has
expected function currently.
thanks in advance,
George
Dec 16 '07 #1
7 3722
On 12月16日, 下午1时49分, George2 <george4acade...@yahoo.comwrote:
Hello everyone,

I am reading some code from other people, there are some code like
this,

Expand|Select|Wrap|Line Numbers
  1. class Foo {
  2. };
  3. Foo& func()
  4. {
  5.         Foo foo;
  6.         return foo;
  7. }
  8. int main()
  9. {
  10.         Foo& foo = func();
  11.         return 0;}
  12.  

I want to confirm with you that it is not good code, since we return a
reference to local object instance, right? Even if the code has
expected function currently.

thanks in advance,
George
I'm afraid this code can not be compiled. To return a reference of
local non-static object is not allowed.
Dec 16 '07 #2
Alf P. Steinbach wrote:
And I'm sorry this is EXTREMELY OFF-TOPIC, but perhaps someone knows how
this can be?

It seems the connection problems are protocol-dependent.

Although I can't read my mail (GMail), I can read the New York Times,
but pinging that server fails:
Is your PC infected by windows ??

--
Ian Collins.
Dec 16 '07 #3
On Dec 16, 7:11 am, "Alf P. Steinbach" <al...@start.nowrote:
* yanlinlin:
On 12鏈16鏃, 涓嬪崍1鏃49鍒, George2 <george4acade...@yahoo.comwrote:
I am reading some code from other people, there are some code like
this,
Expand|Select|Wrap|Line Numbers
  1. class Foo {
  2. };
Expand|Select|Wrap|Line Numbers
  1.         
  2.                         
  3.                 Foo& func()
  4. {
  5.         Foo foo;
  6.         return foo;
  7. }
  •  
  •         
  •                         
  •                 int main()
  • {
  •         Foo& foo = func();
  •         return 0;}
  •  
  •  
  • I want to confirm with you that it is not good code, since
    we return a reference to local object instance, right? Even
    if the code has expected function currently.
    I'm afraid this code can not be compiled. To return a
    reference of local non-static object is not allowed.
    It's allowed and it should compile.
    A compiler that doesn't allow it is non-conforming.
    However, using that result incurs Undefined Behavior.
    I think that if the compiler can prouve that the result is used
    (and it is here), then it is allowed to reject the code. (The
    case here is an interesting one, in fact---I'm assuming that the
    same rules hold for references as for pointers, and that even
    copying an invalid reference is undefined behavior. I've not
    looked it up, however, so caveat empor.)
    PS: Could you, or anyone, confirm whether you see this
    posting? If you don't see it, simply do nothing.
    I've seen it. (Rather obviously.) I even figured out something
    on-topic to add so that I wouldn't be off topic in
    responding:-).

    --
    James Kanze (GABI Software) email:ja*********@gmail.com
    Conseils en informatique orient茅e objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place S茅mard, 78210 St.-Cyr-l'脡cole, France, +33 (0)1 30 23 00 34
    Dec 16 '07 #4
    It's allowed and it should compile.
    >
    A compiler that doesn't allow it is non-conforming.

    However, using that result incurs Undefined Behavior.

    Cheers, & hth.,

    - Alf
    Yes, I misunderstood that.
    It can compile successfully, but with a warning. And the option "treat
    warning as error" misguided me about it. :P
    Dec 16 '07 #5
    On Dec 16, 13:39, James Kanze <james.ka...@gmail.comwrote:
    On Dec 16, 7:11 am, "Alf P. Steinbach" <al...@start.nowrote:
    * yanlinlin:
    On 12月16日, 下午1时49分, George2 <george4acade...@yahoo.comwrote:
    >I am reading some code from other people, there are some code like
    >this,
    >
    Expand|Select|Wrap|Line Numbers
    1.  >class Foo {
    2.  >};
    Expand|Select|Wrap|Line Numbers
    1.         
    2.                         
    3.                  >Foo& func()
    4.  >{
    5.  >        Foo foo;
    6.  >        return foo;
    7.  >}
  •  
  •         
  •                         
  •                  >int main()
  •  >{
  •  >        Foo& foo = func();
  •  >        return 0;}
  •  >
  •  
  •  
  • >I want to confirm with you that it is not good code, since
    >we return a reference to local object instance, right? Even
    >if the code has expected function currently.
    I'm afraid this code can not be compiled. To return a
    reference of local non-static object is not allowed.
    It's allowed and it should compile.
    A compiler that doesn't allow it is non-conforming.
    However, using that result incurs Undefined Behavior.

    I think that if the compiler can prouve that the result is used
    (and it is here), then it is allowed to reject the code. (The
    case here is an interesting one, in fact---I'm assuming that the
    same rules hold for references as for pointers, and that even
    copying an invalid reference is undefined behavior. I've not
    looked it up, however, so caveat empor.)

    How can compiler prove that the result is used? How can he prove i'm
    not writing a thread that's supposed to be externally terminated in
    the very same case as when the function happens to return a reference-
    to-local, the reference later explicitely being used but unreachable
    in practice? :-)
    Dec 17 '07 #6
    On 16 Dec, 06:09, "Alf P. Steinbach" <al...@start.nowrote:
    * George2:


    Hello everyone,
    I am reading some code from other people, there are some code like
    this,
    Expand|Select|Wrap|Line Numbers
    1.  class Foo {
    Expand|Select|Wrap|Line Numbers
    1.         
    2.                  };
  •  
  •         
  •                  Foo& func()
  •  {
  •     Foo foo;
  •     return foo;
  •  }
  •  
  •         
  •                  int main()
  •  {
  •     Foo& foo = func();
  •  
  •         
  •                     return 0;
  •  }
  •  
  •  
  • I want to confirm with you that it is not good code, since we return a
    reference to local object instance, right? Even if the code has
    expected function currently.

    It's Undefined Behavior if the function result is ever used.

    Btw., could you or anyone else please confirm that you can see this posting.

    It seems that all internet connections out of Norway are down at the
    moment, at least via my ISP (e.g. I can't reach Microsoft's servers, nor
    Google), yet articles keep dropping in in international newsgroups.

    Of course, if you don't see this posting, simply don't respond.
    i can c u. uk
    Dec 17 '07 #7
    On Dec 17, 11:56 am, Pavel Shved <Pavel.Sh...@gmail.comwrote:
    On Dec 16, 13:39, James Kanze <james.ka...@gmail.comwrote:
    On Dec 16, 7:11 am, "Alf P. Steinbach" <al...@start.nowrote:
    * yanlinlin:
    On 12鏈16鏃, 涓嬪崍1鏃49鍒, George2 <george4acade...@yahoo.comwrote:
    I am reading some code from other people, there are some code like
    this,
    Expand|Select|Wrap|Line Numbers
    1.  class Foo {
    2.  };
    Expand|Select|Wrap|Line Numbers
    1.  
    2.         
    3.                         
    4.                         
    5.                  Foo& func()
    6.  {
    7.          Foo foo;
    8.          return foo;
    9.  }
    10.  
    11.  
    12.         
    13.                         
    14.                         
    15.                  int main()
    16.  {
    17.          Foo& foo = func();
    18.          return 0;}
    19.  
    20.  
    I want to confirm with you that it is not good code, since
    we return a reference to local object instance, right? Even
    if the code has expected function currently.
    I'm afraid this code can not be compiled. To return a
    reference of local non-static object is not allowed.
    It's allowed and it should compile.
    A compiler that doesn't allow it is non-conforming.
    However, using that result incurs Undefined Behavior.
    I think that if the compiler can prouve that the result is
    used (and it is here), then it is allowed to reject the
    code. (The case here is an interesting one, in fact---I'm
    assuming that the same rules hold for references as for
    pointers, and that even copying an invalid reference is
    undefined behavior. I've not looked it up, however, so
    caveat empor.)
    How can compiler prove that the result is used?
    By flow analysis.
    How can he prove i'm not writing a thread that's supposed to
    be externally terminated in the very same case as when the
    function happens to return a reference- to-local, the
    reference later explicitely being used but unreachable in
    practice? :-)
    That's undefined behavior as well, as far as the standard goes,
    so the compiler doesn't have to take it into account. (In fact,
    of course, it's also impossible to do on most modern systems;
    another process can't really look at the individual instructions
    you're executing.)

    --
    James Kanze (GABI Software) email:ja*********@gmail.com
    Conseils en informatique orient茅e objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place S茅mard, 78210 St.-Cyr-l'脡cole, France, +33 (0)1 30 23 00 34

    Dec 17 '07 #8

    This discussion thread is closed

    Replies have been disabled for this discussion.

    Similar topics

    2 posts views Thread by Kench | last post: by
    25 posts views Thread by cppaddict | last post: by
    14 posts views Thread by Gama Franco | last post: by
    23 posts views Thread by Nascimento | last post: by
    2 posts views Thread by zheng4t | last post: by
    275 posts views Thread by Astley Le Jasper | last post: by
    3 posts views Thread by gieforce | last post: by
    reply views Thread by fmendoza | last post: by
    By using this site, you agree to our Privacy Policy and Terms of Use.