Si lo desea, puede imaginar que C ++ genera un typedef para cada nombre de etiqueta, como
typedef class string string;
Desafortunadamente, esto no es del todo exacto. Desearía que fuera así de simple, pero no lo es. C ++ no puede generar tales typedefs para estructuras, uniones o enumeraciones sin introducir incompatibilidades con C.
Por ejemplo, supongamos que un programa en C declara tanto una función como una estructura denominada estado:
int status(); struct status;
Nuevamente, esto puede ser una mala práctica, pero es C. En este programa, el estado (por sí mismo) se refiere a la función; El estado de la estructura se refiere al tipo.
Si C ++ generó automáticamente typedefs para etiquetas, cuando compiló este programa como C ++, el compilador generaría:
typedef struct status status;
Desafortunadamente, este nombre de tipo entraría en conflicto con el nombre de la función y el programa no se compilaría. Es por eso que C ++ no puede simplemente generar un typedef para cada etiqueta.
En C ++, las etiquetas actúan como los nombres typedef, excepto que un programa puede declarar un objeto, función o enumerador con el mismo nombre y el mismo alcance que una etiqueta. En ese caso, el nombre del objeto, función o enumerador oculta el nombre de la etiqueta. El programa puede hacer referencia al nombre de la etiqueta solo mediante el uso de la palabra clave class, struct, union o enum (según corresponda) delante del nombre de la etiqueta. Un nombre de tipo que consta de una de estas palabras clave seguido de una etiqueta es un especificador de tipo elaborado. Por ejemplo, el estado de la estructura y el mes de enumeración son especificadores de tipo elaborado.
Por lo tanto, un programa en C que contiene ambos:
int status(); struct status;
se comporta igual cuando se compila como C ++. El estado del nombre solo se refiere a la función. El programa solo puede referirse al tipo utilizando el estado de estructura del especificador de tipo elaborado.
Entonces, ¿cómo permite esto que los errores entren en los programas? Considere el programa en el
Listado 1 . Este programa define una clase foo con un constructor predeterminado y un operador de conversión que convierte un objeto foo en char const *. La expresion
p = foo();
en main debe construir un objeto foo y aplicar el operador de conversión. La siguiente declaración de salida
cout << p << '\n';
debería mostrar class foo, pero no lo hace. Muestra la función foo.
Este sorprendente resultado ocurre porque el programa incluye el encabezado lib.h que se muestra en el Listado 2 . Este encabezado define una función también llamada foo. El nombre de la función foo oculta el nombre de la clase foo, por lo que la referencia a foo en main se refiere a la función, no a la clase. main solo puede referirse a la clase utilizando un especificador de tipo elaborado, como en
p = class foo();
La forma de evitar tal confusión en todo el programa es agregar el siguiente typedef para el nombre de clase foo:
typedef class foo foo;
inmediatamente antes o después de la definición de clase. Este typedef causa un conflicto entre el nombre de tipo foo y el nombre de función foo (de la biblioteca) que desencadenará un error en tiempo de compilación.
No conozco a nadie que realmente escriba estos typedefs como algo natural. Requiere mucha disciplina. Dado que la incidencia de errores como el del Listado 1 es probablemente bastante pequeña, es posible que nunca se enfrente a este problema. Pero si un error en su software puede causar lesiones corporales, entonces debe escribir los typedefs sin importar cuán improbable sea el error.
No puedo imaginar por qué alguien querría ocultar un nombre de clase con una función o un nombre de objeto en el mismo ámbito que la clase. Las reglas de ocultación en C fueron un error, y no deberían haberse extendido a las clases en C ++. De hecho, puede corregir el error, pero requiere una disciplina de programación adicional y un esfuerzo que no debería ser necesario.