Disable copy elision in C++ - c++

Question

Disclaimer: Goal of research is how to disable copy elision and return value optimization for supplied part of code. Please avoid from answering if want to mention something like XY-problem. The question has strictly technical and research character and is formulated strongly in this way
In C++14 there was introduced copy elision and return value optimization. If some object had been destructed and copy-constructed in one expression, like copy-assignment or return immediate value from function by value, copy-constructor is elided.
Following reasoning is applied to copy constructor, but similar reasoning can be performed for move constructor, so this is not considered further.
There are some partial solutions for disabling copy elision for custom code:
1) Compiler-dependent option. For GCC, there is solution based on __attribule__ or #pragma GCC constructions, like this https://stackoverflow.com/a/33475393/7878274 . But since it compiler-dependent, it does not met question.
2) Force-disabling copy-constructor, like Clazz(const Clazz&) = delete. Or declare copy-constructor as explicit to prevent it's using. Such solution does not met task since it changes copy-semantics and forces introducing custom-name functions like Class::copy(const Clazz&).
3) Using intermediate type, like describe here https://stackoverflow.com/a/16238053/7878274 . Since this solution forces to introduce new descendant type, it does not met question.
After some research there was found that reviving temporary value can solve question. If reinterpret source class as reference to one-element array with this class and extract first element, then copy elision will turned off. Template function can be written like this:
template<typename T, typename ... Args> T noelide(Args ... args) {
return (((T(&)[1])(T(args...)))[0]);
}
Such solution works good in most cases. In following code it generates three copy-constructor invocations - one for direct copy-assignment and two for assignment with return from function. It works good in MSVC 2017
#include <iostream>
class Clazz {
public: int q;
Clazz(int q) : q(q) { std::cout << "Default constructor " << q << std::endl; }
Clazz(const Clazz& cl) : q(cl.q) { std::cout << "Copy constructor " << q << std::endl; }
~Clazz() { std::cout << "Destructor " << q << std::endl; }
};
template<typename T, typename ... Args> T noelide(Args ... args) {
return (((T(&)[1])(T(args...)))[0]);
}
Clazz func(int q) {
return noelide<Clazz>(q);
}
int main() {
Clazz a = noelide<Clazz>(10);
Clazz b = func(20);
const Clazz& c = func(30);
return 0;
}
This approach works good for a and b cases, but performs redundant copy with case c - instead of copy, reference to temporary should be returned with lifetime expansion.
Question: how to modify noelide template to allow it work fine with const lvalue-reference with lifetime expansion?
Thanks!

Answer 1

According to N4140, 12.8.31:
...
This elision of copy/move operations, called copy elision, is
permitted in the following circumstances (which may be combined to
eliminate multiple copies):
(31.1) — in a return statement in a function with a class return type,
when the expression is the name of a non-volatile automatic object
(other than a function or catch-clause parameter) with the same
cv-unqualified type as the function return type, the copy/move
operation can be omitted by constructing the automatic object directly
into the function’s return value
(31.3) — when a temporary class object that has not been bound to a
reference (12.2) would be copied/moved to a class object with the same
cv-unqualified type, the copy/move operation can be omitted by
constructing the temporary object directly into the target of the
omitted copy/move
So if I understand it correctly, copy elision can only occur, if the return statement is a name of a local variable. So you can for example 'disable' copy elision by returning e.g. return std::move(value)... If you don't like using move for this, you can simply implement noelide as a static_cast<T&&>(...).

Answer 2

This is impossible to be done given all your restrictions. Simply, because the standard does not provide a way of turning off RVO optimizations.
You can prevent mandatory application of RVO by breaking one of the requirements, but you cannot reliably prevent optional allowed optimization. Everything you do is either changing semantics or compiler specific at this point (e.g. -fno-elide-constructors option for GCC and Clang).