Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Your release() example is kind of interesting actually, since in most cases RVO will kick in and allow you to return a unique_ptr without fuss.

    #include <iostream>
    #include <memory>

    std::unique_ptr<int> foo() {
        std::unique_ptr<int> x(new int(42));
        return x;
    }

    int main() {
        std::cout << *foo(); 
    }
the folllowing also works:

    std::unique_ptr<int> foo(std::unique_ptr<int> x) {
        return x;
    }
the following however will not work because RVO cannot be employed (the space occupied on the stack for the return value can't be shared with the source object)

    std::unique_ptr<int> foo(bool b) {
        std::unique_ptr<int> x(new int(42));
        std::unique_ptr<int> y(new int(17));
        return b ? x : y;
    }


Wups, yeah, it occurs to me that a factory function would transfer ownership so a unique_ptr is a more appropriate return value.

You could imagine another example where the goal of the factory function is to construct an object and then set one of two or more other owned pointers to the value. You still want something to hold ownership of the pointer, but don't know its eventual home until after some complicated logic finishes, and don't want to pay the copy constructor cost. That might make a better illustration (or technically, you'd use operator= instead of release(), but same basic point).


You can use std::move() to make the last example work, so it's still easy to return unique_ptr from more complex functions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: