C++

[Dennis_Chikin 3 665]

Здесь на самом деле терминологическая путаница.

 

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

Чтоб за примером далеко не ходить - да хоть inventory_item.h

 

dll - совершенно другая технология, когда этот самый dll дергается из разных программ.

 

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

 

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

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

[User_X.A.R26 261]

@xStream, эта шляпа является DLL-кой и в ней есть куча ASM-вставок в исходниках. Думаю, что она-то и отвечает за поддержку расширенных наборов команд и прочих фишек в процессорах того времени. Однако, насчёт последнего могу сильно ошибаться. В каждую строку кода этой библиотеки не вникал

---

Вкомпилить dll в свой проект

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

---

объединение его с exe так, что отдельный dll становится не нужен

используется для того, чтобы не раскрывать исходный код тем, кому "не положено"

Сами разработчики могут выносить в DLL код не только по причине нужны скрытия кода, а, например, для того, чтобы избежать неоднократного повторения разных моментов. Потом те же функции, заложенные в DLL можно использовать в любых проектах. Это очень удобно. Также ситуация с уменьшением веса EXE. "Лишнее" тоже удобно сбрасывать в DLL и оттуда вызывать

Изменено 31 Января 2015 пользователем 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 и оттуда вызывать

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

[User_X.A.R26 261]

то делается еще и для распространенных библиотек - библиотека единожды загружается в память, а использоваться может разными программами

Я примерно это и старался написать. Просто немного бессвязно пишу и порой "теряюсь" в собственных словах и мыслях)

---

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

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

Изменено 31 Января 2015 пользователем User_X.A.R26

[Desertir 202]

Здесь на самом деле терминологическая путаница.

Уверен? Я не очень.

Статические библотеки - это файлы .h

Цитата из статьи http://www.cplusplus.com/forum/articles/10627/

files with header extensions might be ignored by the compiler if you try to compile them

Статическая либа - файл с расширением .lib, хедеры используются в качестве include, т.е. вставляются препроцессором прямо в файл c(pp). Далее можно прочитать, что же делает компилятор.

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

Sorry, но это вообще жесть. Я посчитаю, что я этого не читал.

 

PS: похоже я несколько запоздал с ответом... но хорошо, что так все оперативно, @xStream, как всегда, спасибо

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

[xStream 86]

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

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

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

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

 

 

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

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

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

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

[Malandrinus 615]

