2009-07-03 16 views
5

Es difícil encontrar un título adecuado para este problema. De todos modos ...Biblioteca de otros #define conflicto de nombres

Actualmente estoy trabajando en un GUI para mis juegos en SDL. He terminado el dibujo del software y estaba en camino de comenzar con la parte OpenGL cuando surgió un error extraño. Incluí el encabezado "SDL/SDL_opengl.h" y compilo. Lanza el "error C2039: 'DrawTextW': no ​​es miembro de 'GameLib :: FontHandler'", que es un error bastante simple, pero no tengo nada llamado DrawTextW, solo FontHandler :: DrawText. ¡Busco DrawTextW y lo encuentro en una llamada #define en el encabezado "WinUser.h"!

//WinUser.h 
#define DrawText DrawTextW 

Al parecer Sustituye mi DrawText con DrawTextW! ¿Cómo puedo evitar que se desborde en mi código de esa manera?

Es una cosa menor que cambia el nombre de mi propia función, pero conflictos de nombres como éste parece bastante peligroso y realmente me gustaría saber cómo evitar todos juntos.

¡Salud!

Respuesta

9

Usted tiene un par de opciones, todas las cuales chupar.

  • Añadir #undef DrawText en su propio código
  • No incluya windows.h. Si otra biblioteca lo incluye, no lo incluya directamente. En su lugar, inclúyalo en un archivo .cpp separado, que luego puede exponer sus propias funciones de contenedor en su encabezado.
  • Cambie el nombre de su propio DrawText.

Cuando sea posible, suelo elegir la opción del medio. windows.h se comporta mal en innumerables otras formas (por ejemplo, en realidad no compila a menos que habilite las extensiones propietarias de C++ de Microsoft), así que simplemente lo evito como la peste. No se incluye en mis archivos si puedo evitarlo. En su lugar, escribo un archivo .cpp separado para contenerlo y exponer la funcionalidad que necesito.

Además, siéntase libre de enviarlo como un error y/o comentario en connect.microsoft.com. Windows.h es un encabezado mal diseñado criminalmente, y si la gente atrae la atención de Microsoft sobre él, hay (escasas) posibilidades de que algún día lo solucionen.

La buena noticia es que windows.h es el único encabezado que se comporta de esta manera.Otros encabezados generalmente intentan prefijar sus macros con algún nombre específico de biblioteca para evitar colisiones de nombres, intentan evitar la creación de macros para nombres comunes e intentan evitar el uso de más macros de los necesarios.

+0

Sí, Windows.h sí colisiona. Supongo que es justo quejarse de que no se compila sin las extensiones ms habilitadas, pero también es razonable que un encabezado específico de ms deba (requiera esas extensiones). – bobobobo

5

Es un desafortunado efecto secundario de #include ing <windows.h>. Suponiendo que usted no está realmente el uso de Windows' DrawText() cualquier parte de su programa, que es perfectamente seguro para #undef inmediatamente después:

// wherever you #include <windows.h>, or any other windows header 
#include <windows.h> 
#undef DrawText 
+0

Gracias! Se compila bien ahora. Un efecto secundario bastante molesto de hecho. Parece que el SDL_opengl.h incluye el windows.h, pero el #undef hace su trabajo. ¿Se podría haber escrito windows.h de manera diferente para evitar este problema? – Zoomulator

+1

Podría. Pero eso requeriría que a Microsoft le importe. – jalf

+1

@jalf Debes considerar las cosas en contexto. Esa API tiene más de 30 años, ¿qué espera que haga Microsoft? Romper la compatibilidad? Mira el blog de Raymond Chen en algún momento y comenzarás a entender por qué la programación para Windows es tan dolorosa a veces y por qué muchas cosas no se pueden arreglar solo. – minexew

4

No hay forma general de evitar este problema - una vez que #Include un archivo de cabecera mediante el preprocesador puede redefinir cualquier nombre que quiera, y no hay nada que pueda hacer al respecto. Puede #undef el nombre, pero eso supone que usted sabe que el nombre fue #definido en primer lugar.

0

Solo #undef los símbolos que no desea. Pero asegúrese de que incluye windows.h y hacer esto antes de incluir SDL:

#include <windows.h> 
#undef DrawText 

#include <SDL/SDL_opengl.h> 
Cuestiones relacionadas