Встраивание шаблонов
Небольшое предисловие: один из админов и автор последующих 5 постов уходит в отпуск на первые майские и будет недоступен. Выходить они будут отложенными публикациями. Так как мы особо не влияем на тексты друг друга, то второй админ может быть спокойно застан врасплох возможными неточностями постов и вашими комментариями. Так что прошу иметь это ввиду. Спасибо
Вот здесь мы поговорили о том, что методы класса - это по факту те же самые обычные функции, только для них первым параметром передается this. И если подумать 1.34 секунды, то можно понять, что взаимодействие класса с внешним миром происходит только за счет методов. А поля класса - это просто кусок памяти, из которого в разных ситуациях компилятор может достать ту или иную информацию. Получается, что низкоуровневый "код класса" - это набор низкоуровневого кода его методов(то есть обычных функций) и не более.
Получается, что возможна ситуация, когда компилятор встроит вызовы одного, нескольких или всех методов класса.
Шаблонные классы - хоть и неполноценные классы, но их инстанциации - да. Поэтому их методы также могут инлайниться, никаких исключений.
Обычные функции тоже могут встраиваться.
А константные шаблонные переменные после инстанциации могут не иметь имени, компилятор просто сразу подставит во все места использования конкретное значение.
Итого, получается, что у нас все шаблонные сущности могут быть встроены компилятором. Конечно же для этого должны быть включены оптимизации(но и без них может получиться).
Получается, что если мы в какой-то единице трансляции указываем явное объявление инстанциации с помощью extern template, и рассчитываем на неявную инстанциацию в другой единице трансляции, то мы спокойно можем нарваться на undefined reference.
Происходит это примерно так:
Знакомый пример, только пара модификаций. В хэдэре только объявление и определение шаблона. В ship.cpp пытаемся неявно инстанцировать строковую специализацию. Чтобы компилятор полностью не убирал код внутри foo за ненадобностью(тогда и ничего инстанцировать не нужно будет), сделаем так, чтобы она влияла на внешний мир. Добавим в шаблон поле, в методе его будем инкрементировать, и в foo выведем поле после модификации. В мэйне будем полагаться на инстанциацию в другой единице трансляции за счет extern template.
Вот если это попытаться скомпилировать(с оптимизациями) и собрать, то на линковке произойдет undefined reference. Компилятор увидел, что метод TurnShip слишком простой и его спокойно можно встроить и не генерировать для него определение. Что и происходит. А линкер в свою очередь из-за этого и не смог найти определение метода.
А божественным избавлением от этой проказы будет использование явной инстанциации. Она заставляет компилятор сгенерировать определение символа. Вызовы по прежнему могут инлайниться, но определение будет и мы сможем к нему обращаться.
Так что помните простое правило: на любое явное объявление инстанциации обязательно нужно предоставить явное определение инстанциации(1 на всю программу на каждое конкретное определение).
Rely on explicitly stated things. Stay cool.
#cppcore #template #compiler
Небольшое предисловие: один из админов и автор последующих 5 постов уходит в отпуск на первые майские и будет недоступен. Выходить они будут отложенными публикациями. Так как мы особо не влияем на тексты друг друга, то второй админ может быть спокойно застан врасплох возможными неточностями постов и вашими комментариями. Так что прошу иметь это ввиду. Спасибо
Вот здесь мы поговорили о том, что методы класса - это по факту те же самые обычные функции, только для них первым параметром передается this. И если подумать 1.34 секунды, то можно понять, что взаимодействие класса с внешним миром происходит только за счет методов. А поля класса - это просто кусок памяти, из которого в разных ситуациях компилятор может достать ту или иную информацию. Получается, что низкоуровневый "код класса" - это набор низкоуровневого кода его методов(то есть обычных функций) и не более.
Получается, что возможна ситуация, когда компилятор встроит вызовы одного, нескольких или всех методов класса.
Шаблонные классы - хоть и неполноценные классы, но их инстанциации - да. Поэтому их методы также могут инлайниться, никаких исключений.
Обычные функции тоже могут встраиваться.
А константные шаблонные переменные после инстанциации могут не иметь имени, компилятор просто сразу подставит во все места использования конкретное значение.
Итого, получается, что у нас все шаблонные сущности могут быть встроены компилятором. Конечно же для этого должны быть включены оптимизации(но и без них может получиться).
Получается, что если мы в какой-то единице трансляции указываем явное объявление инстанциации с помощью extern template, и рассчитываем на неявную инстанциацию в другой единице трансляции, то мы спокойно можем нарваться на undefined reference.
Происходит это примерно так:
// ship.hpp
#pragma once
template<typename T>
struct Ship
{
int i = 0;
void TurnShip(T command);
};
template <class T>
void Ship<T>::TurnShip(T command) {i++;}
// ship.cpp
#include "ship.hpp"
#include <string>
#include <iostream>
void foo() {
Ship<std::string> ship{};
ship.TurnShip(std::string{"Turn upside down"});
std::cout << ship.i << std::endl;
}
// main.cpp
#include "ship.hpp"
#include <string>
extern template class Ship<std::string>;
int main() {
Ship<std::string> ship;
ship.TurnShip(std::string{"Turn upside down"});
}
Знакомый пример, только пара модификаций. В хэдэре только объявление и определение шаблона. В ship.cpp пытаемся неявно инстанцировать строковую специализацию. Чтобы компилятор полностью не убирал код внутри foo за ненадобностью(тогда и ничего инстанцировать не нужно будет), сделаем так, чтобы она влияла на внешний мир. Добавим в шаблон поле, в методе его будем инкрементировать, и в foo выведем поле после модификации. В мэйне будем полагаться на инстанциацию в другой единице трансляции за счет extern template.
Вот если это попытаться скомпилировать(с оптимизациями) и собрать, то на линковке произойдет undefined reference. Компилятор увидел, что метод TurnShip слишком простой и его спокойно можно встроить и не генерировать для него определение. Что и происходит. А линкер в свою очередь из-за этого и не смог найти определение метода.
А божественным избавлением от этой проказы будет использование явной инстанциации. Она заставляет компилятор сгенерировать определение символа. Вызовы по прежнему могут инлайниться, но определение будет и мы сможем к нему обращаться.
Так что помните простое правило: на любое явное объявление инстанциации обязательно нужно предоставить явное определение инстанциации(1 на всю программу на каждое конкретное определение).
Rely on explicitly stated things. Stay cool.
#cppcore #template #compiler
Не всегда инстанциация шаблона нужна для работы программы
Возьмем пример из прошлого поста, объединим в хэдэре объявление шаблона с его определением и выкинем ship.cpp. И попробуем скомпилировать только main.cpp.
И неожиданно, все компилируется и выводится единичка. Почему так? Мы ведь почти ничего не поменяли даже просто нагло и беспардонно выкинули так нам необходимую единицу трансляции с явным инстанированием. Как это работает?
Дело в том, что любой метод, определенный внутри описания класса, неявно помечается inline. А на инлайн сущности не работает эффект подавления неявной специализации. Стандарт вот что говорит об этом:
Кажется, тут можно такую цепочку мыслей провести: компилятору запрещается делать неявную инстанциацию строкового корабля. Но он ее может и не делать, а просто встроить вызов метода этой инстанциации внутрь функции main и дело в шляпе! И ничего не нарушили и все работает.
Естественно, на это полагаться нельзя, потому что не любой метод может быть встроен, а значит компилятору придется проводить неявную инстанциацию. А мы как раз и добивались, чтобы этого не было. И правило "на любое явное объявление инстанциации обязательно нужно предоставить явное определение инстанциации" по-прежнему работает.
Просто интересно было показать, как такое небольшое изменение может развернуть ситуацию на 180. И кстати, если все-таки держать отдельно описание класса и его определение, но пометить метод inline, то будет тот же эффект, который я описал выше.
Pay attention to small details. Stay cool.
#template #compiler #cppcore
Возьмем пример из прошлого поста, объединим в хэдэре объявление шаблона с его определением и выкинем ship.cpp. И попробуем скомпилировать только main.cpp.
// ship.hpp
#pragma once
template<typename T>
struct Ship
{
int i = 0;
void TurnShip(T command) {i++;}
};
// main.cpp
#include "ship.hpp"
#include <string>
#include <iostream>
extern template class Ship<std::string>;
int main() {
Ship<std::string> ship;
ship.TurnShip(std::string{"Turn upside down"});
std::cout << ship.i << std::endl;
}
И неожиданно, все компилируется и выводится единичка. Почему так? Мы ведь почти ничего не поменяли даже просто нагло и беспардонно выкинули так нам необходимую единицу трансляции с явным инстанированием. Как это работает?
Дело в том, что любой метод, определенный внутри описания класса, неявно помечается inline. А на инлайн сущности не работает эффект подавления неявной специализации. Стандарт вот что говорит об этом:
Except for inline functions and class template specializations,
explicit instantiation declarations have the effect of suppressing
the implicit instantiation of the entity to which they refer.
Кажется, тут можно такую цепочку мыслей провести: компилятору запрещается делать неявную инстанциацию строкового корабля. Но он ее может и не делать, а просто встроить вызов метода этой инстанциации внутрь функции main и дело в шляпе! И ничего не нарушили и все работает.
Естественно, на это полагаться нельзя, потому что не любой метод может быть встроен, а значит компилятору придется проводить неявную инстанциацию. А мы как раз и добивались, чтобы этого не было. И правило "на любое явное объявление инстанциации обязательно нужно предоставить явное определение инстанциации" по-прежнему работает.
Просто интересно было показать, как такое небольшое изменение может развернуть ситуацию на 180. И кстати, если все-таки держать отдельно описание класса и его определение, но пометить метод inline, то будет тот же эффект, который я описал выше.
Pay attention to small details. Stay cool.
#template #compiler #cppcore
Преимущества использования extern template
C++ известен долгой компиляцией программ. И одной из причин такого поведения является наличие шаблонов в языке. За счет того, что стандарт допускает больше одной конкретной инстанциации шаблона в программе, люди сильно расслабляются. Мало кто знает, как правильно организовывать и использовать шаблонный код. В большинстве случаев он просто находится в хэдэре и подключается во всевозможные места. Соответсвенно, в каждой TU, куда подключается хэдэр, будет своя копия инстанциации. Но это же не просто сама копия, на компиляцию всех копий тратится время.
А если используются какие-нибудь кодогенераторы, типа grpc-шного или soap-ного, то там реально может быть очень много единиц трансляции. И в каждой будет своя копия какого-нибудь вектора или опшинала.
И хотя для STL-ных сущностей extern template ничем не поможет(об этом в другом посте), для самописных шаблонов, расположенных в хэдэрах - подойдет. Адекватную организацию кода при использовании extern template, мы осветили тут https://t.me/grokaemcpp/226.
Но какие конкретно преимущества дает такой способ организации шаблонного кода?
1) Уменьшение размеров объектных файлов скомпилированных единиц трансляции. При сборке больших проектов у вас скорее всего сгенерируются сотни, если не тысячи объектных файлов или либок, которые за счет загромождения инстанциациями могут весить десятки и сотни мегабайт. Не каждый себе может позволить на машинке такой билд, который помимо полезных исполняемых файлов будет содержать огромное количество объектников с дублирующимся миллион раз кодом. extern template запрещает неявную инстанциацию шаблонов, а значит среди всех объектников будет только один, который и будет содержать нужную инстанциацию.
2) Уменьшение времени компиляции. Компилятору запретили генерировать код, а значит много лишних действий убирается и сокращается время компиляции.
3) Сокращение времени линковки. Вот это не прям очевидный пункт. Чем объемнее объектные файлы - тем больше линкеру работы. А учитывая, что для дедуплицирования инстанциаций нужно найти эти одинаковые дубли, сопоставить их, выбрать один и убрать все остальные, то задача уже не кажется такой простой.
4) Любой код, который подключит ваш заголовочник, сможет инстанцировать или найти любой explicit template instantiation, который захочет. Через extern template мы запретим компилятору самостоятельно генерировать эти инстанциации. Но если для какого-то шаблонного параметра не будет прописан extern template, то компилятор сможет сам неявно конкретизировать шаблон с этим параметром. Поэтому в этом плане, это очень гибкий инструмент.
Из-за последнего пункта такой способ организации кода подойдет для частоиспользуемых шаблонов, которые инстанцируются с большим многообразием параметров. Просто в цппшнике можно предоставить самые популярные варианты инстанциаций, которые будут давать большой импакт в увеличении времени компиляции и наиболее часто будут дублироваться. Остальное компилятор сможет сам неявно инстанцировать.
Если внешняя библиотека завязана на ваш шаблон, то это единственный способ адекватно предоставить ей доступ к коду.
Однако есть способ организации кода, при котором будут все те же плюсы, плюс еще плюсы, минус лишней работы, но потеряем немного гибкости. Но об этом завтра.
Find benefits of using different things in various situations. Stay cool.
#cppcore #template #compiler
C++ известен долгой компиляцией программ. И одной из причин такого поведения является наличие шаблонов в языке. За счет того, что стандарт допускает больше одной конкретной инстанциации шаблона в программе, люди сильно расслабляются. Мало кто знает, как правильно организовывать и использовать шаблонный код. В большинстве случаев он просто находится в хэдэре и подключается во всевозможные места. Соответсвенно, в каждой TU, куда подключается хэдэр, будет своя копия инстанциации. Но это же не просто сама копия, на компиляцию всех копий тратится время.
А если используются какие-нибудь кодогенераторы, типа grpc-шного или soap-ного, то там реально может быть очень много единиц трансляции. И в каждой будет своя копия какого-нибудь вектора или опшинала.
И хотя для STL-ных сущностей extern template ничем не поможет(об этом в другом посте), для самописных шаблонов, расположенных в хэдэрах - подойдет. Адекватную организацию кода при использовании extern template, мы осветили тут https://t.me/grokaemcpp/226.
Но какие конкретно преимущества дает такой способ организации шаблонного кода?
1) Уменьшение размеров объектных файлов скомпилированных единиц трансляции. При сборке больших проектов у вас скорее всего сгенерируются сотни, если не тысячи объектных файлов или либок, которые за счет загромождения инстанциациями могут весить десятки и сотни мегабайт. Не каждый себе может позволить на машинке такой билд, который помимо полезных исполняемых файлов будет содержать огромное количество объектников с дублирующимся миллион раз кодом. extern template запрещает неявную инстанциацию шаблонов, а значит среди всех объектников будет только один, который и будет содержать нужную инстанциацию.
2) Уменьшение времени компиляции. Компилятору запретили генерировать код, а значит много лишних действий убирается и сокращается время компиляции.
3) Сокращение времени линковки. Вот это не прям очевидный пункт. Чем объемнее объектные файлы - тем больше линкеру работы. А учитывая, что для дедуплицирования инстанциаций нужно найти эти одинаковые дубли, сопоставить их, выбрать один и убрать все остальные, то задача уже не кажется такой простой.
4) Любой код, который подключит ваш заголовочник, сможет инстанцировать или найти любой explicit template instantiation, который захочет. Через extern template мы запретим компилятору самостоятельно генерировать эти инстанциации. Но если для какого-то шаблонного параметра не будет прописан extern template, то компилятор сможет сам неявно конкретизировать шаблон с этим параметром. Поэтому в этом плане, это очень гибкий инструмент.
Из-за последнего пункта такой способ организации кода подойдет для частоиспользуемых шаблонов, которые инстанцируются с большим многообразием параметров. Просто в цппшнике можно предоставить самые популярные варианты инстанциаций, которые будут давать большой импакт в увеличении времени компиляции и наиболее часто будут дублироваться. Остальное компилятор сможет сам неявно инстанцировать.
Если внешняя библиотека завязана на ваш шаблон, то это единственный способ адекватно предоставить ей доступ к коду.
Однако есть способ организации кода, при котором будут все те же плюсы, плюс еще плюсы, минус лишней работы, но потеряем немного гибкости. Но об этом завтра.
Find benefits of using different things in various situations. Stay cool.
#cppcore #template #compiler
Другой способ организации шаблонного кода
В чем недостаток способа из предыдущего поста? В том, что при любом изменении шаблона, придется перекомпилировать все единицы трансляции, которые его включают. Весь код находится в хэдэре, значит TU будет в себе содержать полное определение сущности. Значит, любое незначительное изменение реализации приводит к перекомпиляции.
Не зря люди придумали разделение кода на объявление сущности в хэдэре и ее реализацию в цппшнике. Внешний интерфейс класса/сигнатура функции меняются не так часто. А вот изменение деталей реализации при разработке - дело само собой разумеющееся и это происходит на каждой итерации билда при отладке кода.
При использовании подхода с разделением на хэдэр и сорец, при изменении реализации мы перекомпилируем только сорец. И все остальные TU не будут нуждаться в перекомпилировании. А при линковке они просто будут обращаться за нужными символами в обновленную TU исходников сущности.
Таким образом, мы хоть и не увеличиваем изначальную скорость компиляции, но увеличиваем ее при перекомпиляции исходников во время отладки. Я считаю, что это даже больший плюс. Потому что при отладке кода, мы его мильён раз изменяем и на каждую попытку ждать несколько минут - это зашквар. Так программисты и спиваются. Надо же что-то делать пока билд собирается?
Плюс из-за помещения определения в хэдэр, вы не можете распространять свои исходники без раскрытия деталей реализации. Код - бедная, тонкая, голая и стесняющаяся чужих людских глаз натура. Зачем вы его показываете на общее обозрение? Уважьте малыша. Спрячьте его.
Еще один плюс - удобство чтения кода и его организации. Очень часто нам нужно узнать только публичный интерфейс класса, без погружения в детали. Заголовочник с одним объявлением сущности сильно помогает в этом.
Ну и в мире коммерческой разработки на С++ в принципе принято разделение на сорцы и хэдэры. Поэтому, зачастую, инфраструктура проекта завязвна на этой негласной договоренности. И часто бывает непонятно, куда запихать обособленный заголовочник.
Единственный способ, при котором мы можем использовать разделение объявления и определения по разным файлам с шаблонами - мы должны точно знать, с какими параметрами будет инстанцироваться наш шаблон и в цппшнике предоставить явное его инстанцирование с этими параметрами.
И это большое ограничение. Но часто ли вы пишете шаблонный код, у которого вы прям не знаете полный набор возможных шаблонных параметров на данный момент? Средний разработчик не так часто это делает. И вот во всех случаях, когда вы на данный момент точно знаете полное множество возможных шаблонных параметров, стоит использовать именно тот способ, который описан в предыдущем абзаце или в этом посте.
И не нужно нигде писать никакой extern! Компилятор из объявления сам ничего не может инстанцировать, поэтому главная задача extern template решается автоматически.
Вы мне скажете, что нужно будет постоянно следить за новопоявившимися параметрами и добавлять явные инстанциации шаблона с ними в цппшник. И я вам отвечу: это правда. Просто в этом случае следить очень просто: у вас перестает компилироваться код)
Однако это лучше, чем в подходе в extern. Если здесь не уследить за новым шаблонным параметров, то компилятор сам сможет неявно с ним инстанцировать шаблон и тогда будут проявляться все негативные эффекты, которых мы и хотели избежать, использовав extern template.
Последние 2 поста - кульминация всей серии и реальная практическая выжимка из всего того, что мы уже обсудили. Выбирайте то, что подходит вашей ситуации. Надеюсь, я вас убедил в пользе явной инстанциации шаблонов. Еще один пост и мы заканчиваем этувсем уже немного поднадоевшую долгую историю.
Choose the proper tool. Stay cool.
#template #compiler #cppcore
В чем недостаток способа из предыдущего поста? В том, что при любом изменении шаблона, придется перекомпилировать все единицы трансляции, которые его включают. Весь код находится в хэдэре, значит TU будет в себе содержать полное определение сущности. Значит, любое незначительное изменение реализации приводит к перекомпиляции.
Не зря люди придумали разделение кода на объявление сущности в хэдэре и ее реализацию в цппшнике. Внешний интерфейс класса/сигнатура функции меняются не так часто. А вот изменение деталей реализации при разработке - дело само собой разумеющееся и это происходит на каждой итерации билда при отладке кода.
При использовании подхода с разделением на хэдэр и сорец, при изменении реализации мы перекомпилируем только сорец. И все остальные TU не будут нуждаться в перекомпилировании. А при линковке они просто будут обращаться за нужными символами в обновленную TU исходников сущности.
Таким образом, мы хоть и не увеличиваем изначальную скорость компиляции, но увеличиваем ее при перекомпиляции исходников во время отладки. Я считаю, что это даже больший плюс. Потому что при отладке кода, мы его мильён раз изменяем и на каждую попытку ждать несколько минут - это зашквар. Так программисты и спиваются. Надо же что-то делать пока билд собирается?
Плюс из-за помещения определения в хэдэр, вы не можете распространять свои исходники без раскрытия деталей реализации. Код - бедная, тонкая, голая и стесняющаяся чужих людских глаз натура. Зачем вы его показываете на общее обозрение? Уважьте малыша. Спрячьте его.
Еще один плюс - удобство чтения кода и его организации. Очень часто нам нужно узнать только публичный интерфейс класса, без погружения в детали. Заголовочник с одним объявлением сущности сильно помогает в этом.
Ну и в мире коммерческой разработки на С++ в принципе принято разделение на сорцы и хэдэры. Поэтому, зачастую, инфраструктура проекта завязвна на этой негласной договоренности. И часто бывает непонятно, куда запихать обособленный заголовочник.
Единственный способ, при котором мы можем использовать разделение объявления и определения по разным файлам с шаблонами - мы должны точно знать, с какими параметрами будет инстанцироваться наш шаблон и в цппшнике предоставить явное его инстанцирование с этими параметрами.
И это большое ограничение. Но часто ли вы пишете шаблонный код, у которого вы прям не знаете полный набор возможных шаблонных параметров на данный момент? Средний разработчик не так часто это делает. И вот во всех случаях, когда вы на данный момент точно знаете полное множество возможных шаблонных параметров, стоит использовать именно тот способ, который описан в предыдущем абзаце или в этом посте.
И не нужно нигде писать никакой extern! Компилятор из объявления сам ничего не может инстанцировать, поэтому главная задача extern template решается автоматически.
Вы мне скажете, что нужно будет постоянно следить за новопоявившимися параметрами и добавлять явные инстанциации шаблона с ними в цппшник. И я вам отвечу: это правда. Просто в этом случае следить очень просто: у вас перестает компилироваться код)
Однако это лучше, чем в подходе в extern. Если здесь не уследить за новым шаблонным параметров, то компилятор сам сможет неявно с ним инстанцировать шаблон и тогда будут проявляться все негативные эффекты, которых мы и хотели избежать, использовав extern template.
Последние 2 поста - кульминация всей серии и реальная практическая выжимка из всего того, что мы уже обсудили. Выбирайте то, что подходит вашей ситуации. Надеюсь, я вас убедил в пользе явной инстанциации шаблонов. Еще один пост и мы заканчиваем эту
Choose the proper tool. Stay cool.
#template #compiler #cppcore
extern template с шаблонами STL
Обещал рассказать, почему вы не сможете подавить неявную инстанциацию для STL сущностей. Это будет хорошим завершением серии, потому что включает множество обсужденных концепций и особенностей.
Оговорюсь, что буду говорить за реализацию стандартной библиотеки от gcc.
Начнем с того, что фичи стандартных шаблонов распространяются и подключаются с помощью хэдэр-файлов. И если внимательно посмотреть на эти хэдэра, то мы можем увидеть, что авторы библиотеки помещают методы шаблонных классов внутрь определения классов(за все-превсе классы не могу сказать, но тенденция явно проглядывается).
Далее. Единственным способом запретить неявное инстанцирование при распространении кода с помощью заголовочников - с помощью extern template. Все конкретизации мы не можем запретить, но самые популярные - можем попробовать. В случае успеха это будет давать большой импакт к уменьшению времени компиляции и размеру объектников.
А в недавнем посте "Не всегда инстанциация шаблона нужна для работы программы" мы поговорили о том, что методы, определенные внутри описания класса, неявно помечаются inline. А для inline функций запрет на неявное инстанцирование не работает!
Поэтому для шаблонов STL(под этим акронимом я понимаю все шаблонные классы стандартной библиотеки) вы просто не сможете получить никакого профита от extern template. Стандарт это явно запрещает.
Получается, что все разговоры про запрет или ограничение неявного инстанцирования касаются лишь только кастомного кода. Ограничения на стандартные инструменты наложить не получится, как и поиметь соотвествующих плюшек. Sad, but true. Об этой особенности очень мало говорят даже в англоязычном пространстве. Поэтому вы теперь элита и эксперты в правильной организации шаблонного кода.
Use your tools in proper places. Stay cool.
#cpcore #template #compiler
Обещал рассказать, почему вы не сможете подавить неявную инстанциацию для STL сущностей. Это будет хорошим завершением серии, потому что включает множество обсужденных концепций и особенностей.
Оговорюсь, что буду говорить за реализацию стандартной библиотеки от gcc.
Начнем с того, что фичи стандартных шаблонов распространяются и подключаются с помощью хэдэр-файлов. И если внимательно посмотреть на эти хэдэра, то мы можем увидеть, что авторы библиотеки помещают методы шаблонных классов внутрь определения классов(за все-превсе классы не могу сказать, но тенденция явно проглядывается).
Далее. Единственным способом запретить неявное инстанцирование при распространении кода с помощью заголовочников - с помощью extern template. Все конкретизации мы не можем запретить, но самые популярные - можем попробовать. В случае успеха это будет давать большой импакт к уменьшению времени компиляции и размеру объектников.
А в недавнем посте "Не всегда инстанциация шаблона нужна для работы программы" мы поговорили о том, что методы, определенные внутри описания класса, неявно помечаются inline. А для inline функций запрет на неявное инстанцирование не работает!
Поэтому для шаблонов STL(под этим акронимом я понимаю все шаблонные классы стандартной библиотеки) вы просто не сможете получить никакого профита от extern template. Стандарт это явно запрещает.
Получается, что все разговоры про запрет или ограничение неявного инстанцирования касаются лишь только кастомного кода. Ограничения на стандартные инструменты наложить не получится, как и поиметь соотвествующих плюшек. Sad, but true. Об этой особенности очень мало говорят даже в англоязычном пространстве. Поэтому вы теперь элита и эксперты в правильной организации шаблонного кода.
Use your tools in proper places. Stay cool.
#cpcore #template #compiler
