9

sorry for such a long question but I try to be as clear as possible. This somehow follows my previous question about strings in C++. I'm trying to figure out how I could return std::string from a function without redundant memory allocations, without relying on NRVO. The reasons why I don't want to rely on NRVO are:

  • it is not supported by the compiler we currently use
  • even when it is supported it might not always be enabled in Debug mode
  • it might fail in some cases (example)

Please note that I need a C++03 compatible solution (no C++0x rvalue references thus, unfortunately...)

The simplest way do this is pass-by-reference and do std::swap, like this

void test(std::string& res)
{
    std::string s;
    //...
    res.swap(s);
}

But it is more natural and often more convenient to return by value than pass by reference, so what I want to achieve is this:

std::string test()
{
    std::string s;
    //...
    return SOMETHING(s);
}

Ideally it would just do a swap with the "return value", but I don't see how to do this in C++. There is auto_ptr already which does move instead of copy, and I could actually use auto_ptr<string>, but I'd like to avoid dynamically allocating the string object itself.

My idea is to somehow "tag" a string object that it is being returned from a function to permit moving its data when a copy constructor is called on return. So I ended up with this code, which does exactly what I want:

struct Str
{
    struct Moveable
    {
        Str & ref;
        explicit Moveable(Str & other): ref(other) {}
    };

    Str() {}
    Str(const std::string& other) : data(other) {} // copy
    Str(Moveable& other) { data.swap(other.ref.data); } // move

    Moveable Move()
    {
        return Moveable(*this);
    }

    std::string data;
};

Str test()
{
    Str s;
    //...
    return s.Move(); // no allocation, even without NRVO
}

So... Does all this make sense, or there are some serious issues that I'm missing? (I'm not sure if there is no lifetime issue for example). Maybe you have already seen such idea in a library (book, article...), and could give me a reference to it?

EDIT: As @rstevens noticed, this code is MSVC-specific and won't compile under g++ which does not like the non-const temporary. This is an issue, but let's just assume this implementation is MSVC-specific.

Community
  • 1
  • 1
Roman L
  • 3,006
  • 25
  • 37
  • I'm unsure what you are asking. Do you just need to fix your code? You say it does exactly what you want but - as far as I can see - it shouldn't compile. – CB Bailey Jan 19 '11 at 17:16
  • 2
    Have you checked if your string does COW. If so there will be few extra memory allocations. Also some implementations of std::string will put the string in the object (when the string is short) rather than allocate memory for it. If wither of these is true your attempts at optimization may be increasing the cost rather than reducing it. – Martin York Jan 19 '11 at 17:16
  • @Charles: The code is there to explain what I'm trying to achieve, and the question is if I see it right and if there are already some good implementations of that. – Roman L Jan 19 '11 at 17:18
  • @Martin: MSVC does not do COW on std::string as far as I know. Please also see my previous question that I refer to, as we already discussed COW quite much there. Finally, I don't see how this approach can increase the cost, is string::swap somehow incompatible with COW? – Roman L Jan 19 '11 at 17:23
  • "It might fail in some cases" is not a valid point. Developers should be aware of RVO if performance is critical. In particular, the code sample in the linked article will most probably allocate more than required regardless of which is the returned string, if performance is critical, code would avoid the extra allocations inside the function and that will help the compiler perform NRVO at the same time. Also note that depending on the commented out region, some compilers could reorder the code so that the strings are created after branching, removing one string and enabling RVO. Read the asm. – David Rodríguez - dribeas Jan 19 '11 at 17:40
  • @7vies: have you try this pattern out with an object which ouputs something at construction/copy/assignement/destruction ? I don't see how this would actually achieve NRVO... but I am relatively tired tonight :p – Matthieu M. Jan 19 '11 at 18:03
  • @Matthieu: It is NRVO-like only in the sense that it does not lead to redundant memory allocation, which is achieved by doing swap (move) instead of making a copy. Yes, there is construction/destruction, but it is fast for empty strings. – Roman L Jan 19 '11 at 18:10
  • 1
    @David: I wouldn't agree with you in this particular case. Here I would prefer to be sure what is happening (swap) rather than relying on compiler-dependent optimization and reading assembler each time to ensure it was optimized. – Roman L Jan 19 '11 at 18:13

3 Answers3

4

The implementation of boost uses move semantics emulation internally for libraries like Boost.Thread. You may want to look at the implementation and do something similar.

Edit: there is actually an active development of a library Boost.Move, so you can already start using it.

Yakov Galka
  • 70,775
  • 16
  • 139
  • 220
1

Did you check this code on g++?

Since you call Str(Movable &) with a temporary object (the one returned by s.Move())!

This is not standard's compliant and not supported by g++. It is supported by MSVC! (MS calls this a feature...).

mmmmmmmm
  • 15,269
  • 2
  • 30
  • 55
  • You are right, won't compile under g++, I've updated the question. Something different can probably be done for g++, but I'm more interested to know if something *similar* is used somewhere, not exactly my sample implementation. – Roman L Jan 19 '11 at 21:01
0

Have you actually determined that returning by value is a performance problem in your application? That seems like the simplest/easiest way to go, and when you upgrade to a more modern compiler you can use rvalue references.

I can't answer the question regarding the destruction order of s vs the Movable's reference. You could, for your compiler, put code in the various constructors and destructors to see what the order is. Even if it looks ok I'd still consider using one of the normal patterns you outlined though just to prevent reader confusion and possibly breaking on an alternate compiler.

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • 1
    It's not only a question of optimization to me, as it influences the typical usage - unless developers know that return by value is cheap, they will try to avoid doing this. People still try to write somewhat optimal code, even if you say that premature optimization is evil. – Roman L Jan 19 '11 at 19:05