​Линковочная природа шаблонов

Когда мы говорим про шаблоны и их линковку, нам важно видеть все детали общей картины. Иначе полное понимание так и не придет. Поэтому сегодня немного больше приоткроем линковочные тайны темплейтов.

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

Представим, что мы разрабатываем какое-то приложение или отдельный сервис. Этот сервис состоит из отдельных кодовых модулей, которые отдельно компилируются и линкуются вместе для получения готового бинарника. Так вот очень легко допустить, что во многих модулях одного и того же сервиса используется вектор интов. std::vector<int>. Обычно мы просто инклюдим в эти модули хэдэр вектора и после используем его. Таким образом происходит неявная инстанциация. То есть компилятор на этапе компиляции модулей сам инстанциацирует интовую специализацию вектора в каждой единице трансляции и использует ее в коде текущего юнита.

Однако, погодите-ка. То есть у нас в нескольких единицах трансляции есть одна и та же скомпилированная сущность и при линковке это не вызывает никаких проблем. Как так?

Вот, что стандарт говорит по поводу этого:

There can be more than one definition in a program of each of the following: 
class type, enumeration type, inline function, inline variable(since C++17), 
templated entity(template or member of template, but not full template specialization), 
as long as all of the following is true[...]

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

И кстати, утверждение, что шаблоны неявно помечены inline - неверно. Но об этом позже.

За счет чего допускается возможность наличия нескольких определений сущности в программе? Если вы читали гайд по inline(можете найти в закрепе), то, наверняка, знаете ответ. За счет слабых символов.

Скомпилируем гццшкой самую простенькую функцию:

void foo() {
  std::vector<int> vec(10);
  vec[0] = 1;
}

А утилитка nm покажет нам природу символов в бинаре. Там будет генерироваться оч много функций и символов связанных с вектором, поэтому разберем только один пример с конструктором, символ которого выглядит так:

0000000000000000 W std::vector<int, std::allocator<int> >::vector(unsigned long, std::allocator<int> const&)

Вот эта буковка W говорит, что этот символ - слабый. А слабые символы могут быть перезаписаны во время линковки. Линковщик просто сам выберет одно понравившееся ему определение из всех существующих в программе и перезапишет им остальные. Таким образом в программе останется всего одно определение шаблона и все будут ссылаться на него. Однако все равно до линковки во всех единицах трансляции будет своя копия интовой инстанциации шаблона.

Use your weaknesses to solve your problems. Stay cool.

#compiler #cppcore #template

​Шаблоны не подразумевают inline

Дисклеймер: в этом посте слово "специализация" будет значить конкретную программную сущность, объявленную через template<> с пустыми треугольными скобками, которая переопределяет поведения шаблона для конкретного типа.

В прошлом посте кратко коснулись этого. Сегодня разберемся в этом подробнее.

Мы уже знаем, что в программе может быть больше одного определения шаблона и это нормально. Ровно также может быть больше одного определения inline сущности. Так есть ли между этими утверждениями связь?

Очевидно, классы не могут быть inline. Разговор здесь пойдет только про inline функции и переменные(с С++14).

Во-первых, стандарт ничего не говорит по поводу того, что шаблоны по умолчанию inline. Хотя, например, для constexpr функций и статических полей класса это явно описано.

Во-вторых, в нем есть пара слов про явные специализации

Whether an explicit specialization of a function or variable template is inline, 
constexpr, constinit, or consteval is determined by the explicit specialization and 
is independent of those properties of the template. Similarly, attributes appearing 
in the declaration of a template have no effect on an explicit specialization of that 
template...

Эта строчка говорит нам о том, что спецификаторы, которыми помечены явные специализации, могут не совпадать со спецификаторами самих шаблонов. Значит, что шаблоны имеет смысл помечать inline и мы даже может можем изменить это поведение в явной специализации. А значит, шаблоны не подразумевают inline. Их поведение только лишь схоже с inline сущностими в плане обхода ODR. Пример из стандарта:

