Conflicto entre un espacio de nombres y una definición

Question

Tengo este grave problema. Tengo una enumeración dentro de 2 espacios de nombres como esto:

namespace FANLib { 
namespace ERROR { 

    enum TYPE { 

     /// FSL error codes 
     FSL_PARSER_FILE_IERROR,... 

y otra parte de mi código, utilizar de esta manera:

FANLib::Log::internalLog(FSLParser::FILE_IERROR, file_ierror, true, FANLib::ERROR::FSL_PARSER_FILE_IERROR); 

Todo compila bien y bien, pero si resulta que incluyen " windows.h ", obtengo errores! El problema está en "WinGDI.h" que tiene esta línea:

#define ERROR    0 

y hace que el compilador piensa que, después de FANLib :: ..., hay un cero! El error que consigo es:

de error 1 C2589 de error: 'constante': token ilegal en el lado derecho de la '::'

error 2 error C2059: error de sintaxis: '::'

error 3 error C2039: 'FSL_PARSER_FILE_IERROR': no ​​es un miembro de '`espacio de nombres global''

¿hay algo que pueda hacer al respecto, sin tener que cambiar mis espacios de nombres debido a algún imprudente #define? He leído en otra publicación que podría #undef ERROR, pero ¿qué tan seguro es eso?

Answer 1

Generalmente, debe evitar el uso de identificadores de mayúsculas, ya que se utilizan para las macros. En este caso, cambiaría el nombre del espacio de nombres.

(Como nota al margen, <windows.h>#define s otras cosas como GetPrinter y de hecho se vuelve molesto. Yo suelo ir con #undef a continuación. También ayuda para incluir sólo <windows.h> en archivos .cpp y asegurarse el ámbito afectado por la cabecera es lo más pequeño posible.)

Answer 2

Creo que no será un problema si #desdef. Pero tendrías que hacerlo en cualquier lugar donde uses tanto tu enum & windows.h. Lo mejor sería cambiar el nombre de tu espacio de nombres.

Answer 3

Cambiar el nombre de su espacio de nombres es la solución más limpia, más segura y más interoperable.

Answer 4

Saltando en el vagón de "cambiar el nombre de tu espacio de nombres", simplemente porque ERROR es un nombre demasiado común y vago. Encuentra algo más descriptivo.

Answer 5

Es posible que desee refactorizar su código para que ese #include solo aparezca cuando sea necesario. La forma "correcta" puede incluso implicar la creación de archivos y encabezados separados que incluyen interfaces con las funciones a las que llamará desde windows.h

Sin embargo, si solo quiere una solución simple y le preocupan los efectos secundarios de #undef ERROR , acaba de redefinir el error después de que haya terminado con su nulidad:

 
#undef ERROR 
namespace ERROR { 
#define ERROR 0 

que tendría que hacer este error cada vez que se conoce (y no en una cadena).

Habiendo dicho eso, debería estar bien si simplemente no define ERROR. Solo afectaría cómo el preprocesador C maneja ERROR (o más bien cómo no) desde ese punto en adelante.

Por cierto, generalmente he visto nombres en mayúsculas que solo se usan para especificar constantes, no para tipos y espacios de nombres. Me reconsiderar mi convención de nomenclatura si fuera tú ..

Answer 6

La mejor solución es cambiar el esquema de denominación para evitar todo en mayúsculas, como han sugerido otros:

namespace FANLib { 
    namespace Error { 
    enum Type { 
     /// FSL error codes 
     FSL_Parser_File_IError, ... 

también fuera de los límites: identificadores que comienza con _ o __. (Es más complicado que eso, pero su vida será más simple si solo evita todos los nombres que comiencen con un guión bajo)

Answer 7

Si no usa GDI, puede definir NOGDI para suprimir las macros de definición en WinGDI.h. Here puede encontrar otras opciones útiles.

Answer 8

Los identificadores que comienzan con E y un dígito o E y una letra en mayúscula se deben tratar como reservados, ya que tales nuevas macros podrían agregarse al <errno.h>.