none
variable "GLuint" is not a type name RRS feed

  • Pregunta

  • éste es el cuento: tengo un proyecto que hasta ahora compila y funciona usando mingw, y la idea es que compile correctamente en la mayoría de compiladores de c, que para eso se hizo en c. Para verificarlo en visual c++ no simplemente trasteé todos los archivos y lo puse a correr, sino que estoy trasteando de a uno, para que si hay errores no me salga toda una retahila, sino que sepa dónde están los errores en una forma manejable

    El proyecto usa OpenGL (ver. 1, sin cosas raras), y aunque por lo menos compila y sale un resultado más o menos dentro de lo esperado, precisamente como estoy trasteando un archivo a la vez, lo que tengo por ahora no es lo que muestra todo el proyecto sino un chasis con algo básico. Aunque el proyecto con lo más básico compila y corre, me indica que hay varios errores en 'gl.h', que ni siquiera la hice yo sino que es la que viene incluída como parte de la librería de visual studio; en todo caso, nuevamente, compila y corre sin problema por ahora

    Cuando empiezo a meter mis archivos (que compilan sin problema en mingw), entre los primeros está éste, que es un archivo intermedio en donde se declaran funciones que dependen de cada plataforma; esto para que cuando lo trastee a otra plataforma no toque hacer cambios por todo el código sino que los cambios se hagan en un sólo archivo (toca modificar el cpp, pero muestro el .h que es el que importa para el error)

    #ifndef def_middleware_menu
    #define def_middleware_menu
    
    #include <gl/gl.h> // si no no sabe qué es GLuint
    
    //#include <time.h>
    
    #include "definiciones.h"
    
    // para debug, mientras no se pueda cambiar tamaño de ventana
    #define dbg_ancho_ventana 950
    #define dbg_alto_ventana 450
    
    bool dimensiones_ventana(uint16 &_ancho, uint16 &_alto);
    
    bool obtener_directorios(char *_programa, char *_docs, char *_error);
    
    bool cargar_textura(const char *_nom_archivo, GLuint &_tex);
    
    uint32 obtener_ms(); // obtener referencia de tiempo en milisegundos
    
    void pausa_ms(uint16 _ms); // pausa de _ms milisegundos
    
    #endif


    en el archivo llamado middleware.h, notar que hay una declaración que dice

    bool cargar_textura(const char *_nom_archivo, GLuint &_tex);

    y que usa un tipo 'GLuint', que es algo que se declara en gl/gl.h, y que al principio del módulo dice #include <gl/gl.h>. no saca error ni tendría por qué sacarlo.

    Pero como mencioné al principio estoy metiendo los demás archivos poco a poco, y uno de los que siguió fue éste:

    #include "middleware.h"
    #include <gl/gl.h>
    
    #define frames frames_activos()
    #define id_tex id_textura()
    
    
    
    using namespace std;
    
    class sprite_menu {
        
        private:
            
            // 1: no se pudo cargar textura
            // 2: parámetros incorrectos
            static uint32 codigo_error;
            
            // id de textura
            GLuint textura;
            
            // la forma como están organizados los frames en el dibujo
            ubyte frames_ancho;
            ubyte frames_alto;
            // no tiene qué ser un múltiplo exacto; puede que haya menos frames que el total de filas y columnas
            uint16 total_frames;
            
            // tamaño de cada frame dentro de la textura; no recalcular cada vez
            float32 ancho_frame;
            float32 alto_frame;
            
            // tamaño proporcional de cada frame con respecto a pantalla
            float32 proporcion_ancho;
            float32 proporcion_alto;
            
        public:
            
            static uint32 ultimo_error();
            static ofstream *debug;
            
            uint16 frames_activos(); // no es inline porque usa miembros privados y se llamarían desde otros módulos
            
            GLuint id_textura();
            
            frame_menu frame(uint16 _num_frame);
            
            // _fr_ancho y _fr_alto es el número de frames a lo largo y ancho en la textura
            // _total_fr es el número de recuadros útiles. No necesariamente son alto * ancho; p. ej puede ser 5 de ancho por 5 de alto (= 25),
            // pero de esos 25 sólo interesan 21, 22 o 23
            // _ancho_pantalla y _alto_pantalla son las proporciones que debe ocupar cada recuadro en pantalla, relacionado con aspect
            sprite_menu(const char *_nom_archivo, ubyte _fr_ancho, ubyte _fr_alto, uint16 _total_fr, float32 _ancho_pantalla, float32 _alto_pantalla);
            sprite_menu(sprite_menu *_sprite, ubyte _fr_ancho, ubyte _fr_alto, uint16 _total_fr, float32 _ancho_pantalla, float32 _alto_pantalla);
            ~sprite_menu();
        
    }; // class
    
    
    // ------
    
    #endif

    sin compilar, sino revisando el archivo en edición me marca como error las variables de tipo GLuint y me dice que GLuint no es un tipo; eso pese a que en el encabezado del archivo está la línea #include "middleware.h", y middleware.h a su vez incluye gl/gl.h como se mostró en el primer bloque de código. Aunque no debería hacer diferencia, debido al error en ese mismo archivo puse la línea #include <gl/gl.h> y sigue marcando error enlas variables de tipo GLuint que porque eso no es un tipo de variable. Aún así compila porque al ir probando poco a poco todavía no se ha llamado sprite_menu en el bloque de código que ejecuta, pero cuando le digo agregar al proyecto el cpp de ese mismo módulo, ahí sí genera una lista de errores que no lo deja correr, así todavía no se esté llamando desde el código que sí ejecuta. Nuevamente, el cpp es código que compila y corre en mingw sin generar error

    Alguien tiene una explicación de por qué carajos sigue saliendo que GLuint no es un tipo válido así esté declarado en gl/gl.h que no es una librería que yo haya hecho sino que es del mismo sistema, que viene con su include detro del módulo donde se genera el error y que corre sin problema en otros compiladores de c++?

    viernes, 31 de julio de 2020 23:36