template<class T> void f(T) { /* ... */ } 
template<class T> inline T g(T) { /* ... */ } 

template<> inline void f<>(int) { /* ... */ } // OK, inline 
template<> int g<>(int) { /* ... */ } // OK, not inline

Здесь нужно быть аккуратным, потому что на явные специализации распространяется ODR. Явные специализации - уже не шаблоны, поэтому, если вы хотите поместить их в хэдэр, то нужно помечать их inline, чтобы линковщик не ругался.

Если инлайн в нынешнее время в основном используется для обхода ODR, то есть ли смысл помечать шаблонные функции этим ключевым словом?

Особого смысла нет(помимо явных специализаций). Темплейты и так не подвержены ODR. А в остальном инлайн только лишь указывает компилятору, чтобы он сделал проверку на возможность inline expansion. Но он в принципе и так это делает для всех функций.

Differentiate things apart. Stay cool.

#template #cppcore #cpp14 #compiler

Когда стоит использовать explicit template declaration

Мы поговорили о случае, в котором бесполезно использовать explicit template declaration. Теперь поговорим о наиболее уместном и логичном способе использования этой фичи.

Главная функция extern template - запретить компилятору неявную инстанциацию. Значит, для адекватного использования этой конструкции компилятору необходимо иметь возможность выполнить эту неявную инстанциацию. Единственным подходящим ситуации вариантом здесь будет нахождение полного определения шаблона в хэдэре, чтобы его могли видеть все заинтересованные лица(пофантизируйте в комментариях, как могло бы выглядеть лицо у единицы трансляции).

Дальше есть следующие 2 варианта - поместить все явные объявления инстанциации шаблона в этот же хэдэр и распихать по единицам трансляции. Как по мне, лучше иметь одну централизированную точку изменений, так как программисты - люди забывчивые и могут упустить момент добавления нового явного объявления и компилятор сам сделает неявную инстанциацию. Да и если помещать в разные места, то это приведет к дубликации кода. Поэтому оставляем extern template в хэдэре.

Ну и последний момент. Если есть явное объявление инстанциации, должно быть и ее явное определение. Причем это ВАЖНО. Нельзя при использовании extern template полагаться на неявную инстанциацию. В нашем случае это уже невозможно, потому что мы добавили в хэдэр с шаблоном запрет на неявную инстанциацию, но я все равно хочу на это обратить ваше внимание. Компилятор может ее оптимизировать, так что для нее больше не останется отдельно скомпилированной сущности и все вызовы просто встроятся. Тогда компановщик не сможет разрезолвить символы и будет undefined reference. Чуть позже расскажу об этом в отдельном посте.
Итак, explicit template instantiation. Мы помещаем явные определения всех нужных нам неявных специализаций в отдельный цппшник. И вот к коду в этой TU будет обращаться линкер, чтобы подставить адреса нужных вызовов. А в других TU не будет сгенерировано ничего связанного с шаблоном.

Продемонстрирую на примере:

// ship.hpp

#pragma once
#include <string>
template<typename T>
struct Ship
{
  // contain some fields
  void TurnShip(T command);
};

template <class T>
void Ship<T>::TurnShip(T command) {/* do stuff using command */}

extern template class Ship<std::string>; // text command
extern template class Ship<int>; // turn certain number of degrees clockwise

// ship.cpp

#include "ship.hpp"

template class Ship<std::string>;
template class Ship<int>;

// main.cpp

#include "ship.hpp"
#include <string>

