returning references

Discussion in 'C++' started by pauldepstein@att.net, Jan 4, 2008.

  1. Guest

    Below is posted from a link for Stanford students in computer
    science.

    QUOTE BEGINS HERE
    Because of the risk of misuse, some experts recommend never returning
    a
    reference from a function or method.
    QUOTE ENDS HERE

    I have never heard anyone else say that it is a problem for a function
    to return a reference. Are there really experts who object, or is
    this nothing other than the commonplace observation that reference-
    returning is a somewhat difficult concept that needs to be learned
    carefully? (I am just learning about this now.) Assuming programmers
    have some degree of competence and are able to avoid returning
    references to locals and so on, what (if anything) are the pitfalls?

    Paul Epstein
    , Jan 4, 2008
    #1
    1. Advertising

  2. Christopher Guest

    On Jan 3, 6:26 pm, wrote:
    > Below is posted from a link for Stanford students in computer
    > science.
    >
    > QUOTE BEGINS HERE
    > Because of the risk of misuse, some experts recommend never returning
    > a
    > reference from a function or method.
    > QUOTE ENDS HERE
    >
    > I have never heard anyone else say that it is a problem for a function
    > to return a reference. Are there really experts who object, or is
    > this nothing other than the commonplace observation that reference-
    > returning is a somewhat difficult concept that needs to be learned
    > carefully? (I am just learning about this now.) Assuming programmers
    > have some degree of competence and are able to avoid returning
    > references to locals and so on, what (if anything) are the pitfalls?
    >
    > Paul Epstein


    I don't see anything at all with returning references as long as the
    const keyword is used correctly when appropriate. Surprisingly, a good
    number of people do not use const when creating thier function stubs;

    const MyClass & GetMyClass() const; // The typical accessor
    SetMyClass(const MyClass & myclass); // The typical mutator

    I constantly find the above two methods lacking the const keyword in
    source when I am debugging and it leads to misuse by other programmers
    who simply glance at a method without taking into account the impact
    of making changes to the returned reference.

    Another common problem I run into is you can't return NULL for a
    reference. Sometimes it is nice to have the option to return NULL when
    an error occured in which case I use a pointer and tell the caller to
    check the returned value to determine if an error occured. Some people
    don't like that idea though, but it is worth mentioning.
    Christopher, Jan 4, 2008
    #2
    1. Advertising

  3. On 2008-01-04 01:26, wrote:
    > Below is posted from a link for Stanford students in computer
    > science.
    >
    > QUOTE BEGINS HERE
    > Because of the risk of misuse, some experts recommend never returning
    > a
    > reference from a function or method.
    > QUOTE ENDS HERE
    >
    > I have never heard anyone else say that it is a problem for a function
    > to return a reference. Are there really experts who object, or is
    > this nothing other than the commonplace observation that reference-
    > returning is a somewhat difficult concept that needs to be learned
    > carefully? (I am just learning about this now.) Assuming programmers
    > have some degree of competence and are able to avoid returning
    > references to locals and so on, what (if anything) are the pitfalls?


    As far as I know there is only one pitfall, and that is returning a
    reference to a variable local to the function, like so:

    int& foo(int i)
    {
    int r = i+i;
    return r;
    }

    int main()
    {
    int& twice = foo(5);
    }

    Since r is a local variable to foo() it will go out of scope as soon as
    foo() is done executing, this means that the reference returned refers
    to a variable that no longer exists.

    On the other hand there are a number of valid reasons to return a
    reference from a function, a function that returns an element from a
    collection is a good example (look at the at() function in std::vector).

    --
    Erik Wikström
    Erik Wikström, Jan 4, 2008
    #3
  4. kwikius Guest

    On Jan 4, 12:26 am, wrote:
    > Below is posted from a link for Stanford students in computer
    > science.
    >
    > QUOTE BEGINS HERE
    > Because of the risk of misuse, some experts recommend never returning
    > a
    > reference from a function or method.
    > QUOTE ENDS HERE


    hmmm... I assume that following this extremely wise and useful advice,
    Stanford students will not be allowed to do ...

    #include <iostream>
    int main(){
    std::cout << "hello world\n";
    }


    regards
    Andy Little

    (Thankfully Not a C++ expert!) :)
    kwikius, Jan 4, 2008
    #4
  5. Daniel T. Guest

    wrote:

    > Below is posted from a link for Stanford students in computer
    > science.
    >
    > QUOTE BEGINS HERE
    > Because of the risk of misuse, some experts recommend never
    > returning a reference from a function or method.
    > QUOTE ENDS HERE
    >
    > I have never heard anyone else say that it is a problem for a
    > function to return a reference.


    "C++ Coding Standards" by Sutter & Alexandrescu. Item 42: Don't give
    away your internals.

    Don't volunteer too much: Avoid returning handles to internal data
    managed by your class, so clients won't uncontrollably modify
    state that your object thinks it owns.

    For context, "handles" above is defined as non-const references, and
    pointers to non-const data.

    So now you have heard of at least two acknowledged experts who almost
    state the same thing.

    > Are there really experts who object, or is this nothing other than
    > the commonplace observation that reference- returning is a somewhat
    > difficult concept that needs to be learned carefully? (I am just
    > learning about this now.) Assuming programmers have some degree of
    > competence and are able to avoid returning references to locals and
    > so on, what (if anything) are the pitfalls?


    The only valid reference that can be returned from a non-member function
    is something that either the calling code had access to anyway, or
    something that is buried in a module.

    The only valid reference that can be returned from a member-function is
    of something that either the calling code had access to anyway, or
    something that is private within the class.

    In either case, if you are returning a non-const reference, then the
    object returned better not have anything to do with the invariant of
    that class/module or the class/module is asking for trouble
    (encapsulation is broken.)
    Daniel T., Jan 4, 2008
    #5
  6. Christopher Guest

    On Jan 3, 11:14 pm, "Daniel T." <> wrote:
    > wrote:
    > > Below is posted from a link for Stanford students in computer
    > > science.

    >
    > > QUOTE BEGINS HERE
    > > Because of the risk of misuse, some experts recommend never
    > > returning a reference from a function or method.
    > > QUOTE ENDS HERE

    >
    > > I have never heard anyone else say that it is a problem for a
    > > function to return a reference.

    >
    > "C++ Coding Standards" by Sutter & Alexandrescu. Item 42: Don't give
    > away your internals.
    >
    > Don't volunteer too much: Avoid returning handles to internal data
    > managed by your class, so clients won't uncontrollably modify
    > state that your object thinks it owns.
    >
    > For context, "handles" above is defined as non-const references, and
    > pointers to non-const data.
    >
    > So now you have heard of at least two acknowledged experts who almost
    > state the same thing.


    I beg to differ with the statement that two quotes from so called
    experts _almost_ say the same thing. They are extremely different
    considering the impact of const correctness. the former quote is
    moronic and the latter is imo quite correct.


    > > Are there really experts who object, or is this nothing other than
    > > the commonplace observation that reference- returning is a somewhat
    > > difficult concept that needs to be learned carefully? (I am just
    > > learning about this now.) Assuming programmers have some degree of
    > > competence and are able to avoid returning references to locals and
    > > so on, what (if anything) are the pitfalls?

    >
    > The only valid reference that can be returned from a non-member function
    > is something that either the calling code had access to anyway, or
    > something that is buried in a module.
    >
    > The only valid reference that can be returned from a member-function is
    > of something that either the calling code had access to anyway, or
    > something that is private within the class.


    What's stopping me from returning a reference to protected data
    exactly?

    > In either case, if you are returning a non-const reference, then the
    > object returned better not have anything to do with the invariant of
    > that class/module or the class/module is asking for trouble
    > (encapsulation is broken.)


    agreed.
    Christopher, Jan 4, 2008
    #6
  7. Salt_Peter Guest

    On Jan 3, 7:26 pm, wrote:
    > Below is posted from a link for Stanford students in computer
    > science.
    >
    > QUOTE BEGINS HERE
    > Because of the risk of misuse, some experts recommend never returning
    > a
    > reference from a function or method.
    > QUOTE ENDS HERE
    >
    > I have never heard anyone else say that it is a problem for a function
    > to return a reference. Are there really experts who object, or is
    > this nothing other than the commonplace observation that reference-
    > returning is a somewhat difficult concept that needs to be learned
    > carefully? (I am just learning about this now.) Assuming programmers
    > have some degree of competence and are able to avoid returning
    > references to locals and so on, what (if anything) are the pitfalls?
    >
    > Paul Epstein


    Nothing wrong in returning references, example: various operators.
    You already coverred the case of returning a temporary.
    One pitfall is side-effects where an accessor might _get_ nasty.
    Thats where CV-qualifiers play an important role.

    #include <iostream>
    #include <ostream>

    class N
    {
    int m_n;
    public:
    N(int n) : m_n(n) { }
    // accessors
    int& getnasty() { return m_n; } // nasty
    int const& getsafe() const { return m_n; }
    void set(const int& n) { m_n = n; }
    // friend op<<
    friend std::eek:stream&
    operator<<(std::eek:stream& os, const N& r)
    {
    return os << r.m_n;
    }
    };

    int main()
    {
    N instance(9);
    std::cout << instance << std::endl;

    instance.getnasty() = -1; // nasty side-effect
    std::cout << instance << std::endl;

    instance.set(8);
    std::cout << instance << std::endl;
    std::cout << instance.getsafe() << std::endl;
    }

    /*
    9
    -1
    8
    8
    */
    Salt_Peter, Jan 4, 2008
    #7
  8. Barry Guest

    kwikius wrote:
    > On Jan 4, 12:26 am, wrote:
    >> Below is posted from a link for Stanford students in computer
    >> science.
    >>
    >> QUOTE BEGINS HERE
    >> Because of the risk of misuse, some experts recommend never returning
    >> a
    >> reference from a function or method.
    >> QUOTE ENDS HERE

    >
    > hmmm... I assume that following this extremely wise and useful advice,
    > Stanford students will not be allowed to do ...
    >
    > #include <iostream>
    > int main(){
    > std::cout << "hello world\n";


    well this is allowed, while
    std::cout << "hello world" << std::endl;
    is not,

    write
    std::cout << "hello world";
    std::cout << std::endl;
    instead.

    :D

    > }
    >
    >
    > regards
    > Andy Little
    >
    > (Thankfully Not a C++ expert!) :)
    Barry, Jan 4, 2008
    #8
  9. James Kanze Guest

    On Jan 4, 6:48 am, Christopher <> wrote:
    > On Jan 3, 11:14 pm, "Daniel T." <> wrote:
    > > wrote:
    > > > Below is posted from a link for Stanford students in computer
    > > > science.


    > > > QUOTE BEGINS HERE
    > > > Because of the risk of misuse, some experts recommend never
    > > > returning a reference from a function or method.
    > > > QUOTE ENDS HERE


    > > > I have never heard anyone else say that it is a problem for a
    > > > function to return a reference.


    > > "C++ Coding Standards" by Sutter & Alexandrescu. Item 42: Don't give
    > > away your internals.


    > > Don't volunteer too much: Avoid returning handles to internal data
    > > managed by your class, so clients won't uncontrollably modify
    > > state that your object thinks it owns.


    > > For context, "handles" above is defined as non-const references, and
    > > pointers to non-const data.


    > > So now you have heard of at least two acknowledged experts who almost
    > > state the same thing.


    > I beg to differ with the statement that two quotes from so called
    > experts _almost_ say the same thing. They are extremely different
    > considering the impact of const correctness. the former quote is
    > moronic and the latter is imo quite correct.


    The real difference is that they are addressing two radically
    different levels. The Sutter/Alexandrescu quote has nothing to
    do with references per se, but is more concerned with design;
    I'm sure that neither Sutter nor Alexandrescu would condemn
    std::vector<>::eek:perator[] because it returns a reference (to
    internal data, no less), nor the operator<< and operator>> in
    iostream because they return a reference to support chaining.
    (Alexandrescu definitly doesn't like iostream, but I don't think
    that the fact that operator<< returns a reference has anything
    to do with it.)

    The real difference is that Sutter and Alexandrescu address a
    real issue with their comment: how to intelligently design a
    class. Where as the quoted recommendation simply misses the
    point entirely, by concentrating on an irrelevant syntax issue.
    (How is returning a reference riskier than returning a pointer,
    for example?)

    > > > Are there really experts who object, or is this nothing
    > > > other than the commonplace observation that reference-
    > > > returning is a somewhat difficult concept that needs to be
    > > > learned carefully? (I am just learning about this now.)
    > > > Assuming programmers have some degree of competence and
    > > > are able to avoid returning references to locals and so
    > > > on, what (if anything) are the pitfalls?


    > > The only valid reference that can be returned from a
    > > non-member function is something that either the calling
    > > code had access to anyway, or something that is buried in a
    > > module.


    > > The only valid reference that can be returned from a
    > > member-function is of something that either the calling code
    > > had access to anyway, or something that is private within
    > > the class.


    > What's stopping me from returning a reference to protected
    > data exactly?


    > > In either case, if you are returning a non-const reference,
    > > then the object returned better not have anything to do with
    > > the invariant of that class/module or the class/module is
    > > asking for trouble (encapsulation is broken.)


    > agreed.


    But what does that say, anyway? And how is returning a
    reference any more of a problem here than returning a pointer.

    There are two issues with returning a reference; permitting
    access to internal details, and the lifetime of what is referred
    to. They're both design issues, both affect other constructs as
    well, and neither affects all use of references. Many standard
    idioms and patterns involve returning references, and I've never
    heard of any expert who recommended never returning a reference.

    --
    James Kanze (GABI Software) mailto:
    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
    James Kanze, Jan 4, 2008
    #9
  10. On 2008-01-04 10:29, Barry wrote:
    > kwikius wrote:
    >> On Jan 4, 12:26 am, wrote:
    >>> Below is posted from a link for Stanford students in computer
    >>> science.
    >>>
    >>> QUOTE BEGINS HERE
    >>> Because of the risk of misuse, some experts recommend never returning
    >>> a
    >>> reference from a function or method.
    >>> QUOTE ENDS HERE

    >>
    >> hmmm... I assume that following this extremely wise and useful advice,
    >> Stanford students will not be allowed to do ...
    >>
    >> #include <iostream>
    >> int main(){
    >> std::cout << "hello world\n";

    >
    > well this is allowed, while
    > std::cout << "hello world" << std::endl;
    > is not,
    >
    > write
    > std::cout << "hello world";
    > std::cout << std::endl;
    > instead.


    The reference will be returned regardless if you use it or not, but I
    guess they make an exception for library functions :)

    PS. Please do not quote signatures

    --
    Erik Wikström
    Erik Wikström, Jan 4, 2008
    #10
  11. Daniel T. Guest

    Christopher <> wrote:
    > "Daniel T." <> wrote:
    > > wrote:


    > > > Below is posted from a link for Stanford students in computer
    > > > science.

    > >
    > > > QUOTE BEGINS HERE
    > > > Because of the risk of misuse, some experts recommend never
    > > > returning a reference from a function or method.
    > > > QUOTE ENDS HERE

    > >
    > > > I have never heard anyone else say that it is a problem for a
    > > > function to return a reference.

    > >
    > > "C++ Coding Standards" by Sutter & Alexandrescu. Item 42: Don't give
    > > away your internals.
    > >
    > > Don't volunteer too much: Avoid returning handles to internal data
    > > managed by your class, so clients won't uncontrollably modify
    > > state that your object thinks it owns.
    > >
    > > For context, "handles" above is defined as non-const references, and
    > > pointers to non-const data.
    > >
    > > So now you have heard of at least two acknowledged experts who almost
    > > state the same thing.

    >
    > I beg to differ with the statement that two quotes from so called
    > experts _almost_ say the same thing. They are extremely different
    > considering the impact of const correctness. the former quote is
    > moronic and the latter is imo quite correct.


    Only if you assume that the former quote includes "const reference" when
    it says "reference". It may not.

    My personal standing rule is, "functions return const reference, pointer
    to const, or by object, unless they are returning one of the parameters
    passed in." (Of course there are exceptions, there are exceptions to
    every rule, but if I find myself returning a non-const reference or a
    pointer to a non-const object, I make sure I have a real good reason.)

    > > > Are there really experts who object, or is this nothing other than
    > > > the commonplace observation that reference- returning is a somewhat
    > > > difficult concept that needs to be learned carefully? (I am just
    > > > learning about this now.) Assuming programmers have some degree of
    > > > competence and are able to avoid returning references to locals and
    > > > so on, what (if anything) are the pitfalls?

    > >
    > > The only valid reference that can be returned from a non-member function
    > > is something that either the calling code had access to anyway, or
    > > something that is buried in a module.
    > >
    > > The only valid reference that can be returned from a member-function is
    > > of something that either the calling code had access to anyway, or
    > > something that is private within the class.

    >
    > What's stopping me from returning a reference to protected data
    > exactly?


    Granted. The point of the post is that if you are returning a non-const
    reference to something the calling code doesn't have access to (for
    whatever reason,) you are probably making a mistake.

    I suspect that at this point, any difference between our positions is
    merely picking nits.
    Daniel T., Jan 4, 2008
    #11
  12. Bo Persson Guest

    Daniel T. wrote:
    :: wrote:
    ::
    ::: Below is posted from a link for Stanford students in computer
    ::: science.
    :::
    ::: QUOTE BEGINS HERE
    ::: Because of the risk of misuse, some experts recommend never
    ::: returning a reference from a function or method.
    ::: QUOTE ENDS HERE
    :::
    ::: I have never heard anyone else say that it is a problem for a
    ::: function to return a reference.
    ::
    :: "C++ Coding Standards" by Sutter & Alexandrescu. Item 42: Don't
    :: give away your internals.
    ::
    :: Don't volunteer too much: Avoid returning handles to internal
    :: data managed by your class, so clients won't uncontrollably
    :: modify state that your object thinks it owns.
    ::
    :: For context, "handles" above is defined as non-const references,
    :: and pointers to non-const data.
    ::
    :: So now you have heard of at least two acknowledged experts who
    :: almost state the same thing.
    ::
    ::: Are there really experts who object, or is this nothing other than
    ::: the commonplace observation that reference- returning is a
    ::: somewhat difficult concept that needs to be learned carefully?
    ::: (I am just learning about this now.) Assuming programmers have
    ::: some degree of competence and are able to avoid returning
    ::: references to locals and so on, what (if anything) are the
    ::: pitfalls?
    ::
    :: The only valid reference that can be returned from a non-member
    :: function is something that either the calling code had access to
    :: anyway, or something that is buried in a module.
    ::
    :: The only valid reference that can be returned from a
    :: member-function is of something that either the calling code had
    :: access to anyway, or something that is private within the class.
    ::
    :: In either case, if you are returning a non-const reference, then
    :: the object returned better not have anything to do with the
    :: invariant of that class/module or the class/module is asking for
    :: trouble (encapsulation is broken.)

    But even if you return a const reference to internal data, the
    encapsulation is still broken - just a bit less. By returning a
    reference, you have promised to somehow keep the referred-to object.
    If you return by value, you are more free to change your
    implementation later.


    Also, we should all note that Sutter & Alexandrescu say "avoid" in
    their guidelines, not "never do this". That's an important difference!


    Bo Persson
    Bo Persson, Jan 4, 2008
    #12
  13. Daniel T. Guest

    "Bo Persson" <> wrote:

    > But even if you return a const reference to internal data, the
    > encapsulation is still broken - just a bit less. By returning a
    > reference, you have promised to somehow keep the referred-to object.
    > If you return by value, you are more free to change your
    > implementation later.


    Changing a function from returning const-reference to returning const
    object can't break any existing clients.

    IE. if I have this:

    class Object {
    public:
    const Foo& getFoo() const;
    };

    and later, I don't want to store a Foo, I can easily change the class to:

    class Object {
    public:
    const Foo getFoo() const; // I could even dump the first const
    };

    and clients will not be affected. As I understand it, the two returns
    are as interchangeable as if they were function parameters.

    At least this is my understanding...
    Daniel T., Jan 4, 2008
    #13
  14. James Kanze Guest

    On Jan 4, 8:36 pm, "Daniel T." <> wrote:
    > Changing a function from returning const-reference to returning const
    > object can't break any existing clients.


    > IE. if I have this:


    > class Object {
    > public:
    > const Foo& getFoo() const;
    > };


    > and later, I don't want to store a Foo, I can easily change
    > the class to:


    > class Object {
    > public:
    > const Foo getFoo() const; // I could even dump the first const
    > };


    > and clients will not be affected. As I understand it, the two
    > returns are as interchangeable as if they were function
    > parameters.


    Unless, of course, the type doesn't support copy. Or if the
    client takes the address of the return, and later uses it. Or
    any number of other cases as well. The lifetime of the object
    is *not* the same.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Jan 4, 2008
    #14
  15. Daniel T. Guest

    James Kanze <> wrote:
    > On Jan 4, 8:36 pm, "Daniel T." <> wrote:


    > > Changing a function from returning const-reference to returning const
    > > object can't break any existing clients.

    >
    > > IE. if I have this:

    >
    > > class Object {
    > > public:
    > > const Foo& getFoo() const;
    > > };

    >
    > > and later, I don't want to store a Foo, I can easily change
    > > the class to:

    >
    > > class Object {
    > > public:
    > > const Foo getFoo() const; // I could even dump the first const
    > > };

    >
    > > and clients will not be affected. As I understand it, the two
    > > returns are as interchangeable as if they were function
    > > parameters.

    >
    > Unless, of course, the type doesn't support copy. Or if the
    > client takes the address of the return, and later uses it. Or
    > any number of other cases as well. The lifetime of the object
    > is *not* the same.


    Well, in the former case, Object has no choice but to return a reference
    (or pointer.) In the latter case... I don't concern myself with such
    pathological behavior by the client. I don't guarantee that state
    returned by const reference will last past the next sequence point in
    any case.
    Daniel T., Jan 5, 2008
    #15
  16. James Kanze Guest

    On Jan 5, 1:57 am, "Daniel T." <> wrote:

    [...]
    > > Unless, of course, the type doesn't support copy. Or if the
    > > client takes the address of the return, and later uses it. Or
    > > any number of other cases as well. The lifetime of the object
    > > is *not* the same.


    > Well, in the former case, Object has no choice but to return a
    > reference (or pointer.)


    And the case is rather frequent, don't you think.

    > In the latter case... I don't concern myself with such
    > pathological behavior by the client. I don't guarantee that
    > state returned by const reference will last past the next
    > sequence point in any case.


    In sum, you require the results of a lookup in a map to be used
    in the expression doing the lookup, and not later. That's very,
    very counter-intuitive and unexpected. And also very difficult
    to use correctly, since the client does have to test whether the
    lookup found something before using it.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Jan 5, 2008
    #16
  17. Daniel T. Guest

    James Kanze <> wrote:
    > "Daniel T." <> wrote:
    > > Jame Kanze wrote:
    > > > Daniel T wrote:


    > > > > [Returning a const-reference to internal state can be
    > > > > converted to a return of a const object of that state]
    > > >
    > > > Unless, of course, the type doesn't support copy. Or if the
    > > > client takes the address of the return, and later uses it. Or
    > > > any number of other cases as well. The lifetime of the object
    > > > is *not* the same.

    >
    > > Well, in the former case, Object has no choice but to return a
    > > reference (or pointer.)

    >
    > And the case is rather frequent, don't you think.


    That depends on how often you use value semantics.

    > > > [What] if the client takes the address of [a const-reference]
    > > > return, and later uses it.

    > >
    > > In the latter case... I don't concern myself with such
    > > pathological behavior by the client. I don't guarantee that state
    > > returned by const reference will last past the next sequence
    > > point in any case.

    >
    > In sum, you require the results of a lookup in a map to be used in
    > the expression doing the lookup, and not later. That's very, very
    > counter-intuitive and unexpected. And also very difficult to use
    > correctly, since the client does have to test whether the lookup
    > found something before using it.


    A map does not return a non-const reference to any internal state, so I
    don't see how that relates in any way.
    Daniel T., Jan 5, 2008
    #17
  18. James Kanze Guest

    On Jan 5, 3:35 pm, "Daniel T." <> wrote:
    > James Kanze <> wrote:
    > > "Daniel T." <> wrote:
    > > > Jame Kanze wrote:
    > > > > Daniel T wrote:
    > > > > > [Returning a const-reference to internal state can be
    > > > > > converted to a return of a const object of that state]


    > > > > Unless, of course, the type doesn't support copy. Or if the
    > > > > client takes the address of the return, and later uses it. Or
    > > > > any number of other cases as well. The lifetime of the object
    > > > > is *not* the same.


    > > > Well, in the former case, Object has no choice but to return a
    > > > reference (or pointer.)


    > > And the case is rather frequent, don't you think.


    > That depends on how often you use value semantics.


    You use value semantics when value semantics are called for.
    Entity objects almost never have reference semantics. And in
    many cases, entity objects have to be looked up using an
    externally specified key.

    > > > > [What] if the client takes the address of [a const-reference]
    > > > > return, and later uses it.


    > > > In the latter case... I don't concern myself with such
    > > > pathological behavior by the client. I don't guarantee that state
    > > > returned by const reference will last past the next sequence
    > > > point in any case.


    > > In sum, you require the results of a lookup in a map to be used in
    > > the expression doing the lookup, and not later. That's very, very
    > > counter-intuitive and unexpected. And also very difficult to use
    > > correctly, since the client does have to test whether the lookup
    > > found something before using it.


    > A map does not return a non-const reference to any internal
    > state, so I don't see how that relates in any way.


    std::map certainly does return references to internal state, as
    does every other map I've every seen or heard of.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Jan 5, 2008
    #18
  19. Daniel T. Guest

    James Kanze <> wrote:
    > "Daniel T." <> wrote:


    > > A map does not return a non-const reference to any internal
    > > state, so I don't see how that relates in any way.

    >
    > std::map certainly does return references to internal state, as
    > does every other map I've every seen or heard of.


    Really, could you give an example? Maybe I'm mistaken...
    Daniel T., Jan 5, 2008
    #19
  20. Guest

    Daniel T. wrote:

    > James Kanze <> wrote:
    >> "Daniel T." <> wrote:

    >
    >> > A map does not return a non-const reference to any internal
    >> > state, so I don't see how that relates in any way.

    >>
    >> std::map certainly does return references to internal state, as
    >> does every other map I've every seen or heard of.

    >
    > Really, could you give an example? Maybe I'm mistaken...


    std::map< int, int > the_map;
    ...
    the_map[5] = 6; // the_map[5] returns an int&.

    I conjecture that the two of you are in disagreement about whether that is
    an "internal state" of the map. Since I have no idea what "internal state"
    is supposed to mean with regard to std::map, I will not offer an opinion.


    Best

    Kai-Uwe Bux
    , Jan 5, 2008
    #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. Roger Leigh
    Replies:
    8
    Views:
    414
    Karl Heinz Buchegger
    Nov 17, 2003
  2. Replies:
    3
    Views:
    434
    Victor Bazarov
    Nov 10, 2004
  3. DanielEKFA
    Replies:
    8
    Views:
    585
    DanielEKFA
    May 16, 2005
  4. Replies:
    8
    Views:
    693
    Bruno Desthuilliers
    Dec 12, 2006
  5. Lars Willich
    Replies:
    13
    Views:
    819
    Ian Shef
    Oct 23, 2007
Loading...

Share This Page