Visual Studio 2022 и дефайны

@Optimus11 · Регистрация: 10.01.2017

Студворк — интернет-сервис помощи студентам

Здравствуйте,

Пытаюсь подключить библиотеку, но VisuaiStudio2022 упорно показывает непонятную мне ошибку:

Вот скриншот из студии:

http://file-st06.karelia.ru/64... studio.jpg

То есть в файле rglfw.c - определяется платформа и делается "#define _GLFW_WIN32".

В файле internal.h проверяется define и включается файл:

C++
1
2
3
#elif defined(_GLFW_WIN32)
 
 #include "win32_platform.h"

По цвету из скриншота видно, что определение прошло успешно, но студя упорно сообщает об ошибке "No supported window creation API selected", как будто бы не один из define`ов не прошел проверку:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
#if defined(_GLFW_COCOA)
 #include "cocoa_platform.h"
#elif defined(_GLFW_WIN32)
#include "win32_platform.h"
#elif defined(_GLFW_X11)
 #include "x11_platform.h"
#elif defined(_GLFW_WAYLAND)
 #include "wl_platform.h"
#elif defined(_GLFW_OSMESA)
 #include "null_platform.h"
#else
 #error "No supported window creation API selected"
#endif

Не понимаю, что дальше то делать ?

@TheCalligrapher · 15.03.2023, 20:04

Сообщение от Optimus11

То есть в файле rglfw.c - определяется платформа и делается "#define _GLFW_WIN32".
В файле internal.h проверяется define и включается файл:

Не понял. Каким образом заголовочный файл internal.h может знать, что там было сделано в обычном файле реализации rglfw.c? Почему вы ожидаете, что определение макроса в rglfw.c будет видно в internal.h? Как эти файлы вообще связаны между собой?

Сообщение от Optimus11

Вот скриншот из студии:

@Optimus11 · 15.03.2023, 20:09 **[ТС]**

Сообщение от TheCalligrapher

Не понял. Каким образом заголовочный файл internal.h может знать, что там было сделано в обычном файле реализации rglfw.c? Почему вы ожидаете, что определение макроса в rglfw.c как-то повлияет на internal.h? Как эти файлы вообще связаны между собой?

Прошу извинить я define`ы почти не использую и решил, что если define определён в одной файле, то о должен распространятся на другие.

Но тогда вопрос: а как вообще сработают проверки дефайнов в internal.h ? Нужно вручную дефайнить платформу получается ?

Добавлено через 51 секунду

Сообщение от TheCalligrapher

вот скриншот из студии

Там ссылка есть на большой размер.

@TheCalligrapher · 15.03.2023, 20:21

Сообщение от Optimus11

решил, что если define определён в одной файле, то о должен распространятся на другие.

В С и С++ ничего никуда никогда не "распространяется". В С и С++ все объявления видны только в одной единице трансляции, т.е. фактически в одном файле. Все, что определено в единице трансляции выше, будет видно в ней ниже. Больше ничего видно не будет.

Сообщение от Optimus11

Но тогда вопрос: а как вообще сработают проверки дефайнов в internal.h ? Нужно вручную дефайнить платформу получается ?

Это значит, что эти макросы должны быть определены (или не определены) в той в каждой единице трансляции отдельно еще до того, как будет включен internal.h. Такие глобальные настройки могут вообще делаться через настройки проекта, т.е. выполняться на уровне командной строки компилятора для каждого файла.

@Optimus11 · 15.03.2023, 20:46 **[ТС]**

Сообщение от TheCalligrapher

В С и С++ ничего никуда никогда не "распространяется". В С и С++ все объявления видны только в одной единице трансляции, т.е. фактически в одном файле. Все, что определено в единице трансляции выше, будет видно в ней ниже. Больше ничего видно не будет.

Это значит, что эти макросы должны быть определены (или не определены) в той в каждой единице трансляции отдельно еще до того, как будет включен internal.h. Такие глобальные настройки могут вообще делаться через настройки проекта, т.е. выполняться на уровне командной строки компилятора для каждого файла.

Хорошо, но почему тогда Visual Studio окрашивала код так, как будто бы видит это определение ?

@TheCalligrapher · 15.03.2023, 20:49

Сообщение от Optimus11

но почему тогда Visual Studio окрашивала код так, как будто бы видит это определение ?

Где именно?

@Optimus11 · 15.03.2023, 20:50 **[ТС]**

Сообщение от TheCalligrapher

Где именно?

На скриншоте, я там выделил.

@TheCalligrapher · 15.03.2023, 20:51

Код .h-файла невозможно никак осмысленно "окрасить". .h-файл обычно используется (включается) в множестве разных контекстов. И в каждом контексте "окраска" запросто может быть (и будет) своей. По этой причине невозможно никак осмысленно "окрасить" .h-файл.

Поэтому что там вам "наокрашивала" Visual Stidio в .h-файле ничего не значит вообще. "Окраска" .h-файла почти никогда ничего не значит и обращать не нее внимание нет никакого смысла.

@nmcf · 15.03.2023, 20:53

TheCalligrapher, VS делает бледным шрифтом то, что не подходит под условие. Вроде бы так.

@Optimus11 · 15.03.2023, 20:55 **[ТС]**

Сообщение от nmcf