int main() {
  Ship<std::string> ship;
  ship.TurnShip(std::string{"Turn upside down"});
  Ship<int> ship1; // i know it's silly to instantiate 2 version of
                  // ship just to have a different style of turning,
                 // but stick to the goodold example
  ship1.TurnShip(36'000); // just trying to make a giant whirlpool 
}

Если мы отдельно скомпилируем main.cpp и посмотрим на символы объектника, то там будет только то, что связано с std::basic_string, но не с Ship. Как и было задумано.

Подводя итог: нам нужен хэдэр с полным определением шаблона и явными объявлениями extern template и сорец с явными определениями этих инстанциаций. Теперь мы можем везде тыкать наш хэдэр и ожидать уменьшения времени компиляции и меньшего размера объектников.

Choose the right way. Stay cool.

#template #compiler #cppcore

​экспресс совет

Cнова ненадолго отвлечемся от шаблонов.

В моем программистком детстве меня всегда бесило, что когда мне нужно беззнаковое 32-битное число, мне приходилось писать это длинное unsigned. А если нужно большое беззнаковое - то вообще unsigned long long. Фу прям.

Да, size_t тоже представляет собой беззнаковое 64-битное число. Но я большой фанат семантики типов, а size_t обозначает размер чего-то. А не всегда числа представляют собой размер.

Но есть выход! Подключаете <cstdint> и кайфуете с человеческим представлением типов
std::int8_t
std::uint8_t
std::int16_t
std::uint16_t
std::int32_t
std::uint32_t
std::int64_t
std::uint64_t
и еще несколько менее важных(мб потом обсудим)

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

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

Эти тайпдефы появились в стандарте с С++11. Раньше приходилось подключать сишный stdint.h. Этот хэдэр предоставляет те же алиасы с теми же свойствами, но без "std::". Это конечно не по-христианскиплюсовому, но для ленивых неяростных адептов с++ отлично подойдет.

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

В общем, кто пользуется - меня поддержит, кто еще нет - берите на заметку.

Stay laconic. Stay cool.

#cppcore #cpp11

​std::for_each

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

Чем она хороша? В подходящих условиях она дает больше семантики по сравнению с "конкурентами".

Например, есть range-based-for цикл. Он записывается примерно так:

for(auto & traitor: traitors) {
  // exquisitely torture the traitor
}

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

Но если такой логики нет и мы просто делаем определенную операцию над каждым элементом, то создается совершенно лишнее напряжение, которого можно было бы избежать. И этому побегу поможет std::for_each.

Функция имеет явную семантику: для каждого элемента последовательности выполняется вот эта функция. И все. Думать много не нужно. Нужно просто понять, как преобразуется или обрабатывается элемент и дело в шляпе.

Но не каждый знает, что эта функция возвращает не void, а тот же тип унарной операции, что мы передали в нее. Значит мы можем использовать stateful операции, то есть функциональные объекты, и сохранять результат вычислений в этом объекте не используя никакие глобальные переменные, ссылки и прочее. Стандарт гарантирует, что возвращаемое значение for_each содержит финальное состояния функтора после завершения операций над всеми элементами.

Эта особенность может пригодиться, когда помимо обработки элемента необходимо собрать по ним статистику. Допустим, я хочу убрать из массива строк все пробелы и сосчитать, сколько в среднем на каждую строку приходится пробелов. И тут как бы вроде скорее всего наверное вероятно лучше std::transform подходит(по семантике основной операции), но все портит сбор статистики. Можно засунуть в трансформ лямбду со ссылкой на внешний счетчик, но по смыслу это уже не будет чистая трансформация строк. Поэтому можно подобрать менее точечный по предназначению алгоритм, но он лучше подходит этой ситуации. Единственное, что лямбду нельзя будет использовать.

Пример:

struct SpaceHandler {
  void operator()(std::string& str) {
    auto new_end_it = std::remove_if(str.begin(), str.end(), [](const auto & ch){ return ch == ' ';});
    space_count += str.size() - std::distance(str.begin(), new_end_it);
    str.erase(new_end_it, str.end());
  }
  int space_count {0};
};

int main() {
  std::vector<std::string> container = {"Ole-ole-ole ole", "C++ is great!",
  "Just a random string just to make third elem"};
  int i = std::for_each(container.begin(), container.end(), SpaceHandler()).space_count;
  std::for_each(container.begin(), container.end(), [](const auto& str) { std::cout << str << std::endl;});
  std::cout << "Average number of spaces is " << static_cast<double>(i) / container.size() << std::endl;
}

//Output

Ole-ole-oleole
C++isgreat!
Justarandomstringjusttomakethirdelem
Average number of spaces is 3.66667

Здесь мы используем функтор SpaceHandler, для которого перегружен оператор круглые скобки. За счет чего мы в этом операторе может сохранять вычисления в поля класса SpaceHandler. Чем мы и воспользовались для подсчета статистики.

Большое неудобство с этими лямбдами, но нам пока не позволено доставать из них поля класса, так что выживаем, как можем.

Кстати, с С++20 std::for_each стал constexpr, что позволяет удобнее обрабатывать наборы данных во время компиляции .

Use proper tools. Stay cool.

#cppcore #cpp20 #algorithms

​Как узнать, что constexpr функция вычисляется в compile time

C constexpr функциями есть один прикол - они могут вычисляться и в рантайме, и компайлтайме. Но вот какой момент: мы же не зря пометили их constexpr. Нам важно, чтобы в тот момент, когда мы хотели разгрузить рантайм, он действительно разгружался. Не всегда просто бывает сходу понять, что все аргументы функции тоже являются вычислимыми во время компиляции. А это, собственно, одно из основных условий того, что и сама функция вычислится в это время.

Так вот интересно: а можно ли как-то убедиться в том, что выражение вычислено в compile-time?

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

⚡️ Присвоить значение выражения constexpr переменной. Они могут инициализироваться только значениями, доступными на этапе компиляции, поэтому вам сразу же компилятор выдаст ошибку "constexpr variable must be initialized by a constant expression", если вы попытаетесь передать в функцию не constexpr значение.

constexpr int JustRandomUselessFunction(int num) {
  return num + 1;
}

int main() {
  int usual_runtime_var = 0;
  constexpr int error = JustRandomUselessFunction(usual_runtime_var); 
  //👆🏿Error: constexpr variable must be initialized by a constant expression
  constexpr int constexpr_var = 5;
  constexpr int ok = JustRandomUselessFunction(constexpr_var); 
  //👆🏿 OK since constexpr_var is constexpr
}

Правда, здесь есть ограничение, что void выражения таким макаром не проверить.

⚡️ Поместить вызов функции в static_assert. Эта штука может проверять только вычислимые на этапе компиляции условия, поэтому компилятор опять же вам подскажет, облажались вы или нет.

constexpr int JustRandomUselessFunction(int num) {
  return num + 1;
}

int main() {
  int usual_runtime_var = 0;
  constexpr int constexpr_var = 5;
  static_assert(JustRandomUselessFunction(usual_runtime_var)); 
  //👆🏿 Error: static assertion expression is not an integral constant expression
  static_assert(JustRandomUselessFunction(constexpr_var)); // OK
}

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

⚡️ Использовать фичу С++20 - std::is_constant_evaluated(). Если коротко, то она позволяет внутри функции определить в каком контексте она вычисляется: constant evaluation context или runtime context. Здесь есть и практическая польза: в зависимости от контекста мы можем использовать constexpr-френдли операции(их набор довольно сильно ограничен и придется попотеть, чтобы что-то сложное реализовать) или обычные. Но для наших целей мы можем вот как использовать: мы можем заветвиться по контексту и вернуть из функции какое-то уникальное значение, которое соответствует только compile-time ветке. И уже по итоговому результату понять, когда произошли вычисления. А дальше уже набрасывать реальный код в ветки. Например:

constexpr int CalculatePeaceNumber(double base)
{
  if (std::is_constant_evaluated())
  {
    return 666; // That's how we can be sure about compile time evaluation
  }
  else
  {
    // some peaceful code
    return 0; // true balance and peace
  }
}

constexpr double pi = 3.14;

int main() {
  const int result = CalculatePeaceNumber(pi);
  std::cout << result << " " << CalculatePeaceNumber(pi) << std::endl;
}

//Output
666 0

Обратите внимание, что здесь используется обычный if, потому что в if constexpr is_constant_evaluated будет всегда возвращать true(в нем условие всегда в compile-time поверяется).

Наверняка, есть еще способы. Если знаете, напишите их в комментарии)

