estilo al vincular una referencia a objeto-o-dummy

Question

¿Cuál es la mejor manera de enlazar una referencia rvalue a un objeto dado o una copia temporal del mismo?

A &&var_or_dummy = modify? static_cast<A&&>(my_A) 
         : static_cast<A&&>(static_cast<A>(my_A)); 

(Este código no funciona en mi reciente GCC 4.6 ... Recuerdo que funcione antes, pero ahora siempre devuelve una copia.)

En la primera línea, la static_cast transforma my_A de una lvalue a un xvalor. (C++ 0x §5.2.9/1-3) El static_cast interno en la segunda línea realiza la conversión lvalue-a-rvalue, y el externo obtiene un valor x de este prvalue.

Esto parece ser compatible porque la referencia nombrada está vinculada condicionalmente al temporal según §12.2/5. El mismo truco funciona de la misma manera en C++ 03 con una referencia const.

también puedo escribir la misma cosa menos verbosidad:

A &&var_or_dummy = modify? std::move(my_A) 
         : static_cast<A&&>(A(my_A)); 

Ahora es mucho más corto. La primera abreviatura es cuestionable: se supone que move indica que algo le está sucediendo al objeto, no una mera combinación de valor lvalue-a-xvalor-a-valor. Confusamente, move no se puede usar después del : porque la llamada a la función interrumpiría el enlace temporal a referencia. La sintaxis A(my_A) es quizás más clara que la static_cast, pero es técnicamente equivalente a un modelo de estilo C.

también puedo ir hasta el final y escribir por completo en C-estilo arroja:

A &&var_or_dummy = modify? (A&&)(my_A) : (A&&)(A(my_A)); 

Después de todo, si esto va a ser un idioma, debe ser conveniente, y no es static_cast realmente protegiéndome de cualquier cosa de todos modos: el peligro real es no vincular directamente al my_A en el caso true.

Por otro lado, esto fácilmente se ve dominado por el nombre de tipo repetido tres veces. Si A fuera reemplazado por una plantilla grande y fea, realmente querría un atajo real.

(Tenga en cuenta que V se evalúa sólo una vez a pesar de aparecer cinco veces :)

#define VAR_OR_DUMMY(C, V) ((C)? \ 
    static_cast< typename std::remove_reference< decltype(V) >::type && >(V) \ 
: static_cast< typename std::remove_reference< decltype(V) >::type && > ( \ 
    static_cast< typename std::remove_reference< decltype(V) >::type >(V))) 

hacker como macros son, creo que es la mejor alternativa del montón. Es un poco peligroso porque devuelve un valor x, por lo que no debe usarse fuera de la inicialización de referencia.

Debe haber algo en lo que no haya pensado ... ¿sugerencias?

Answer 1

Sólo evitar todo este lío con una llamada a la función adicional:

void f(bool modify, A &obj) { 
    return [&](A &&obj) { 
    real(); 
    work(); 
    }(modify ? std::move(obj) : std::move(A(obj))); 
} 

En lugar de:

void f(bool modify, A &obj) { 
    A &&var_or_dummy = /* ??? */; 
    real(); 
    work(); 
} 

¡Es lambdas, lambdas, everywhere!

Answer 2

Veo dos problemas con su enfoque.

que se basan en el comportamiento

int i = 0; 
int& j = true?  i :  i; 
int&& k = true? move(i) : move(i); 
assert(&i == &j); // OK, Guaranteed since C++98 
assert(&i == &k); // Does this hold as well? 

El actual proyecto de norma N3126 contiene 5.16/4:

Si el segundo y tercer operandos [al operador condicional] son ​​glvalues ​​de la misma categoría de valor y tienen el mismo tipo, el resultado es de ese tipo y valor de categoría

lo que me hace pensar que las dos afirmaciones anteriores deben mantenerse. Pero usando GCC 4.5.1 el segundo falla. Creo que esto es un error de GCC.

Además, usted confía en el compilador para extender el tiempo de vida del objeto temporal se refiere a y en el siguiente ejemplo:

A func(); 

A&& x = func();     // #1 
A&& y = static_cast<A&&>(func()); // #2 

x no va a ser una referencia colgando pero no estoy tan seguro sobre y. Creo que la regla sobre extender la vida útil de los temporales se supone que solo se aplica en los casos en que las expresiones del inicializador son puros rvalues. Al menos, esto simplificaría en gran medida la implementación. Además, GCC parece estar de acuerdo conmigo en este caso. GCC no extiende la vida útil del objeto temporal A en el segundo caso. Este sería un problema de referencia colgante en su enfoque .

Actualización: De acuerdo con 12.2/5, se supone que las vidas de los objetos temporales se extienden en ambos casos, # 1 y # 2. Ninguno de los puntos en la lista de excepciones parece aplicarse aquí. Una vez más, GCC parece tener errores en este sentido.

Una solución fácil para el problema sería:

vector<A> tempcopy; 
if (!modify) tempcopy.push_back(myA); 
A& ref = modify ? myA : tempcopy.back(); 

Alternativly, se podría utilizar un impulso :: scoped_ptr en lugar de un vector.

Answer 3

El problema de la seguridad de xvalue puede solucionarse en cierta medida al proporcionar una alternativa para el uso dentro de expresiones. Los temas son completamente diferentes, ahora No quieren un resultado xValue y podemos usar una función:

template< typename T > 
T &var_or_dummy(bool modify, T &var, T &&dummy = T()) { 
    if (modify) return var; 
    else return dummy = var; 
} 

    maybe_get_result(arg, var_or_dummy(want_it, var)); 

Ahora el tipo tiene que ser predeterminado Urbanizable, y el maniquí se construye siempre. La copia se evalúa condicionalmente. No creo que realmente quiera lidiar con el código que hizo demasiado de esto.

Boost Optional pueden ayudar un poco; Sólo se requiere CopyConstructible T:

template< typename T > 
T &var_or_dummy(bool modify, T &var, 
       boost::optional<T> &&dummy = boost::optional<T>()) { 
    if (modify) return var; 
    else return dummy = var; 
} 

opcional es útil, pero tiene cierta superposición con las uniones C++ 0x. No es demasiado difícil de reimplementar.

template< class T > 
struct optional_union { 
    bool valid; 
    union storage { 
     T obj; // union of one non-POD member simply reserves storage 

     storage() {} // uh, what could the constructor/destructor possibly do?? 
     ~storage() {} 
    } s; 

    optional_union() : valid(false) {} 
    optional_union &operator=(T const &in) { 
     new(&s.obj) T(in); // precondition: ! valid 
     valid = true; 
     return *this; 
    } 
    ~optional_union() 
     { if (valid) s.obj.~T(); } 
}; 

template< typename T > 
T &var_or_dummy(bool modify, T &var, 
       optional_union<T> &&dummy = optional_union<T>()) { 
    if (modify) return var; 
    else return (dummy = var).s.obj; 
} 

La clase optional_union sólo es suficiente para esta aplicación ... es obvio que se podría ampliar mucho.