DLLs и STLs и статические данные (о, мой!)
Обнаружение операционная система и тип ЦП не настолько легко сделать портативно . Я имею sh сценарий приблизительно 100 строк, который работает через очень большое разнообразие платформ Unix: любая система я использовал с 1988.
основные элементы
-
uname -p, тип процессора , но обычноunknownна современных платформах Unix. -
uname -mдаст "аппаратное название машины" в некоторых системах Unix. -
/bin/arch, если это существует, будет обычно давать тип процессора. -
unameбез аргументов назовет операционную систему.
В конечном счете необходимо будет думать о различиях между платформами и , как прекрасный Вы хотите сделать их. , Например, только для хранения вещей простыми я рассматриваю i386 до i686, любой" Pentium*" и любой" AMD*Athlon*" все как [1 110].
Мой ~/.profile выполнения сценарий при запуске, который устанавливает одну переменную на строку, указывающую на комбинацию ЦП и операционной системы. Я имею определенный для платформы bin, man, lib, и include каталоги, которые будят набор на основе этого. Тогда я установил полную лодку переменных среды. Так, например, сценарий оболочки для переформатирования почты может звонить, например, $LIB/mailfmt, который является определенным для платформы исполняемым двоичным файлом.
, Если Вы хотите сократить углы , uname -m и плоскость uname, скажет Вам, что Вы хотите знать на многих платформах. Добавьте другой материал при необходимости в нем. (И используйте case, не вложенный if!)
3 ответа
Мы успешно передаем объекты STL в нашем приложении, которое состоит из десятков библиотек DLL. Чтобы убедиться, что он работает, один из наших автоматических тестов, который запускается при каждой сборке, - это проверка настроек для всех проектов. Если вы добавляете новый проект и неправильно его конфигурируете или нарушаете конфигурацию существующего проекта, сборка завершается неудачно.
Мы проверяем следующие настройки. Обратите внимание, что не все из них вызовут проблемы, но мы проверяем их на согласованность.
#defines
_WIN32_WINNT
STRICT
_WIN32_IE
NDEBUG
_DEBUG
_SECURE_SCL
Параметры компилятора
DebugInformationFormat
WholeProgramOptimization
RuntimeLibrary
Пока они ВСЕ используют одну и ту же версию динамических DLL, проблем с STL быть не должно. Но если у вас их несколько, они будут использовать, например, разные кучи, что приведет к бесконечным неприятностям.
Мы используем коллекции stl в нашем приложении и передаем их методам в разных dll (обычно в виде ссылок) и из них. Это не вызывает никаких проблем.
Единственная область, где у нас возникли проблемы, - это когда одна DLL выделяет память, а другая DLL пытается ее удалить. Это только считается плохим, но я не уверен, почему. Однако это только кажется проблемой в сборках отладки (где о ней сообщается), но все еще работает в сборках выпуска. Сказав, что где бы я ни сталкивался с этим, я исправляю это.
Если бы я писал стороннюю библиотеку, я бы дважды подумал об использовании параметров stl в api. Раньше (VC6) нам приходилось использовать OCI (Oracles C api) вместо OCCI (Oracles C ++ api), потому что он работал только с реализацией Microsoft STL, а мы использовали stlport.