Check context of your life. Stay cool.

#cpp20 #cpp11 #compiler

Квиз

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

#include <iostream>

int main() {
    int i = 10;
    std::cout << (i & 1 == 0);
}

Какой будет вывод у этого кода?

Нормальный человек подумает, что ответ на вопрос выше: 1. Но компьютер не человек, как и те, кто помнят наизусть приоритет операций😆. Эти машины ответят 0. Почему?

Потому что приоритет оператора сравнения больше приоритета битового И. Поэтому в начале сравнятся 1 и 0. Будет 0. А И с нулем будет всегда нуль. Ожидаемым результат будет, если расставить скобки:

#include <iostream>

int main() {
    int i = 10;
    std::cout << ((i & 1) == 0);
}

Чтобы вас больше нельзя было перехитрить, приведу здесь приоритеты операций в С++.

1. Постфиксный инкремент/декремент: ++, --
2. Вызов функции: ()
3. Индексный доступ: []
4. Доступ к члену: ., ->
5. Префиксный инкремент/декремент: ++, --, унарный плюс (+), унарный минус (-), логическое отрицание (!), побитовое дополнение (~), разыменование (*), взятие адреса (&), приведение типа (static_cast, dynamic_cast, reinterpret_cast, const_cast), sizeof
6. Операторы умножения: *, /, %
7. Операторы сложения: +, -
8. Побитовые сдвиги: <<, >>
9. Операторы сравнения: <, >, <=, >=
10. Операторы равенства: ==, !=
11. Побитовое И: &
12. Побитовое исключающее ИЛИ: ^
13. Побитовое ИЛИ: |
14. Логическое И: &&
15. Логическое ИЛИ: ||
16. Тернарный оператор: ? :
17. Операторы присваивания: =, +=, -=, *=, /=, %=, <<=, >>=, &=, ^=, |=
18. Оператор запятой: ,

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