Todas las respuestas

  • Hola

      

    Gracias por levantar tu consulta en los foros de MSDN. Entendimos su pregunta y vamos a darle seguimiento para buscar la mejor repuesta pertinente al caso.  

    Cualquier duda referente a productos Microsoft, puedes consultarnos. Es un gusto informarte. 

    Gracias por usar los foros de MSDN.   

    Eric Ruiz

     ____________________________ 

      

    Por favor recuerde "Marcar como respuesta" las respuestas que hayan resuelto su problema, es una forma común de reconocer a aquellos que han ayudado, y hace que sea más fácil para los otros visitantes encontrar la solución más tarde.  

    Microsoft ofrece este servicio de forma gratuita, con la finalidad de ayudar a los usuarios y la ampliación de la base de datos de conocimientos relacionados con los productos y tecnologías de Microsoft.   

    Este contenido es proporcionado "tal cual" y no implica ninguna responsabilidad de parte de Microsoft. 

    sábado, 1 de agosto de 2020 0:57
    Moderador
  • actualización: hice algunos ensayos, tales como tachar (marcar como comentario) todo el código de manera que si se generaba un error no fuera por la sintaxis. Incluí en el proyecto el mismo archivo que sin ese archivo generaba error cuando quedaba incluído, pero con el código tachado, y aún así genera el error, de manera que entiendo que no es por el contenido del archivo; por otro lado hice un ensayo sólo para verificar la sintaxis. Iniciar un proyecto completamente nuevo, sin nada que yo le haya agregado, generado a partir de las plantillas que el mismo visual propone

    Estando el proyecto recién generado se incluyen estas dos líneas:

    #include <gl/GL.h>
    #include <gl/GLU.h>

    y con sólo ese cambio ya no compila, y reporta más de 900 errores por cosas en el archivo gl.h, de la misma librería del visual. Es decir que volvieron a la política de sabotear el OpenGL para forzar que la gente use directx. Pensé que eso lo habían dejado atrás en las primeras versiones, y que por algo habían decidio que el visual c usara c estándard en vez de inventarse sus proias sintaxis, ya que si la gente tiene que reescribir los programas para cada plataforma pues simplemente excluye esas plataformas, pero no aprendieron. Devolviéndome al Android NDK y a Mingw; suerte visual, que lo usaré de vez en cuando para c# (posiblemente)

    jueves, 6 de agosto de 2020 20:31