C++

[xStream 86]

@Desertir, 

По сути эти "х" перед цифрами означают разное: х86 исторически отображает архитектуру, которая пошла с первого 86-го процессора (самые известные i386 и i486, а пресловутый пентиум носил индекс 586), а когда появилась разрядность 64 бит на той же архитектуре, стали обозначать разрядность. Отсюда несостыковка такая. В общем, всего лишь исторический фактор. Для общего развития, еще есть ia64 - это суперскалярные процессоры от интела, исторически сразу 64 разряда. Так же существует amd64, отличается наборами микрокоманд, см. ниже.

В общем-то в статье так и написано, но что-то сильно много букв

 

 

sse2, sse3 и другими страшными буквами, но это уже не столь существенно.

Это не подвиды, это наборы расширенных команд микропроцессоров, конкретно sse2 и sse3 - инструкции для работы с потоковыми данными. На самом деле их уйма, и разные процессоры поддерживают разные наборы. Различия в основном в последних исторически наборах команд, которые у АМД и у Интела свои, потом либо отмирают, либо появляются универсальные для обоих вендоров наборы.

По топику - для сборки сырцов в исполняемый файл, почти все эти наборы не важны - либо они есть в новых процессорах, либо не требуются для функционирования программы (рентгена).

Изменено 29 Января 2015 пользователем xStream

[xStream 86]

@User_X.A.R26, я без понятия, что это такое вообще Если какая-то штука либо для проверки фич процов, то да, смысла париться нет, если не собираетесь поддерживать компы с конфигурацией годов, когда начали писать сталкер

[xStream 86]

 

 

Здесь на самом деле терминологическая путаница. Статические библотеки - это файлы .h - при сборке просто тупо используемые из них куски становятся частью .exe dll - совершенно другая технология, когда этот самый dll дергается из разных программ.

Шта, простите?

.h - заголовочные файлы с объявлениями, .c & .cpp - файлы имплементации, то бишь реализации собственно сама логика, код.

И то и другое - исходный код.

 

.lib - это файлы библиотек для компоновки результата. Используется в случае и статической и динамической линковки. По сути - промежуточные файлы, нужные линкеру (иногда компилятору, но сами являются результатом работы компилятора)

.exe и .dll - файлы, содержащие исполняемый код. Екзешники самостоятельны, имеют точки входа, дллки тоже могут иметь точки входа, но не являются самостоятельными сущностями в ОСи. 

В случае статической линковки, в .lib файле собирается полностью исходный код и встраивается в тело программы, в случае динамической, в .lib файле собираются определения того, какая динамическая библиотека используется и адреса функций и методов классов, что позволяет основной программе использовать содержимое динамической библиотеки в своих целях.

 

Зачем нужны динамические библиотеки - отдельный вопрос. Ну как минимум в случае сталкера такие дллки сделаны потому, что и игра и редактор используют одни и те же классы и дефиниции, чтобы не дублировать код, его и вынесли в отдельные либы.

 

 

 

Вкомпилить dll в свой проект - это, в общем, объединение его с exe так, что отдельный dll становится не нужен

Это в общем-то какой-то бессмысленный набор слов

 

@Desertir, 

Собсно я выше расписала.

 

 

 

Насколько мне известно: такого понятия нет. А вот перенос кода из библиотеки в приложение...

Да, нет такого понятия. И переносить просто бессмысленно.

 

 

 

чтобы избежать неоднократного повторения разных моментов.

Не только и не столько. Это делается еще и для распространенных библиотек - библиотека единожды загружается в память, а использоваться может разными программами. Что и память экономит и универсализирует интерфейс. Пример таких библиотек, пресловутые msvcxxx.dll библиотеки, они используются программами, написанными в разных версиях визуалстудии от мелкомягких.

Для программистов может быть еще одна причина важна, которую я написала выше.

 

 

Также ситуация с уменьшением веса EXE. "Лишнее" тоже удобно сбрасывать в DLL и оттуда вызывать

Не совсем. Опять же на примерах: библиотеки могут предоставлять одинаковый интерфейс, но реализовывать разный функционал, ядру же (программе) пофиг, как там работает библиотека. В случае сталкера - рендеры, они подгружаются в зависимости от настроек программы, но коду ядра совершенно все равно, какой рендер сейчас подключен.

[xStream 86]

А разве оперативка не будет страдать из-за увесистых EXE в случае "монолитности" последнего?

Плакать и истекать кровью?       Процессору и памяти все равно, что там они хранят или считают.

Первая и главная причина появления динамических библиотек (это ведь не только в винде так, но и юнихах с линухами) - экономия памяти, но не памяти одного экзешника, а всей системы в целом. Представь себе веб сервер, на нем крутится апач, на каждый хит (на самом деле все зависит от настроек, но я буду описывать так - это нагляднее) создается дочерний процесс, который например тянет пхп интерпретатор. Так вот, если апач-процесс - это нормально, многопоточность и раздельные ресурсы и так далее, то пхп-интерпретатор один, вот он и существует в виде библиотеки. Например, весит он 6Мб (версия 5.4 столько весит), потом сам пхп подключает туеву хучу расширений - опять же в виде длл (1-30Мб). Так вот, по идее на каждый апач-процесс должно быть несколько экземпляров пхп (по количеству изолированных нитей выполнения), сам пхп - по пачке расширений (количество расширений помножим на количество пхп). Без длл это было бы очень много - под пару гигов оперативки, что очень расточительно. При использовании длл, каждая из них (будь то пхп или его расширения) загружается в память всего один раз, что дает всего под сотню метров оперативки.

Чувствуется разница?

 

 

Я так понимаю, он просто добавляет все опции для линкера без нашего шаманства?

Не совсем так. Он создает код для автоматической загрузки библиотеки и импорта имен библиотеки в пространство программы (инклюдит .h файлы).

Можно любую динамическую либу загрузить программно после запуска программы в любой момент, просто использовать код, который обращается к ней до этого нельзя, да и банально не выйдет. Так же некоторые неудобства получаются с именованиями - все приходится ручками делать, так как автоматического импорта не происходит.

Изменено 31 Января 2015 пользователем xStream

[xStream 86]

@Desertir, темплейты всегда в заголовках потому, что у них нет непосредственно кода реализации: классы (функции) создаются по мере надобности. Точнее, шаблон можно вынести в cpp, но это описание никто нигде не увидит, так как подключаются хедеры, а не файлы имплементации.

Смутно помню, что в какой-то из новых версий то ли языка, то ли студии, можно определять шаблон в .cpp

 

Ответ на твой вопрос: описание шаблона вместе с реализацией должно быть в зоне видимости всех тех мест, где ты это используешь - это делают в заголовочных файлах.

Изменено 5 Февраля 2015 пользователем xStream