Компилятор, кстати, может стать тут вашим помощником. Какие-то из них и без опций показывают ворнинг об опасности неожиданных результатов из-за порядка приоритета операций. Но чтобы было наверяка, просто добавьте опции компиляции -Wall -Wextra(ну или на крайняк -Wparentheses) и вам обязательно все покажут и расскажут, что вы за черт по жизни где вы могли бы облажаться.

Stay alert. Stay cool.

Мюсли подписчиков

Запускаем еще одну рубрику на канале: мюсли подписчиков. Здесь будут публиковаться их полнотекстовые статьи или небольшая превьюха к статье с ссылкой на оригинал.

Сегодняшним дебютантом будет наш добрый ленивец - @topin89.

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

И такой способ есть! Называется контейнеризация. Обычно этот термин ассоциируется с каким-нибудь Docker'ом. Однако он не совсем подходит для создания окружения-как-ОС(рабочего окружения).

Автор статьи предлагает вам попробовать более подходящий инструмент для этого - systemd-nspawn. Хотя это даже не статья, а гайд по установке, настройке и минимальному запуску контейнеров с рабочим окружением. Причем такой гайд, что я прям охренел от степени проработки и подробности. Появился вопрос - далее по тексту определенно появится ответ. Все четко, структурировано и по делу. На все действия даны комментарии, так что вы точно будете знать, для чего предназначена та или иная строчка или команда.

В общем, крутой гайд от крутого специалиста и олда нашего канала. С вопросами по содержимому статьи можете приходить прямо к нему.

Ссылочка на статью вот. https://gist.github.com/topin89/f5078164e3dc53bd48838277baeb0d3b

Спасибо, Михаил, за то, что делитесь знаниями)

Share your knowledge. Stay cool.

#мюслиподписчиков

