Значительно ли увеличивает занимаемую площадь использование STL?

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

Во встроенном проекте с лимитом 64 КБ, который я когда-то делал, я даже не мог связать стандартные библиотеки C. Так что это зависит от того, что вам нужно делать

Использование STL увеличит ваш двоичный размер по двум основным причинам:

Встраивание

По умолчанию компилятор обрабатывает код шаблона как встроенный. Следовательно, если вы используете std::list<int> в нескольких разных модулях компиляции, и компилятор встраивает этот код, каждый из них будет иметь свои собственные локальные встроенные определения функций std::list<int> (что, вероятно, не имеет большого значения, поскольку по умолчанию компилятор будет встроить только очень маленькие определения).

Обратите внимание, что (как указывает Мартин в другом месте) множественно определенные символы удаляются всеми современными компоновщиками C++ на больших платформах, как описано в Документация GCC. Таким образом, если компилятор оставляет код шаблона вне очереди, компоновщик удаляет дубликаты.

Специализация

Из-за самой природы шаблонов C++ std::list<int> потенциально произвольно отличается от std::list<double>. Фактически, стандарт требует, чтобы std::vector<bool> был определен как битовый вектор, поэтому большинство операций там полностью отличается от std::vector<T> по умолчанию.

С этим может справиться только сопровождающий библиотеки. Одно из решений - взять базовую функциональность и удалить ее из шаблона. Превратите его в структуру данных в стиле C с помощью void* повсюду. Тогда интерфейс шаблона, который видят нижестоящие разработчики, представляет собой тонкую оболочку. Это уменьшает количество дублированного кода, поскольку все специализации шаблонов имеют общую основу.

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

Контейнеры STL эффективны для того, чем они являются ... контейнеры общего назначения. Если вы выбираете между написанием собственного двусвязного списка или использованием std :: list, пожалуйста ... используйте STL. Если вы подумываете о написании очень зависящих от предметной области, битовых контейнеров для каждой из ваших конкретных потребностей, сначала используйте STL, а затем выберите свои сражения, когда весь ваш код будет работать правильно.

Некоторые хорошие практики:

• Если ваша библиотека собирается предоставлять эти контейнеры через API, вам, возможно, придется выбирать между помещением кода STL в заголовки библиотеки или отказом от использования STL. Проблема в том, что мой компилятор не должен реализовывать STL так же, как ваш.
• Узнайте, как и когда STL контейнеры выделяют память. Когда вы можете визуализировать, как растет дек и сжимается по сравнению с вектором, вы будете лучше подготовлены к тому, чтобы решить, какой из них использовать.
• Если вам нужно микроуправлять каждым байтом, подумайте о написании собственных распределителей. Это редко требуется за пределами встроенных систем.

Дело в STL, потому что это все шаблоны, которые он только увеличивает размер, когда вы фактически используете. Если вы не используете метод, этот метод не создается.

Но за то, что вы используете, всегда будет цена.

Но настоящий вопрос вы должны задать. Будет ли размер больше или меньше вашей собственной реализации? Если вы не используете STL, что вы используете? Вы можете написать собственное письмо от руки, но за это придется заплатить. Это не нулевое пространство, он не будет хорошо протестирован, и вы не будете следовать установленным передовым методам.

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

В другом сообщении говорится, что код шаблона должен быть встроен или иметь несколько определений. Это абсолютно НЕПРАВИЛЬНЫЙ.

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

Если не встроено, то копия метода будет сгенерирована в каждой единице компиляции, которая использует метод. Но ТРЕБОВАНИЕ к компоновщику C++ состоит в том, что он должен удалять ВСЕ, кроме ОДНОЙ копии этих методов, когда приложение связано с исполняемым файлом. Если компилятор не удалил лишние копии, ему пришлось бы сгенерировать ошибку компоновщика нескольких определений.

Это легко показать:
Следующее иллюстрирует это:

• Метод _M_insert_aux () не встроен.
• Он размещен в обоих модулях компиляции.
• Эта только одна копия метода находится в конечном исполняемом файле.

a.cpp

#include <vector>

void a(std::vector<int>& l)
{
    l.push_back(1);
    l.at(0) = 2;
}

b.cpp

#include <vector>

void b(std::vector<int>& l)
{
    l.push_back(1);
    l.at(0) = 2;
}

main.cpp

#include <vector>

void a(std::vector<int>&);
void b(std::vector<int>&);

int main()
{
    std::vector<int>    x;
    a(x);
    b(x);
}

Проверка

>g++ -c a.cpp
>g++ -c b.cpp

>nm a.o
<removed other stuff>
000000a0 S __ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi
<removed other stuff>

>nm b.o
<removed other stuff>
000000a0 S __ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi
<removed other stuff>

>c++filt __ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi
std::vector<int, std::allocator<int> >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, int const&)

>g++ a.o b.o main.cpp
nm a.out | grep __ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi
00001700 T __ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi

Игнорируя пока обсуждение STL, есть одна неочевидная важная практика для создания статической библиотеки, занимающей мало места. Разделите свою библиотеку на как можно больше разрозненных единиц компиляции. Например, если вы посмотрите на libpthread.a, вы увидите, что каждая функция имеет свой собственный блок компиляции. Многие компоновщики выбрасывают мертвый код на основе целых единиц компиляции, но не более детализированного, чем это. Если я использую только несколько функций из библиотеки pthreads, мой компоновщик внесет только эти определения и ничего больше. С другой стороны, если бы вся библиотека была скомпилирована в один объектный файл, моему компоновщику пришлось бы добавить всю библиотеку как единый «блок».

Это зависит от используемой вами инструментальной цепочки и применяется только в том случае, если вы создаете статические библиотеки. Но я видел очень ощутимую разницу для больших библиотек, построенных неоптимально.

Хотя в нем не рассматриваются шаблоны STL, в документации по GCC есть небольшой раздел, посвященный минимизации раздувания кода при использовании шаблонов-шаблонов.

Ссылка есть http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Template-Instantiation.html#Template-Instantiation

Специализации STL, основанные на указателях, могут иметь одну и ту же реализацию. Это потому, что (void *) имеет тот же размер, что и (int *) или (foo *). Так что пока:

vector 〈int〉 и vector 〈foo〉 - разные реализации.

vector 〈int *〉 и vector 〈foo *〉 могут иметь большую часть одной и той же реализации. Многие реализации STL делают это для экономии памяти.

Если весь шаблон определен в заголовке, поэтому он полностью определен, компиляторы, такие как g ++, автоматически создадут копию в каждой единице компиляции, используя класс. Как говорили другие, компоновщик удалит несколько определений.

Они также автоматически встраивают методы в определение класса для более высоких уровней оптимизации. Но этим можно управлять с помощью параметров компилятора.