gl.h включен до glew, но GLFW нуждается в gl.h

#c #opengl #glew #glfw

Вопрос:

Я помню, что способ упорядочивания ваших #include-ов имеет значение. Что ж, у меня небольшие проблемы. У меня есть эти два заголовка:

 #include <gl/glfw.h>
#include <gl/glew.h>

Если я запускаю это, я получаю сообщение об ошибке, в котором говорится, что gl.h включен перед glew.h . Но если я поменяю порядок этих двух так, чтобы glew.h был первым, я получу МНОГО ошибок. Я просто думал о том, чтобы выяснить, что означают #define-s, чтобы я мог просто сказать за себя: #define что означает 0x0000x.

Как я могу исправить эту проблему с расположением заголовков.
Безопасен ли метод поиска и создания моих определений?

1. Ты не это имеешь в виду #include <glfw.h> ?

2. нет, мой файл glfw.h находится в папке gl /

3. Я неправильно выразился, я хотел сказать #include <gl/glfw.h> . Необходимо поставить .h в конце, IIRC

4. Я только что исправил это. Спасибо за предупреждение. 🙂 Вы случайно не знаете ответ?

Ответ №1:

Какие ошибки вы получаете, когда сначала включаете заголовок GLEW?

Заголовок GLEW определяет всю магию, необходимую для отключения включения большинства заголовков GL, поэтому включение заголовка GLEW перед заголовком GLFW должно сработать; должно, поскольку я успешно использовал это в течение ряда лет в Linux, Windows и Mac OS X с собственным GCC, Clang, MinGW, Cygwin и VC . Это даже официальный FAQ:

http://www.glfw.org/faq.html#can-i-use-extension-loaders-with-glfw

1. Вы добавили свою собственную версию заголовка GLU? В моей установке VS 10 нет заголовка GLU в этом месте. В любом случае, вы можете отключить включение заголовка GLU с помощью GLFW_NO_GLU.

Ответ №2:

Основная проблема заключается в том, что glfw.h имеет явную проверку, чтобы проверить, был ли gl.h уже включен, и завершится неудачей, если это произошло, вместо того, чтобы просто продолжать игнорировать эту «ошибку». В итоге я просто прокомментировал этот фрагмент кода из заголовка в моей версии библиотеки.