​Встраивание шаблонов

Небольшое предисловие: один из админов и автор последующих 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.

// 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

​Другой способ организации шаблонного кода

В чем недостаток способа из предыдущего поста? В том, что при любом изменении шаблона, придется перекомпилировать все единицы трансляции, которые его включают. Весь код находится в хэдэре, значит 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

Квиз

Возвращаемся в рабочие будни с интересным(надеюсь) #quiz'ом. Многие знают, что такой код писать нельзя, но не знают, почему и что будет в результате таких неправильных действий. Сегодня вечером и разберемся во всех тонкостях. А сейчас пытаемся сами понять, что будет при попытке запуска этого кода?

#include <iostream>
struct Class
{
    Class(int init) : c{init}, b{c}, a{b} {}
    int b;
    int a;
    int c;
};

int main() {
    Class obj{5};
    std::cout << obj.a << " " << obj.b << " " << obj.c << std::endl;
}

​Правильный ответ - {мусор} {мусор} 5.

Список инициализации в конструкторе - вещь дельная, полезная и иногда без нее никуда. Но с ним есть один неприятный момент - все может пойти по шляпе, если не соблюдать одно правило. "Порядок инициализации полей в списке инициализации конструктора должен совпадать с порядком следования полей в описании класса". Но вот не все знают, что же будет, если это правило нарушить. Поэтому давайте разбираться.

Для начала приведу цитату из стандарта:

In a non-delegating constructor, initialization proceeds in the following order:

- First, and only for the constructor of the most derived class, virtual base classes 
are initialized in the order they appear on a depth-first left-to-right traversal of the 
directed acyclic graph of base classes, where “left-to-right” is the order of appearance 
of the base classes in the derived class base-specifier-list.
    
- Then, direct base classes are initialized in declaration order as they appear in the 
base-specifier-list(regardless of the order of the mem-initializer)
    
- Then, non-static data members are initialized in the order they were declared in the
 class definition (again regardless of the order of the mem-initializer()
    
- Finally, the compound-statement of the constructor body is executed.

Теперь разжуем эту сухую писанину в мягкую кашицу для лучшего усвоения.

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

Далее инициализируются нестатические поля класса в порядке, в котором они объявлены в определении класса, и который никак не зависит от списка инициализации конструктора.

Ну и далее выполняется само тело конструктора.

Какие из этого выводы?

Самый главный - поведение абсолютно определено стандартом. Здесь нет никакого UB! Список инициализации лишь задает способ инициализации, но никак не влияет на порядок. Порядк определяется только порядком следования полей в описании класса(сверху вниз).

То есть в нашем примере в начале будет инициализировать b, потом a и, наконец, c. И не смотря на то, что в списке инициализации c стоит первым, на самом деле его инициализация будет проходить последней. А так как все остальные поля зависят от значения c и инициализируются раньше него, то в них будет содержаться мусор.

Никто нам не может запретить писать список инициализации в том порядке, в котором мы хотим. Да и непонятно, как это сделать. С точки зрения С++, код вполне корректен и может работать. Просто от этого будут последствия, но вполне предсказуемые.

Благо, к нам на помощь приходят компиляторы, которые аккуратно подскажут нам, что мы делаем чухню возможно не то, что хотим. Скорее всего компилятор вам сам кинет ворнинг, что переменная c используется неинициализированной. Чтобы точно заставить компилятор это сделать, добавьте опцию -Wall. Подробнее про ворнинги в этом цикле статей.

Также вы можете(должны?) добавить флаг компиляции, чтобы превращать все предупреждения в ошибки. Тогда вы точно ничего важного не пропустите. Как говорится, флаг -Werror вам в руки!

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

Еще есть нюансы с default member initializer и его сочетанием со списком инициализации конструктора. Короче, много нюансов, как и во всех плюсах)
В один пост все все равно не влезет. Будем разделять и властвовать!

Devide et empera. Stay cool.

#cppcore

Линковка constexpr с другими TU

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

