"Backporting" nullptr a C++ - programas pre-C++ 0x

Question

Más o menos lo que sugiere el título. Mientras estoy en not yet using C++0x me gustaría estar preparado para cuando suceda, y también me gustaría reducir la cantidad de código que tengo que reescribir para usar algunas de sus instalaciones. De esa forma puedo avanzar y retroceder la compatibilidad de una vez.

Una de las más interesantes que he encontrado es nullptr, que he estado usando más a menudo recientemente.

Después de comprobar la "Solución oficial" y Meyer's suggestion, decidí que me gustaría utilizar esto en mis programas C++ y C++ 0x futuros. La segunda parte es simple: al ser una palabra clave, solo se admitirá el nullptr. Pero la primera parte me está causando cierta incomodidad.

El Meyers funciones propuesta como esta:

class nullptr_t { // ← this is my issue 
    // definition of nullptr_t 
} nullptr = { }; 

El problema con esta propuesta es que se declara el tipo de ser declarada como std::nullptr_t como es requerido por C++ 0x. Lo que significa que la solución para "sentirse nativo" tiene que hacerse volviendo a abrir el espacio de nombres std:: para agregar un tipo. Tengo el entendimiento de que es ilegal hacer en un programa de C++ (a diferencia de agregar especializaciones que aparentemente parece fruncir-y-dejar-ir-con-una-advertencia).

Quiero usar nullptr en una cómoda forma Y legal en un programa en C++. Una de las opciones que había pensado en declarar fue el tipo en otro espacio de nombres y luego llevarlo en el uso de using:

namespace mylibrary { 
class nullptr_t { 
    .... 
} nullptr = { }; 
// end namespace 
} 

// These would have to go in the header file. 
using mylibrary::nullptr; 
using mylibrary::nullptr_t; // apparently this is necessary as well? 

sería este el camino correcto para hacer que funcione? Obligaría a las directivas using, lo que también obliga a un orden específico de directivas #include. ¿Tendría razón al esperar que ningún código pre-C++ 0x solicite el tipo nullptr_t con espacio de nombres (como un tipo de argumento de función, por ejemplo)? ¿Funcionaría realmente "sentirse nativo" si se hace de esta manera?

---

Como una adición, es una bienvenida o mal visto que hay que tratar de acondicionarlo alguna ingeniosa C++ 0x cosas a C++ para una mejor compatibilidad y la codificación? Mientras tanto, he integrado esta solución y otras en las que estoy trabajando en in a piece of software to be released.

Answer 1

La razón principal por la que no se le permite añadir cosas a namespace std no es por lo que desordenar las cosas que ya están allí. Esto de otra manera podría hacerse fácilmente. Algo que encontré en el pasado fueron definiciones múltiples para operadores de salida para contenedores instanciados con un tipo incorporado como std::vector<int>. Sin embargo, nullptr_t no está definido en este espacio de nombres y agregar un typedef debería ser bastante inofensivo. Es decir, definiría nullptr_t en un espacio de nombre diferente que namespace std y luego agregaría un typedef para nullptr_t a namespace std. La variable nullptr debe declararse en el ámbito global de todos modos, ya que se utiliza sin reservas en C++ 2011.

Si se necesita el tipo std::nullptr_t depende de si le interesa agregar las firmas con este tipo. Por ejemplo, std::shared_ptr<T> se puede comparar con nullptr. Para esto, es necesario agregar sobrecargas adecuadas que mencionen el tipo std::nullptr_t (o utilizar algún otro nombre para este tipo).

Answer 2

menos que se puede pensar en una razón tiene que declarar otra objeto de tipo nullptr_t (no puedo), me escondía el tipo de distancia y poner nullptr en el espacio de nombres global para imitar una palabra clave lo más cerca posible :

namespace mylibrary 
{ 
    class nullptr_t 
    { 
     .... 
    }; 
} 

mylibrary::nullptr_t nullptr = { };