2011-06-07 18 views
5

Me cansé de esperar la compatibilidad del compilador de nullptr (gcc 4.6 does pero son tan pocas las nuevas distribuciones que lo admiten).Perfectamente emular nullptr

Por lo tanto, como un espacio de detención hasta nullptr es totalmente compatible, decidí emularlo. Hay dos ejemplos de emulación: uno de here, y uno de wikibooks.

De nota, ninguna implementación menciona un operator ==. Sin embargo, sin uno, el siguiente código will not compile.

int* ptr = nullptr; 
assert(ptr == nullptr); // error here: missing operator == 

¿Es este error operator == un error del compilador?
Es operator == (y !=, <, <=, etc.) necesarios para emular más perfectamente nullptr?
¿Qué más es diferente entre un emulado nullptr y el verdadero?

+2

¿Por qué harías esto en vez de 'assert (ptr);' en primer lugar? – ildjarn

+0

@Neil Butterworth: Eso no es verdad. 'nullptr' tiene que ser parte del Estándar porque solo tiene valor cuando todos usan el mismo tipo de puntero nulo -' std :: nullptr_t'. Si todos implementaran su propio puntero nulo, ¿cómo escribirías una función que aceptaría un puntero nulo? No sabe cuál es el tipo de puntero nulo. – Puppy

+0

@ildjarn: utilicé una afirmación para limpiar el código. Mi ejemplo real era 'std :: remove (v.begin(), v.end(), nullptr);' que usa el operador de igualdad. Y la razón por la que no usaré 'std :: remove_if' es que no quiero. Quiero que funcione como el verdadero 'nullptr'. –

Respuesta

2

Lo compiló con el compilador C++ 0x que falló por algún motivo desconocido. Es compiles fine in C++03.

+0

Entonces, volviendo a mi pregunta original. ¿Es este error un efecto de las nuevas reglas de lenguaje C++ 0x? ¿O es un error que se introdujo en gcc cuando se agregaron las otras características de C++ 0x? –

+2

@deft_code: 1) su código es inválido C++ 0x porque usa la palabra clave nullptr. 2) Estoy 90% seguro de que es un error de GCC 3) ya había un [error similar] (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990). – ybungalobill

+0

Gran hallazgo con ese error. Mi [caso de error exacto] (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990#c4) aparece en los comentarios. En respuesta al punto 1, tengo que decir _no duh! _ Obviamente no es válido en un compilador C++ 0x totalmente compatible. gcc 4.5 aún no es totalmente compatible y, por lo tanto, necesito emular una palabra clave. –

1

Sí, debe implementar tal cosa. Sin embargo, estoy sorprendido de que los operadores de conversión implícitos no estén dando el puntapié inicial y que le permitan comparar sin proporcionar un operador explícito.

template<typename T> bool operator==(T* ptr, nullptr_t null) { 
    return ptr == 0; 
} 
template<typename C, typename R> bool operator==(R C::* ptr, nullptr_t null) { 
    return ptr == 0; 
} 
// And the reverse 
1

De hecho, es mencionado en la propuesta oficial de su primer ejemplo de referencia:

Los experimentos con varios compiladores populares existentes muestran que genera o engañosas diagnósticos insuficientes y/compilador para varios de los casos de uso común descritos en sección 2. (Los ejemplos incluyen: "no conversión de" const "a" int ""; "no función de conversión adecuada de" const la clase "a" int " existe"; "Un argumento de plantilla no puede hacer referencia a un tipo sin nombre"; “No operador“== "coincide con estos operandos, tipos de operando son: int == clase const ”) Creemos que los compiladores todavía tendrá que añadir conocimiento especial de nullptr con el fin de proporcionar tics calidad diagnosticable para . casos de uso común.

Por lo tanto, debe llenar este vacío si el compilador aún no lo hace.

+0

Esa discusión de diagnóstico de compilador deficiente es en referencia a un tipo 'nullptr' sin nombre. Sin embargo, el comité de estándares decidió que 'nullptr' tendría el tipo' nullptr_t'.Todos esos mensajes de error crípticos mejoran mucho cuando la clase 'nullptr' se llama' nullptr_t'. –

+0

@deft_code - Entonces, ¿cuál es el problema? – littleadv