Return value optimization and destructor calls - c++

Question

I know that RVO is mostly applied but can I count on it? I have a function that creates an object of class FlagContainer.
class FlagContainer {
public:
~FlagContainer() {
someItem->flag = true;
}
private:
Item * someItem;
}
public FlagContainer createFlagContainer() {
return FlagContainer();
}
After the caller used the container, the flag must be set. So I can do this with the destructor.
{
FlagContainer container = createFlagContainer();
// do something with container
}
When out of scope, the destructor will be called. But can I be sure that the destructor will never be called in createFlagContainer? Is there any way to achieve this?
I would use AVR GCC 4.7.0 compiler.

Answer 1

I know that RVO is mostly applied but can I count on it?
Don't rely on RVO for logic. Put simply, someone compiling your program can switch it off with a command-line option.
Is there any way to achieve this?
Surprisingly, the standard library already gives you this functionality so you don't need to run the risk of implementing it yourself (move constructors and operators are notoriously difficult to get right)
std::unique_ptr with a custom deleter does the job nicely.
#include <iostream>
#include <memory>
#include <cassert>
// test type
struct X
{
bool flag = false;
};
// a custom deleter that sets a flag on the target
struct flag_setter_impl
{
template<class X>
void operator()(X* px) const {
if (px) {
assert(!px->flag);
std::cout << "setting flag!" << std::endl;
px->flag = true;
}
}
};
// a type of unique_ptr which does not delete, but sets a flag
template<class X>
using flag_setter = std::unique_ptr<X, flag_setter_impl>;
// make a flag_stter for x
template<class X>
auto make_flag_setter(X& x) -> flag_setter<X>
{
return flag_setter<X>(&x, flag_setter_impl());
}
// quick test
auto main() -> int
{
using namespace std;
X x;
{
auto fs1 = make_flag_setter(x);
auto fs2 = move(fs1);
}
return 0;
}
but I don't have the STL on my target
Then don't forget your rules of 0, 3, 5
#include <iostream>
#include <memory>
#include <cassert>
// test type
struct X
{
bool flag = false;
};
// a custom deleter that sets a flag on the target
struct flag_setter_impl
{
template<class X>
void operator()(X* px) const {
if (px) {
assert(!px->flag);
std::cout << "setting flag!" << std::endl;
px->flag = true;
}
}
};
// a type of unique_ptr which does not delete, but sets a flag
template<class X>
struct flag_setter
{
flag_setter(X* px) : px(px) {}
flag_setter(const flag_setter&) = delete;
flag_setter(flag_setter&& r) noexcept : px(r.px) { r.px = nullptr; }
flag_setter& operator=(const flag_setter& r) = delete;
flag_setter& operator=(flag_setter&& r)
{
flag_setter tmp(std::move(r));
std::swap(tmp.px, px);
return *this;
}
~flag_setter() noexcept {
flag_setter_impl()(px);
}
private:
X* px;
};
// make a flag_stter for x
template<class X>
auto make_flag_setter(X& x) -> flag_setter<X>
{
return flag_setter<X>(&x);
}
// quick test
auto main() -> int
{
using namespace std;
X x;
{
auto fs1 = make_flag_setter(x);
auto fs2 = move(fs1);
}
return 0;
}

Answer 2

There is no guarantee [yet] that copy-elision is applied. Guaranteed copy-elision is proposed for inclusion into C++17. Whether copy-elision is applied is entirely at the discretion of the compiler (some compilers have an option to entirely disable it, though).
A potential approach avoiding this need might be the use of an essentially unusable type which can be used only as the constructor argument for the type you are interested in being used and to return an object of that type:
class FlagContainerBuilder {
friend class FlagContainer;
public:
FlagContainerBuilder(/* suitable arguments go here */);
// nothing goes here
};
class FlagContainer {
// ...
public:
FlagContainer(FlagContainerBuilder&& builder);
// as before
};
FlagContainerBuilder createFlagContainer() { ... }
This way you avoid the need to potentially destroy a FlagContainer returned from createFlagContainer().

Answer 3

I know that RVO is mostly applied but can I count on it?
No. Compilers are allowed to implement RVO, but not required. You can only count on it, when your compiler promises to do so.

Answer 4

Although this particular case as per standard 12.8/3/p31.1 Copying and moving class objects [class.copy] renders as a context that the compiler can do NRVO (aka copy elision), you can't rely on it. A program that relies on this kind of optimization is effectively non portable.
To ensure move of the object I would define a move constructor and inside I would null the pointer of the other object, while in the destructor I would check whether the pointer is nullptr in order to set its flag true:
class FlagContainer {
public:
FlagContainer(FlagContainer&& other) : someItem(other.someItem) {
other.someItem = nullptr;
}
~FlagContainer() {
if(someItem) someItem->flag = true;
}
Item * someItem;
};
FlagContainer createFlagContainer() {
return FlagContainer();
}
Live Demo