#c #visual-studio #macros
#c #visual-studio #макросы
Вопрос:
Есть ли макрос, который я могу использовать для проверки текущего типа конфигурации в Visual Studio? В зависимости от текущей настройки я бы хотел включить функцию main или dllmain:
#IFDEF CONFIGURATION_TYPE_EXE
int main(int argc, char **argv)
{
...
}
#ELSEIF CONFIGURATION_TYPE_DLL
BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
return TRUE;
}
#ENDIF
Комментарии:
1. Вы можете определить свои собственные конфигурации сборки и определения препроцессоров в Visual Studio, чтобы сделать это за вас.
2. Можете ли вы определить «текущий тип конфигурации», вы имеете в виду режимы сборки Release / Debug?
3. @simbolo нет, в свойствах конфигурации -> Общие есть опция «тип конфигурации», которую я хотел бы проверить на текущую конфигурацию (debug / release).
4. @helloworld922 как я могу это сделать?
Ответ №1:
Если это dll, то _WINDLL будет определен как унаследованное значение. Вы можете найти его здесь: Свойства конфигурации -> C / C -> Препроцессор -> Определения препроцессора.
#ifdef _WINDLL
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{ ... }
#else
int main(int argc, char** argv)
{ ... }
#endif
Комментарии:
1. Это более надежно, чем
_USRDLL
, как упоминалось, оно наследуется автоматически включаемой таблицей свойств.2. @MatthewHolder Хотя мне интересно, делают ли это старые версии, такие как VC6, автоматически (мне было нелегко найти информацию об этом в Интернете), кажется, что версии, даже такие старые, как VS 2008, делают это. Кстати, вы можете отключить это автоматическое определение, нажав «Редактировать» в строке «Определения препроцессора» и снимите флажок «Наследовать от родительских или проектных значений по умолчанию» в появившемся окне.
3. @KeithM, основная причина, по которой большинство считает
_WINDLL
более надежным, заключается в том, что это автоматическое включение через таблицу свойств системы сборки, которая обычно не находится под контролем пользователя._USRDLL
является частью шаблона проекта, который пользователь может удалить после создания проекта.4. @Matthew Я не думаю, что вы поняли мой комментарий так, как я это имел в виду. Я знаю об этом; меня беспокоило то, что я не могу точно определить, как далеко уходит история
_WINDLL
. То есть VS 2008 делает это автоматически, но я не смог подтвердить, делают ли это более старые версии MSV. (В вопросе не упоминается конкретная версия MSVS.)5. @KeithM, ах… Я сам не могу сказать наверняка, но прошло много лет с тех пор, как я использовал версии Visual C до 2005 года, но я могу подтвердить, что 2005 тоже это сделал. Я использовал 4 и 6 и хочу сказать, что они тоже это сделали, но это было бы из очень смутных воспоминаний, которые могли бы просто заставить меня думать, что когда это не так. Я всегда следовал соглашению о создании общего листа свойств для всех конфигураций проекта, который будет
_CONSOLE
использоваться в консольных приложениях,_WINDOWS
в приложениях с графическим интерфейсом и_USRDLL
в приложениях DLL, и моя команда следовала тому же соглашению.
Ответ №2:
Если это проект DLL, _USRDLL
он будет определен. (см. раздел Свойства конфигурации Препроцессор Определения препроцессора).
Однако будьте осторожны, поскольку список заполняется мастером и не будет обновляться автоматически, если проект был создан как что-то другое, а затем настроен как DLL. Кроме того, вы должны быть осторожны, если вы создаете библиотеку, которая будет связана с DLL.
Комментарии:
1. Я только что попробовал ifdef _USRDLL в проекте, который я изначально создал как приложение. Когда я переключаюсь на тип конфигурации dll, он все еще не определен. Так что, думаю, мне придется изменить и другие настройки проекта.