Visual Studio: макрос для проверки типа конфигурации (exe / dll)

#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, он все еще не определен. Так что, думаю, мне придется изменить и другие настройки проекта.