Для начала вспомним, что какое влияние ключевое слово constexpr оказывает на функции в плане линковки. Для функций constexpr подразумевает inline, поэтому мы уходит от первоначального вопроса к вопросу использования статических переменных в inline функциях.

Использование может быть разным. Сегодня рассмотрим использование статических констант в непосредственно в теле функции.

Приведу краткий рекап, но для более лучшего понимания процессов можете на достуге прочитать наш гайд по inline(ссылка в закрепе).

inline подразумевает внешнюю линковку. То есть другие единицы трансляции спокойно могут видеть определение сущности и взаимодействовать с ним. inline сущности могут иметь несколько определений в разных единицах трансляции. А компановщик после компиляции в итоговом бинарнике оставляет из всех лишь одно определение inline сущности.

Статические же сущности уникальны для каждой единицы компиляции и никому не позволительно иметь к ним доступ при линковке. Эдакие эндемики своей TU.

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

И тут мы приходим в первой ситуации: мы определили inline функцию в одной единице трансляции и пытаемся из другой единицы получить к ней доступ. Условно так:

//first.cpp
static const int a = 3;
constexpr int gaga() {
  return a;
}

//second.cpp
int gaga();
void boo() {
  gaga();
}

Это дело в таком виде не соберется даже без оптимизаций. Функция boo будет отсылаться на несуществующий символ gaga. Можно провести ряд манипуляций, чтобы в таком виде генерировалось определение, но на оптимизациях компилятор все равно его выкинет и сборка зафейлится.

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

А они есть.

Более подходящим и общеиспользуемым вариантом организации кода с inline сущностями является помещение их в хэдэры и подключение в те TU, где они будут использоваться. Выглядит это примерно так:

//header.hpp
static const int const_var = 3;
constexpr int gaga() {
  return const_var;
}
//first.cpp
#include "header.hpp"
void boo() {
  gaga();
}

//second.cpp
#include "header.hpp"
void kak_delaut_gucy() {
  gaga();
}

Этот чудокод теперь собирается без проблем, компилятор встроит все вызовы и будет все хорошо. Но вот что будет, если функция gaga будет чуть сложнее для того, чтобы ее встраивать? Что будет, если для first.cpp и second.cpp компилятор все-таки будет генерировать определение gaga?

А будет UB. Тут применимо вот такое правило.

If an inline function [...] with external 
linkage is defined differently in 
different translation units, 
the behavior is undefined.

Но почему же определения разные? Мы же один и тот же код с одной и той же константой просто копируем в нужные единицы трансляции.

Только вот константы на самом деле разные. В каждой единице трансляции будет своя копия const_var и каждое определение gaga будет ссылаться на разные сущности-копии const_var.

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

Конечно, компилятор скорее всего оптимизирует использование такой простой переменной и все будет работать как ожидается. Но просто сам формат организации кода и зависимостей сущностей может привести к UB. Оно вам надо? Оно вам не надо.

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

​Так что лучше не мешайте статические и инлайновые сущности вместе. Опасный коктейль получается.

Sometimes mixing certain ingredients just won't work. Stay cool.

#cpp11 #cpcore

​Фиксим неприятности

Сегодня коротко разберем, как обезопасить себя от проблем кода из предыдущего поста?

Просто надо использовать inline переменные! Но для этого понадобится С++17 и выше. Их и более менее все используют, но надо оговорку сделать.

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

Поэтому код будет выглядеть вот так:

//header.hpp
inline constexpr int const_var = 3;
constexpr int gaga() {
  return const_var;
}
//first.cpp
#include "header.hpp"
void boo() {
  gaga();
}

//second.cpp
#include "header.hpp"
void kak_delaut_gucy() {
  gaga();
}

constexpr и const имеют одинаковый линковочный смысл для переменных, поэтому замена вполне корректна. Да и просто constexpr переменная лучше смотрится с constexpr функций.

Fix your flaws. Stay cool.

#cpp17