Внесу свои пять копеек насчёт заголовков и исходников. Как верно сказала Анна, то и другое - файлы исходного текста. В целом же с технической точки зрения разницы между заголовочными (*.h/*.hpp) и *.c/*.cpp файлами (которые обычно называют собственно исходниками) нет никакой. Одни включаются в другие инклюдами, а в итоге после препроцессинга получается один комбинированный текстовый файл (называемый единицей трансляции), который и подаётся на вход компилятора.

 
Разница между заголовками и исходниками существует исключительно на уровне принятых соглашений об организации кода. В языке СИ/C++ есть объявления и определения. Определения - это указание выделить память и поэтому они должны быть строго в единственном экземпляре (в единственном не только на единицу трансляции, но и на всю программу). Объявления задают типы и структуру данных, должны предшествовать определениям и часто могут дублироваться. Поэтому объявления собирают в заголовках для их удобного включения "все разом" в начале текста (причём включения в разные единицы трансляции), а определения соответственно находятся в основном тексте (дабы быть в единственном экземпляре).
 
Ещё раз. С точки зрения компилятора никаких заголовков нет. Компилятор всегда компилирует один файл, который должен строго следовать синтаксису языка СИ/C++. Заголовочные файлы - это просто средство удобной организации программы, разделение одного модуля на несколько файлов, а что обычно содержится в заголовке, а что в исходнике - диктуется природой элементов языка и тем простым фактом, что после подстановки всех инклюдов получившаяся единица трансляции должна быть корректным компилируемым файлом.

[Desertir 202]

Делаю Variadic templates (template<class ... Args>). В общем если определение такой функции находится в файле, где она вызывается, все ок. Переношу определение в другой cpp и линкер ломается, говорит "1 unresolved externals".

//share.h

#pragma once

#include <string>

 

template<typename... Args>

void test(string name, Args... args);

//main.cpp

#include "share.h"

void main()

{

test("%s\n", "Success");

system("pause");

}

//works fine, go to test.cpp...

template<typename... Args>

void test(string name, Args... args)

{

printf(name.c_str(), args...);

}

//test.cpp

#include "share.h"

//...and not works

template<typename... Args>

void test(string name, Args... args)

{

printf(name.c_str(), args...);

}

error LNK2019: unresolved external symbol "void __cdecl test<char const *>(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,char const *)" (??$test@PBD@@YAXV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBD@Z) referenced in function _main	

Я так понимаю, это магия этих пакетизированных типов, как правильно в таком случае написать код?

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

[abramcumner 1 229]

Вся эта функция целиком должна быть в share.h

template<typename... Args>
void test(string name, Args... args)
{
    printf(name.c_str(), args...);
}

Пост malandrinus`а годится и для твоего случая: main.cpp компилируется отдельно, test.cpp отдельно.

[xStream 86]

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

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

 

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

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

[Elz 343]

Ребят, помощь нужна. Очень срочно...

c:\program files (x86)\msbuild\microsoft.cpp\v4.0\v120\microsoft.cppbuild.targets(328,3): неопознанный элемент <#text> в элементе .

 

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

[Desertir 202]

@Elz, открой файл нотепадом и глянь эту строку. Почему то xml тег побился, или вообще левый появился, у меня такого нет (ни <#text> ни <text>) Изменено 29 Марта 2015 пользователем Desertir

[Elz 343]

@Desertir, в том-то и дело, я его открываю, а там нет такого тега ВООБЩЕ!

[abramcumner 1 229]

(328,3) - что по этим координатам в файле?

[Elz 343]

@abramcumner,

 

<Target Name="PrepareForBuild" DependsOnTargets="SetBuildDefaultEnvironmentVariables;SetUserMacroEnvironmentVariables;GetResolvedWinMD;$(PrepareForBuildDependsOn)">
  <!-- These PropertyGroups are required because TargetPath and others are defined
       to contain an item list. We want that item list to be expanded so that it can be used
       as a regular property value and not as an item-list-with-transform. -->
    <PropertyGroup>
      <TargetDir>$(TargetDir)</TargetDir>
      <LocalDebuggerCommand>$(LocalDebuggerCommand)</LocalDebuggerCommand>

 

 

Там три пробела, а потом начинается сей текст...

Изменено 29 Марта 2015 пользователем Elz

[Desertir 202]

@Elz, похоже никто не в теме.

 

Свершилось чудо, а именно релиз мега крутой надстройки ReSharper для С++. Теперь код и на C++ можно "писать" в несколько кликов.

Конечно были EAP версии, и я ими пользовался, но тем не менее релиз - долгожданное событие.

Изменено 11 Апреля 2015 пользователем Desertir

[Elz 343]

@Desertir, я уже давно (дней 9-15 назад) скачал R# с торрента)) Полезная штука.

Да я не стал мучаться - сегодня вынду переставлю, и все. Кстати, в этот раз абсолютно лецинзионная MSVS2013 попалась какая-то тупанутая, ни тебе строки меню "Сборка" (хотя галочкой отметил), ни тебе автоподсказок во время написания кода. Как только не извращался с настройками - не включил... Бред!

[Карлан 1 050]

Можете как-то совсем на пальцах объяснить про ссылки и указатели? Который день читаю, а как-то все не пойму.

[Desertir 202]

@Карлан, а чего тут объяснять? Есть ячейка памяти с определенным номером 0x1234DEAD (для x32/x86).

Переменная это именованная ячейка 0x1234DEAD + некоторый объем других ячеек, в зависимости от типа переменной.

Ссылка это тоже самое, только название переменной другое. Ссылка связана с тем же участком памяти и используется так же, как и обычная переменная.

Указатель сам себе переменная, которая хранит цифру. Эта цифра и есть 0x1234DEAD.

 

А вот где и как их применять - отдельный вопрос, объяснить просто будет трудно и будет очень много слов.

Проще задавать конкретные вопросы.

 

PS: надеюсь не сказал нигде глупость.

[Dennis_Chikin 3 665]

*var - обратиться по адресу, указанному в var. &var - получить адрес var
Собственно, в lua, имея дело с переменной, всегда имеешь дело с ее адресом, к которому зачем-то привязан тип, а потом при операции происходит 100500 преобразований, и не всегда с ожидаемым результатом.

 

upd: зачеркнутое было действительно написано не на русском языке. Я подумаю, как сказать то, что хотел сказать. (И вообще - что именно хотел.)

 

В сях, если не указал, что это - адрес - имеешь дело с копией.
char *s = "моя строка"; // s - это "где конкретно лежит буква "м".
char c1 = *( s + 3 ); // это пробел. То есть, просто пробел. А вот s+3 - это откуда мы его берем.
char c2 = s[3]; // тоже пробел. Но уже другой. Хотя взят оттуда же.
char c3 = s[3]; // и еще один пробел.
char *ptr = &c1; // адрес какого-то пробела, лежащего где-то.

А вот
char &addr = s; // это уже типично плюсплюснутое извращение, придуманное для изращенцев, и так делать не надо.

Для чего все такое придумано - а вот собственно то, что я тебе про сохранение/чтение писал.
Выделяешь память, много. Получаешь указатель (сиречь, адрес).
Объявляешь его указателем на структуру нужного тебе типа, ну там, на таблицу, например. И, вуалая - по элементу всегда имеешь нужное. Если хочешь что-то другое - объявляешь более другую стуктуру, или вообще указатель на тип (если знаешь, где у тебя что лежит), и по нему имеешь что хочешь в том виде, в каком надо.
А читаешь/пишешь в файл - всегда блоком, от которого тебе надо знать только адрес и размер. И все это - мгновенно.

Изменено 19 Апреля 2015 пользователем Dennis_Chikin