Эффект определения _WINDLL в статической библиотеке
По причинам, которые я не собираюсь вдаваться в подробности, а сводлюсь к сложным цепочкам .props, у меня есть ряд проектов (все C скомпилированы с помощью компилятора C++), которые в DLLрешение, по-прежнему создают статические библиотеки, но определяют _WINDLL. . Это поправимо, но нелегко.
Ни один из этих проектов не будет и никогда не будет использовать MFC или что-либо подобное, но проект один - уровень абстракции ОС - не включает Windows.h для сокетов, мьютексов и потоков.
Из-за этого во время компиляции нет ошибок или предупреждений, и приложение, кажется, работает нормально, но это древний зверь, с сотнями мелких функций и без модульных тестов :)
Мой вопрос: нужно ли мне нужно исправить эти статические библиотеки, чтобы не определять _WINDLL?
Обновлено:
Казалось бы, необходима дополнительная информация, хотя я думаю, что у меня есть свой ответ:
Лист свойств, определяющий это, является НАШЕМ листом свойств, и он является частью относительно сложной системы, которая позволяет нам создавать Release / Debug / Lib / Dll Arm / WinCE / x86 / x64 Clang / MSVC с небольшой болью с относительно, но иногда свои вопросы. Листы свойств имеют иерархическую структуру и используются как проектами, над которыми я работаю, так и проектами, к которым я не хочу прикасаться.
@JonathanPotter - Нет. Спасибо - обновил вопрос.
Я думаю, что _WINDLL - это то, что компилятор определяет для вас, чтобы сообщить вам, что вы компилируете как DLL. Я не думаю, что это что-то неявно меняет; ваш код должен будет проверить это через #ifdef.
@JonathanPotter - Аааа, и это проверяется в другом решении, которое использует те же файлы .props. Спасибо. Я надеюсь и верю, что вы правы :) Я, конечно, не нашел этого в системных заголовках, но я всегда неохотно доверял этому как «окончательному ответу» :)
«включить Windows.h для сокетов, мьютексов и потоков» по крайней мере для «мьютексов» и «потоков», я бы рекомендовал вместо них include <mutex> и include <thread>.
@JesperJuhl Я не хочу запускать ребят из Си :). Плюс это уровень абстракции ОС. Педаль до металла и все.
@zzxyz. - Я не слежу за тобой. <mutex> и <thread> - это заголовки C++, заголовки нет C. О чем ты?
@JesperJuhl Они ребята из C, и я собираюсь вставить заголовки STL в их код? Я действительно не понимаю, что делать, если это вызывает проблему.
Это не предопределенный макрос, как предположил Джонатан. Это происходит из окна свойств «Библиотеки динамической компоновки Windows». Используйте «Просмотр»> (Другие окна)> «Менеджер свойств», чтобы увидеть это. Не означает ничего, кроме «этот проект создает DLL, которая будет использоваться в Windows». Вы, конечно, потеряете очки элегантности из-за того, что он определен в проекте статической библиотеки, но вам, вероятно, это сойдет с рук. Было бы разумно удалить лист свойств.
@HansPassant - он явно определен в одном из НАШИХ листов свойств (я знаю, я знаю), который используется проектами, на которые я никогда даже не смотрел. Одному Богу известно, что с этим делают эти проекты. Я тоже не могу снять простыню без больших головных болей.
_WINDLL может не определяться компилятором, но он определяется реализацией. Обычно любой идентификатор с начальным подчеркиванием, за которым следует заглавная буква, зарезервирован, и его существование должно контролироваться, если не самим компилятором, то связанной средой выполнения.
Конечно, ваши листы свойств находятся под контролем источника. Так что просто узнайте, кто добавил эту страницу свойств в ваш проект или кто добавил символ препроцессора _WINDLL в список свойств, и попросите разъяснений. Сообщение о фиксации также может дать некоторые подсказки.
Вы получаете ошибки?