I am sorry for this...

Discussion in 'C++' started by Nakor, Jan 31, 2005.

  1. Nakor

    Nakor Guest

    Hello,

    I am a Computer Programmer Analyst student. I am taking this course
    which for this week's assignment requires me to join some newsgroups.
    I am sorry to have to spam you with such useless crap.

    Regardless I am supposed to instigate a response of some sort, so could
    someone please fulfill that requirement for me?

    Thanks,

    Nakor
     
    Nakor, Jan 31, 2005
    #1
    1. Advertising

  2. * Nakor:
    >
    > I am a Computer Programmer Analyst student. I am taking this course
    > which for this week's assignment requires me to join some newsgroups.
    > I am sorry to have to spam you with such useless crap.
    >
    > Regardless I am supposed to instigate a response of some sort, so could
    > someone please fulfill that requirement for me?
    >
    > Thanks,
    >
    > Nakor


    Okay, what's wrong with this function

    std::string const& helloText()
    {
    return "A response";
    }

    ?

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Jan 31, 2005
    #2
    1. Advertising

  3. Nakor

    Nakor Guest

    Thanks for replying. I'm not certain what would be intended by this
    bit of code, but I am willing to guess.

    If you merely wished for the function to pass back a welcome string
    then this would suffice:

    std::string helloText()
    {
    return "A response";
    }

    Other than that I'm not sure what would be the intention :)
     
    Nakor, Jan 31, 2005
    #3
  4. Nakor

    Matthias Guest

    Nakor wrote:

    >
    > Other than that I'm not sure what would be the intention :)
    >


    The point is, returning a reference to a local object can generally be
    called a bad idea :)

    --
    Regards,
    Matthias
     
    Matthias, Jan 31, 2005
    #4
  5. Nakor

    Nakor Guest

    Ah ok! Thanks heh :)
     
    Nakor, Jan 31, 2005
    #5
  6. Matthias wrote:
    > Nakor wrote:
    >
    >>
    >> Other than that I'm not sure what would be the intention :)
    >>

    >
    > The point is, returning a reference to a local object can generally be
    > called a bad idea :)


    I actually thought the function returned a reference to a temporary.
    The problem is not that it's local (and a string literal is not really
    local to anything), the problem is in the lifetime of the temporary.

    V
     
    Victor Bazarov, Jan 31, 2005
    #6
  7. Nakor

    Matthias Guest

    Victor Bazarov wrote:
    > Matthias wrote:
    >
    >> Nakor wrote:
    >>
    >>>
    >>> Other than that I'm not sure what would be the intention :)
    >>>

    >>
    >> The point is, returning a reference to a local object can generally be
    >> called a bad idea :)

    >
    >
    > I actually thought the function returned a reference to a temporary.
    > The problem is not that it's local (and a string literal is not really
    > local to anything), the problem is in the lifetime of the temporary.
    >
    > V


    Yes, the temporary will be deleted upon leaving the scope. So will any
    local object during stack unwinding. So the point stays the same, no? :)

    --
    Regards,
    Matthias
     
    Matthias, Jan 31, 2005
    #7
  8. "Victor Bazarov" <> wrote in message
    news:SwvLd.40543$01.us.to.verio.net...
    > Matthias wrote:
    >> Nakor wrote:
    >>
    >>>
    >>> Other than that I'm not sure what would be the intention :)
    >>>

    >>
    >> The point is, returning a reference to a local object can generally be
    >> called a bad idea :)

    >
    > I actually thought the function returned a reference to a temporary.
    > The problem is not that it's local (and a string literal is not really
    > local to anything), the problem is in the lifetime of the temporary.



    I am not sure if I understood this right: A temporary exists as long as
    the const reference it was bound to. So the part of binding the temporary to
    the return value should not yet pose a problem. The problems start when
    actually using the return value, because assigning it to another const
    reference (which includes calling std::string::eek:perator=) does not extend
    the life of the temporary again, thus leaving us with a const reference to
    an invalid object. Is this correct?

    thanks!
    --
    jb

    (reply address in rot13, unscramble first)
     
    Jakob Bieling, Jan 31, 2005
    #8
  9. Matthias wrote:
    > Victor Bazarov wrote:
    >
    >> Matthias wrote:
    >>
    >>> Nakor wrote:
    >>>
    >>>>
    >>>> Other than that I'm not sure what would be the intention :)
    >>>>
    >>>
    >>> The point is, returning a reference to a local object can generally
    >>> be called a bad idea :)

    >>
    >>
    >>
    >> I actually thought the function returned a reference to a temporary.
    >> The problem is not that it's local (and a string literal is not really
    >> local to anything), the problem is in the lifetime of the temporary.
    >>
    >> V

    >
    >
    > Yes, the temporary will be deleted upon leaving the scope.


    Why? There is a const reference bound to it...

    > So will any
    > local object during stack unwinding. So the point stays the same, no? :)


    No.
     
    Victor Bazarov, Jan 31, 2005
    #9
  10. Nakor

    Matthias Guest

    Victor Bazarov wrote:
    > Why? There is a const reference bound to it...


    I see. Thanks for clearing up :)

    --
    Regards,
    Matthias
     
    Matthias, Jan 31, 2005
    #10
  11. Nakor

    Default User Guest

    Nakor wrote:
    > Hello,
    >
    > I am a Computer Programmer Analyst student. I am taking this course
    > which for this week's assignment requires me to join some newsgroups.
    > I am sorry to have to spam you with such useless crap.



    Ok, I'll supply some advice for using the Google interface for posting
    to usenet groups. It's common practice to quote a relevant portion of
    the message to which you are replying, as I have done here.
    Unfortunately, the Google interface doesn't make it obvious to the new
    user how to do so.

    Rather than clicking the Reply at the bottom of the message, look for
    one alongside the header labeled "show options". Click this, and the
    header will expand. Select the Reply shown there, and you will get a
    full quoting of the message with proper attributions. This will make
    your experience on usenet MUCH more fulfilling.




    Brian
     
    Default User, Jan 31, 2005
    #11
  12. Jakob Bieling wrote:
    > "Victor Bazarov" <> wrote in message
    > news:SwvLd.40543$01.us.to.verio.net...
    >
    >>Matthias wrote:
    >>
    >>>Nakor wrote:
    >>>
    >>>
    >>>>Other than that I'm not sure what would be the intention :)
    >>>>
    >>>
    >>>The point is, returning a reference to a local object can generally be
    >>>called a bad idea :)

    >>
    >>I actually thought the function returned a reference to a temporary.
    >>The problem is not that it's local (and a string literal is not really
    >>local to anything), the problem is in the lifetime of the temporary.

    >
    >
    >
    > I am not sure if I understood this right: A temporary exists as long as
    > the const reference it was bound to. So the part of binding the temporary to
    > the return value should not yet pose a problem. The problems start when
    > actually using the return value, because assigning it to another const
    > reference (which includes calling std::string::eek:perator=) does not extend
    > the life of the temporary again, thus leaving us with a const reference to
    > an invalid object. Is this correct?


    This is a very good question. I am not really sure, to be honest.

    Recently there were some discussions (I even participated in one of
    them, IIRC) about lifetimes of temporaries if they are returned from
    functions as objects and then either bound to references or not. So,
    from those points of view, if I write

    #include <string>
    const std::string& foo() { return "foo"; }
    int main() {
    const std::string& bar = foo();
    }

    the temporary created inside 'foo' should survive until 'main' returns
    since there is always some reference bound to it...

    Another point you brought up is assignment, so if I write

    #include <string>
    const std::string& foo() { return "foo"; }
    int main() {
    std::string bar = foo();
    }

    it still should be OK, since the temporary is created as part of the
    initialiser expression, and will last until the constructor returns
    upon constructing the 'bar' object (12.2/4).

    Now, I am likely making a mistake in both of those cases and the
    temporary is not going to survive long enough. 12.2/5 among other
    things, states "A temporary bound to the returned value in a function
    return statement (6.6.3) persists until the function exits" which does
    put me in doubt about my correctness.

    Now, the main question is, can _re_binding the reference keep the
    temporary alive or do we only get one shot at it? IOW, if I do

    std::string foo() { return "42"; }
    const std::string& bar() { return foo(); }
    const std::string& foobar() { return bar(); }

    does 'foobar' return a valid reference? Even stricter, does 'bar'
    return a valid reference?

    V
     
    Victor Bazarov, Jan 31, 2005
    #12
  13. Matthias wrote:
    > Victor Bazarov wrote:
    >
    >> Why? There is a const reference bound to it...

    >
    >
    > I see. Thanks for clearing up :)


    Not at all. I mean, I don't think I cleared it up. But that
    muddying of the waters wasn't intentional. I myself am in the
    fog WRT this. One thing I know for sure, it's not a local
    object.

    V
     
    Victor Bazarov, Jan 31, 2005
    #13
  14. Victor Bazarov wrote:

    > Not at all. I mean, I don't think I cleared it up. But that
    > muddying of the waters wasn't intentional. I myself am in the
    > fog WRT this. One thing I know for sure, it's not a local
    > object.



    Based on TC++PL "10.4.10 Temporary Objects" I think the temporary
    created after the return of the literal is destroyed at the end of the
    expression.


    An example mentioned there:

    "However, in combination they can cause obscure problems.

    For example:

    void f(string& s1, string& s2, string& s3)
    {
    const char* cs= (s1+s2).c_ str() ;

    cout << cs;

    if (strlen(cs=(s2+s3).c_ str())<8 && cs[0]==´a´) {
    // cs used here
    }
    }

    Probably, your first reaction is "but don’t do that," and I agree.

    However, such code does get written, so it is worth knowing how it is
    interpreted.

    A temporary object of class string is created to hold s1+s2. Next, a
    pointer to a C-style string is extracted from that object. Then – at the
    end of the expression – the temporary object is deleted.

    Now, where was the C-style string allocated? Probably as part of the
    temporary object holding s1+s2, and that storage is not guaranteed to
    exist after that temporary is destroyed. Consequently, cs points to
    deallocated storage. The output operation cout<<cs might work as
    expected, but that would be sheer luck. A compiler can detect and warn
    against many variants of this problem.

    The example with the if-statement is a bit more subtle. The condition
    will work as expected because the full expression in which the temporary
    holding s2+s3 is created is the condition itself.

    However, that temporary is destroyed before the controlled statement is
    entered, so any use of cs there is not guaranteed to work.

    Please note that in this case, as in many others, the problems with
    temporaries arose from using a high-level data type in a low-level
    way. A cleaner programming style would have not only yielded a more
    understandable program fragment, but also avoided the problems with
    temporaries completely. For example:

    ...."




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Feb 1, 2005
    #14
  15. Ioannis Vranos wrote:

    > Based on TC++PL "10.4.10 Temporary Objects" I think the temporary
    > created after the return of the literal is destroyed at the end of the
    > expression.
    >
    >
    > An example mentioned there:
    >
    > "However, in combination they can cause obscure problems.
    >
    > For example:
    >
    > void f(string& s1, string& s2, string& s3)
    > {
    > const char* cs= (s1+s2).c_ str() ;
    >
    > cout << cs;
    >
    > if (strlen(cs=(s2+s3).c_ str())<8 && cs[0]==´a´) {
    > // cs used here
    > }
    > }



    Actually this example is different from what we are discussing here, and
    probably the temporary remains until the end of the scope of the const
    reference.




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Feb 1, 2005
    #15
  16. Ioannis Vranos wrote:

    > and
    > probably the temporary remains until the end of the scope of the const
    > reference.



    Probably in agreement to this, TC++PL mentions in the same place:


    "A temporary can be used as an initializer for a const reference or a
    named object. For example:

    void g(const string&, const string&) ;

    void h(string& s1, string& s2)
    {
    const string& s = s1+s2;

    string ss = s1+s2;

    g(s,ss); // we can use s and ss here
    }

    This is fine. The temporary is destroyed when "its" reference or named
    object go out of scope.

    Remember that returning a reference to a local variable is an error
    (7.3) and that a temporary object cannot be bound to a non-const
    reference (5.5).

    A temporary object can also be created by explicitly invoking a
    constructor. For example:

    void f(Shape& s, int x, int y)
    {
    s.move(Point(x,y)); // construct Point to pass to Shape::move()
    // ...
    }

    *Such temporaries are destroyed in exactly the same way as the
    implicitly generated temporaries.*"




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Feb 1, 2005
    #16
  17. In message <>,
    Nakor <> writes
    >Hello,
    >
    >I am a Computer Programmer Analyst student. I am taking this course
    >which for this week's assignment requires me to join some newsgroups.
    >I am sorry to have to spam you with such useless crap.
    >
    >Regardless I am supposed to instigate a response of some sort, so could
    >someone please fulfill that requirement for me?


    That's easy. Please post the email address of the person who set you
    this useless task, so we can return the favour.

    There you are. Purposeful communication on Usenet. Whatever next?

    --
    Richard Herring
     
    Richard Herring, Feb 1, 2005
    #17
  18. Victor Bazarov wrote:
    > Jakob Bieling wrote:
    > > I am not sure if I understood this right: A temporary exists as

    long as
    > > the const reference it was bound to. So the part of binding the

    temporary to
    > > the return value should not yet pose a problem. The problems start

    when
    > > actually using the return value, because assigning it to another

    const
    > > reference (which includes calling std::string::eek:perator=) does not

    extend
    > > the life of the temporary again, thus leaving us with a const

    reference to
    > > an invalid object. Is this correct?

    IMHO it is.

    > #include <string>
    > const std::string& foo() { return "foo"; }
    > int main() {
    > const std::string& bar = foo();
    > }
    >
    > the temporary created inside 'foo' should survive until 'main'

    returns
    > since there is always some reference bound to it...

    I think not. As you say there is "some" reference.
    A const reference "initialized" with a temporary value makes that
    temporary value live for the lifetime of the reference itself. But,
    chaining of const references assignment doesn't prevent temporary
    destruction (IMHO you need GC to ensure such a behavior).

    > Now, I am likely making a mistake in both of those cases and the
    > temporary is not going to survive long enough. 12.2/5 among other
    > things, states "A temporary bound to the returned value in a function
    > return statement (6.6.3) persists until the function exits" which

    does
    > put me in doubt about my correctness.

    Yes I think this paragraph is relevant on this topic.
    ..
    ..
    Best regards,
    Bogdan
     
    Bogdan Sintoma, Feb 1, 2005
    #18
  19. Nakor

    Nakor Guest

    >That's easy. Please post the email address of the person who­ set you

    >this useless task, so we can return the favour.


    My sentiments exactly. Unfortunately I can not send you her email as I
    would certainly get in trouble with the school. I was very annoyed to
    have to do this assignment.
     
    Nakor, Feb 1, 2005
    #19
  20. In message <>, Nakor
    <> writes
    >>That's easy. Please post the email address of the person who­ set you

    >
    >>this useless task, so we can return the favour.

    >
    >My sentiments exactly. Unfortunately I can not send you her email as I
    >would certainly get in trouble with the school. I was very annoyed to
    >have to do this assignment.
    >

    You'd better hope that L*** A**** isn't reading this group, then.

    --
    Richard Herring
     
    Richard Herring, Feb 1, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alan Seunarayan

    CAB Files (sorry for cross - posting!)

    Alan Seunarayan, Apr 26, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    698
    bruce barker
    Apr 26, 2004
  2. Alan S.
    Replies:
    0
    Views:
    451
    Alan S.
    Aug 16, 2004
  3. josephtthomas

    sorry...me newbie...

    josephtthomas, Dec 23, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    421
    Kevin Spencer
    Dec 23, 2003
  4. Big E

    Sorry

    Big E, Jun 11, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    537
    Big E
    Jun 11, 2004
  5. =?Utf-8?B?dG1laXN0ZXI=?=

    Sorry about muiltiple asp.net caching questions

    =?Utf-8?B?dG1laXN0ZXI=?=, Jun 28, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    314
    =?Utf-8?B?dG1laXN0ZXI=?=
    Jun 28, 2004
Loading...

Share This Page