Библиотека времени исполнения Microsoft Visual Studio ~ C/С++ ~ Статическое/динамическое связывание
Я являюсь пользователем Microsoft Visual Studio.
Мой вопрос о "C/С++ Runtime Library" .
Я создал "Empty Project" с исходным файлом ".cpp" "main.cpp", содержащим следующий код:
#include <iostream>
int main(void)
{
std::cout << "Hello World" << std::endl;
return 0;
}
"iostream - это заголовочный файл, который используется для ввода/вывода на языке программирования С++.
Это часть стандартной библиотеки С++.
-
Есть ли разница между "C/С++ Runtime Library" и "C/С++
Стандартная библиотека "?
-
Как узнать, есть ли "C/С++ Runtime Library"
библиотека статически или динамически связана с проектом?
-
Как узнать, где находится эта библиотека в файловой системе?
-
В случае, если "C/С++ Runtime Library" динамически связана с
проект, как я могу узнать, какая ".dll" используется, и где используется
".dll" находится в файловой системе?
-
Предположим, что я статически связываю "C/С++ Runtime Library" с проектом, могу ли я быть уверенным, что исполняемый файл, сгенерированный из исходного кода, будет работать на всех платформах Windows (XP/Vista/Seven/..., 32 бит /64 бит)?
-
Каковы преимущества/недостатки динамического связывания "C/С++ Runtime
Библиотека "в проект?
-
Должно ли "C/С++ Runtime Libray" быть статически или динамически связано с проектом?
Спасибо за ваши ответы.
Ответы
Ответ 1
Термин "C/С++ Runtime Library" ничего не значит, это примерно имя параметра проекта в среде IDE. Project + Properties, C/С++, Code Generation, Runtime Library. Там вы можете выбрать между /MD и/MT.
С/MD, по умолчанию, ваша программа будет использовать DLL-версию библиотек времени исполнения. На вашем компьютере они были скопированы в c:\windows\system32 и/или c:\windows\syswow64 установщиком Visual Studio. И у вас есть их копии в подкаталоге vc/redist каталога установки VS, там вы сможете использовать его при создании установщика для своей программы. Три версии из них, x86 для 32-разрядных процессоров Intel, x64 для 64-разрядных процессоров Intel и рычаг для ARM-процессоров. Выберите правильный вариант на основе платформы, выбранной в вашем проекте.
Соответствующие имена DLL:
- msvcr110.dll: библиотека времени выполнения C (memcpy и др.)
- msvcp110.dll: стандартная библиотека С++ (std::string и др.)
- vccorlib110.dll: библиотека времени выполнения для приложений Windows Store
- vcomp110.dll: библиотека времени выполнения для OpenMP (см. #pragma omp)
- atl110.dll: библиотека времени выполнения для проектов ATL
- mfc110 *.dll: библиотеки времени выполнения и локализации для проектов MFC
- vcamp110.dll: библиотека времени выполнения проектов AMP
На вашем компьютере вы также получили отладочные сборки этих DLL, скопированных в каталог Windows установщиком VS. Они имеют то же имя с прилагаемой буквой "d". Полезно только для отладки вашего кода, вы не можете распространять их. Соответствующая настройка библиотеки времени выполнения -/MDd.
Для большинства проектов на С++ нужны только msvcr110.dll и msvcp110.dll, вы знаете, когда будете использовать другие библиотеки, поскольку для них есть конкретные шаблоны проектов и настройки.
Простым способом получить все эти DLL, установленные на вашем компьютере пользователя, является использование предварительно созданного установщика. Вы можете скачать здесь (примечание: текущее только с сегодняшнего дня, это может измениться, когда станет доступен пакет обновления или обновление). Или вы можете просто скопировать их в тот же каталог, что и ваш основной EXE.
Вы можете избежать зависимости от этих DLL, изменив параметр Runtime Library на /MT. В этом случае код поддержки во время выполнения привязан к вашей программе, и у вас будет только один EXE для развертывания. Разумеется, он будет увеличиваться, когда вы это сделаете, иногда значительно, особенно, когда вы используете MFC.
Использование/MT является рискованным, если вы создаете библиотеки DLL, а также EXE. В итоге вы получите несколько копий ЭЛТ. Это была особенно проблема с более ранними версиями VS, где каждый CRT получал бы свою собственную кучу, а не VS2012. Но у вас все еще могут быть уродливые проблемы времени выполнения, если у вас более одной переменной "errno", например. Использование /MD настоятельно рекомендуется избегать такого снижения.
Ваша программа будет работать в Windows Vista, 7 и 8. Поддержка XP будет ослабевать, вам понадобится VS Update 1 и измените настройку набора инструментов в проекте с "v110" на "v110_xp", чтобы создать программу, которая все еще работает на XP. Некоторые функции теряются, когда вы это делаете, связанные с локалью и локальным хранилищем потоков, требуется тестирование.
Ответ 2
здесь ничего не происходит... пожалуйста, перезвоните, если вы обнаружите ошибку.
1. Есть ли разница между "C/С++ Runtime Library" и "C/С++ Standard Library"?
да и нет. иногда люди используют библиотеку времени исполнения для обозначения всего и вообще игнорируют стандартную библиотеку (для инструментов Microsoft). однако технически библиотека времени выполнения загружается во время выполнения, поэтому она включает в себя пару .lib(import lib) и .dll. см. здесь для деталей: http://msdn.microsoft.com/en-us/library/vstudio/abx4dbyh(v=vs.100).aspx
технически, libc * - это стандартные библиотеки, а * crt - библиотеки времени выполнения.
2. Как узнать, статическая или динамическая привязка библиотеки "C/С++ Runtime Library" к проекту?
Если вы используете IDE (VS2010, другие похожи), это в свойствах проекта:
- configuration properties
- c/c++
- code generation
[Runtime Library]
3. Как узнать, где находится эта библиотека в файловой системе?
Файлы lib находятся в каталоге lib вашего sdk (если вы установили более поздний windows sdk) или в visual С++-каталог.
4. В случае, если "C/С++ Runtime Library" динамически связана с проектом, как я могу узнать, какая ".dll" используется и где используемая ".dll" находится в файловой системе?
Вы можете определить, какие из них используются с помощью инструмента зависимости. http://www.dependencywalker.com/
DLL файлы находятся где-то в каталоге Windows. Они перемещают их, и теперь они в причудливых местах с манифестом и вещами, чтобы отслеживать версию. Я бы не стал слишком беспокоиться об этом. Если вам нужно беспокоиться об этом, возможно, что-то не так. Для получения дополнительной информации:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa375365(v=vs.85).aspx
http://en.wikipedia.org/wiki/Side-by-side_assembly
Если это вызывает беспокойство, вы можете связать распространяемый пакет с вашим установщиком: Разница между Visual Studio Redistributable и Visual Studio SP1
5. Предположим, что я статически связываю "C/С++ Runtime Library" с проектом, могу ли я быть уверенным, что исполняемый файл, сгенерированный из исходного кода, будет работать на всех платформах Windows (XP/Vista/Seven/..., 32 бит /64 бит)?
да, если вы связываете статически, тогда вы более безопасны с точки зрения того, что не можете найти dll. однако это делает ваш исполняемый файл более крупным. есть другие последствия с точки зрения поведения... это сложно перечислить, но разница исходит из того факта, что библиотека находится в dll vs, скомпилированном в ваш exe.
6. Каковы преимущества/недостатки динамического связывания "C/С++ Runtime Library" с проектом?
зачем использовать dll:
a - размер. меньший размер exe, потому что все материалы библиотеки находятся в dll, которые должны быть установлены уже в пользовательской системе, хотя иногда это неверно.
b - если во время выполнения есть ошибки, microsoft может подтолкнуть новый выпуск пользователю. вам не придется иметь дело с этим. если вы статически связываете, вам нужно нажать новый exe для пользователя.
почему бы не использовать dll:
a - многие проблемы с обработкой dll. если вы забудете объединить переиздание, может возникнуть много проблем.
b - наличие большего количества DLL для загрузки и выгрузки вызывает более медленное время запуска и выхода.
возможно, другие причины, о которых я не думал...
7. Должен ли "C/С++ Runtime Libray" быть статически или динамически связан с проектом?
это действительно зависит. Я лично предпочитаю статически связанную. я ненавижу скремблировать вокруг ищет правильный redist/dll/etc.