TheCalligrapher, VS делает бледным шрифтом то, что не подходит под условие. Вроде бы так.

да.

Добавлено через 57 секунд

Сообщение от TheCalligrapher

Код .h-файла невозможно никак осмысленно "окрасить". .h-файл обычно используется (включается) в множестве разных контекстов. И в каждом контексте "окраска" запросто может быть (и будет) своей.

Поэтому что там вам "наокрашивала" Visual Stidio в .h-файле ничего не значит вообще. "Окраска" .h-файла почти никогда ничего не значит и обращать не нее внимание нет никакого смысла.

Ну насколько я замечал, окраска кода в Visual Stuio всегда значит состояние данной строки кода.

@TheCalligrapher · 15.03.2023, 21:06

Сообщение от Optimus11

насколько я замечал, окраска кода в Visual Stuio всегда значит состояние данной строки кода.

Еще раз повторяю: у строки кода во включаемом файле в принципе нет и не может быть никакого конкретного "состояния". Поэтому ни о каком "окраска кода в Visual Stuio всегда значит" в случае включаемого файла не может быть и речи. Окраска кода во включаемом файле в общем случае вообще ничего не значит.

Добавлено через 8 минут
---

Простой эксперимент с Visual Studio показывает, что подсветка активных ветвей #if в .h-файлах зависит от того, как этот .h-файл открывали. Когда .h-файл открывается нажатием правой кнопки мыши на директиве #include в конкретном файле реализации, подсветка определяется тем контекстом, в котором располагается эта директива #include в этом файле реализации. То есть один и тот же .h-файл будет иметь совершенно разную подсветку ветвей #if, когда его открывают из разных точек через разные #include.

Вы в своем случае видите "неправильную" подсветку потому, что "неправильно" (не оттуда) открыли свой .h-файл.

@nmcf · 15.03.2023, 21:09

Я думал, что VS весь проект анализирует.

@TheCalligrapher · 15.03.2023, 21:17

Сообщение от nmcf

Я думал, что VS весь проект анализирует.

Вы о чем вообще? При чем здесь "весь проект анализирует"?

Еще раз повторяю совершенно элементарную и очевидную вещь: один и тот же .h-файл может требовать разной расцветки ветвей #if в разных точках включения. То есть в принципе не существует и не может существовать однозначной расцветки ветвей #if в .h-файле.

Невозможно отобразить то, чего не существует. Никак. Хоть анализируй "весь проект", хоть не анализируй.

@nmcf · 15.03.2023, 21:22

Сообщение от TheCalligrapher

один и тот же .h-файл может требовать разной расцветки ветвей #if в разных точках включения

Я о том, что в VS есть такая подсветка. Если они её сделали, значит какую-то логику предполагали.

@TheCalligrapher · 15.03.2023, 21:22

Например

C++
1
2
3
4
// test.h
#ifdef VASYA
  #error Поздравляю, Вася, ты балбес!
#endif

C++
1
2
3
4
5
6
7
8
// test.cpp
#include "test.h"
 
#define VASYA
#include "test.h"
#undef VASYA
 
int main() {}

Как по-вашему должна выглядеть подсветка ветвей #if в таком test.h???

@nmcf · 15.03.2023, 21:24

Теперь уже не знаю. Надо проверять.

@TheCalligrapher · 15.03.2023, 21:24

Сообщение от nmcf

Если они её сделали, значит какую-то логику предполагали.

Я выше подробно написал, какую "логику" они предполагали: подсветка зависит от того, из какого контекста открывался .h-файл, если этот файл открывался нажатием правой кнопки мыши на конкретной директиве #include. Но и это работает весьма условно...

Если вы не знаете, из какого контекста был открыт ваш .h-файл, то ответ "нет": никакой логики в его подсветке нет. Просто запомните: подсветка активных ветвей #if (и многого другого) во включаемых файлах - бессмысленна и не значит вообще ничего.

Новые блоги и статьи Все статьи Все блоги /
WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114
Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .	Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .

@TheCalligrapher Вездепух 12930 / 6798 / 1820 Регистрация: 18.10.2014 Сообщений: 17,208
	15.03.2023, 20:51
	Код `.h`-файла невозможно никак осмысленно "окрасить". `.h`-файл обычно используется (включается) в множестве разных контекстов. И в каждом контексте "окраска" запросто может быть (и будет) своей. По этой причине невозможно никак осмысленно "окрасить" `.h`-файл. Поэтому что там вам "наокрашивала" Visual Stidio в `.h`-файле ничего не значит вообще. "Окраска" `.h`-файла почти никогда ничего не значит и обращать не нее внимание нет никакого смысла. 0

@nmcf 7804 / 6568 / 2988 Регистрация: 14.04.2014 Сообщений: 28,705
	15.03.2023, 20:53
	TheCalligrapher, VS делает бледным шрифтом то, что не подходит под условие. Вроде бы так. 0

@nmcf 7804 / 6568 / 2988 Регистрация: 14.04.2014 Сообщений: 28,705
	15.03.2023, 21:09
	Я думал, что VS весь проект анализирует. 0

@nmcf 7804 / 6568 / 2988 Регистрация: 14.04.2014 Сообщений: 28,705
	15.03.2023, 21:24
	Теперь уже не знаю. Надо проверять. 0