Lifetime extension of temporaries' data members and API design

Question

Suppose I have a cross-platform Path class like:

class Path {
public:
    // ...
    Path parent() const;                // e.g., /foo/bar -> /foo

    std::string const& as_utf8() const {
        return path;
    }
private:
    std::string path;
};

The parent() member function returns the parent path of this path, so it (rightly) returns a newly constructed Path object that represents it.

For a platform that represents paths at the OS-level as UTF-8 strings (e.g., Unix), it seems reasonable for as_utf8() to return a reference directly to the internal representation path since it's already UTF-8.

If I have code like:

std::string const &s = my_path.as_utf8();  // OK (as long as my_path exists)
// ...
Path const &parent = my_path.parent();     // OK (temporary lifetime extended)

Both these lines are fine because:

• Assuming my_path persists, then s remains valid.
• The lifetime of the temporary object returned by parent() is extended by the const&.

So far, so good. However, if I have code like:

std::string const &s = my_path.parent().as_utf8(); // WRONG

then this is wrong because the temporary object returned by parent() does not have its lifetime extended because the const& does not refer to the temporary but to a data member of it. At this point, if you try to use s, you'll either get garbage or a core dump. If the code were instead:

    std::string as_utf8() const {                 // Note: object and NOT const&
        return path;
    }

then the code would be correct. However, it would be inefficient to create a temporary every time this member function is called. The implication is also that no "getter" member functions should ever return references to their data members.

If the API is left as-is, then it would seem to place an undue burden on the caller to have to look at the return type of as_utf8() to see whether it returns a const& or not: if it does, then the caller must use an object and not a const&; if it returns an object, then the caller may use a const&.

So is there any way to solve this problem such that the API is both efficient in most cases yet prevents the user from obtaining dangling references from seemingly innocuous looking code?

---

By the way, this was compiled using g++ 5.3. It's possible that the lifetime of the temporary should be extended, but that the compiler has a bug.

Answer 1

What you could do is create 2 different versions of as_utf8(), one when used on lvalues, and one for rvalues. You would need C++11 though.

That way, you get the best of both worlds: a const& when the object isn't a temporary, and an efficient move when it isn't:

std::string const& as_utf8() const & {
                               // ^^^ Called from lvalues only
    return path;
}

std::string as_utf8() const && {
                        // ^^^^ Called from rvalues only
    return std::move(path); //We don't need path any more
}

Answer 2

To my mind the guiding principle as to whether to return a reference or an object is to examine the defined role of the originating class.

i.e. is the method exposing a simple property (argues for a reference, particularly if it's immutable), or is it generating something?

If it's generating a new object or representation we can reasonably expect it to return a distinct object.

Users of APIs are generally accustomed to understanding that properties do not outlive their host objects. This can of course be made plain in the documentation.

e.g.

struct path
{
    /// a property
    /// @note lifetime is no longer than the lifetime of this object
    std::string const& native() const;

    /// generate a new string representation in a different format
    std::string to_url() const;

};

I personally would avoid the prefix of as_ in this case since to me it suggest that we're returning a new representation of the same object, such as:

struct world 
: std::enable_shared_from_this<world>
{
    struct sky {} my_sky_;

    /// returns a shared_ptr to my sky object, which shares its lifetime
    /// with this world.
    std::shared_ptr<sky> as_sky() 
    { 
      return std::shared_ptr<sky>(shared_from_this(), std::addressof(my_sky_));
    }
};