static_cast
В предыдущих статьях мы несколько раз упоминали оператор
Исходя из своих наблюдений, наиболее востребованным оператором приведения является
Оператор
Конечно, некоторые смысловые ошибки нельзя поймать, ведь с точки зрения типа, все хорошо. Например, приведение значения к
Правила приведения для фундаментальных (встроенных) типов в C++ определены заранее, а вот для пользовательских классов можно определить свои собственные преобразования с помощью оператора приведения к типу:
Эта ручка будет дергаться при явном и неявном приведении типов в живом примере 1:
Если такое предупреждение появляется, то вероятно, что что-то вы все таки упускаете в своем коде. Но иногда такие ситуации встречаются, когда полезная нагрузка от вашего действия есть, а предупреждение не к месту. Например, в следствие какой-нибудь препроцессорной директивы. Напоминаем, что в C++17 так же есть атрибут
Так же
Разберем эту тему подробнее, когда дойдем до динамического полиморфизма
В предыдущих статьях мы несколько раз упоминали оператор
static_cast, поэтому мы решили затронуть еще и тему приведения типов. По мере развития серии, рассмотрим каждый из них, а завершим разбором C-style cast.Исходя из своих наблюдений, наиболее востребованным оператором приведения является
static_cast, т.к. в основном большинство приходится на преобразование между совместимыми друг с другом типами:int32_t value_i32 = 42;
int64_t value_i64 = static_cast<int64_t>(value_i32);
float value_f32 = 42.314;
int16_t value_i16 = static_cast<int16_t>(value_f32);
Оператор
static_cast так же проверяет корректность выполняемого приведения. Например, запрещает приведение указателя к значению:// error: invalid 'static_cast' from type 'int*' to type 'int'
static_cast<int>(&value);
Конечно, некоторые смысловые ошибки нельзя поймать, ведь с точки зрения типа, все хорошо. Например, приведение значения к
enum class может привести к непредвиденным сценариям 🤭:enum class action_e : int { RUN = 0, FIGHT = 1 };
// Should I run or fight?
action_e action = static_cast<action_e>(2);
Лучше бы их все таки дополнять еще debug-only assert или вообще условным ветвлением.Правила приведения для фундаментальных (встроенных) типов в C++ определены заранее, а вот для пользовательских классов можно определить свои собственные преобразования с помощью оператора приведения к типу:
operator Type():class specific_error_t
{
...
// Оператор приведение к типу `bool`
operator bool() const
{
return m_code < 0;
}
...
};
Эта ручка будет дергаться при явном и неявном приведении типов в живом примере 1:
specific_error_t internal_code = -1;Один из неочевидных способов применения этого оператора является приведение к типу
// Приведение `internal_code` к типу `bool`
bool has_internal_code = static_cast<bool>(internal_code);
void. Казалось бы, зачем? Но это помогает подавить предупреждение компилятора о неиспользуемой переменной / не присвоенном значении:void foo()
{
int result = read_and_do_something();
#ifdef DEBUG
// Debug build check only
assert(result == 0);
#endif
static_cast<void>(result);
}
Если такое предупреждение появляется, то вероятно, что что-то вы все таки упускаете в своем коде. Но иногда такие ситуации встречаются, когда полезная нагрузка от вашего действия есть, а предупреждение не к месту. Например, в следствие какой-нибудь препроцессорной директивы. Напоминаем, что в C++17 так же есть атрибут
[[maybe_unused]], который решает эту проблему.Так же
static_cast позволяет выполнить приведение к типу родительского класса (upcasting) и к типу наследников (downcasting) в рамках одной иерархии классов:Child *pointer = new Child();Важным моментом является тот факт, что
// Upcasting
Base *base_ptr = static_cast<Base*>(pointer);
// Downcasting
Child *child_ptr = static_cast<Child*>(base_ptr);
static_cast не может обеспечить проверку корректности совершенного преобразования к наследнику (downcasting)! Если наследник выбран неправильно и вы допустили ошибку преобразования к другому типу, то вам все равно дадут скомпилироваться: живой пример 2. У компилятора действительно не хватает информации, чтобы это проверить на этапе компиляции. Разберем эту тему подробнее, когда дойдем до динамического полиморфизма
reinterpret_cast
Исходя из имени этого оператора, он вводится для узкой специализации: "переосмыслить" значение, т.е. представить его в другом виде. Его используют для приведение несовместных типов: «указатель к объекту», «указатель к указателю». Из живого примера 1:
Где же нам такое может понадобиться? Если не брать в пример какой-нибудь зловещий хакинг чисел с плавающей запятой на уровне битов, то в основном, при работе с сырой памятью. Например, при записи и чтении данных в файл:
Наверняка вы знаете, что числа с плавающей точкой совершенно иначе представляются в системе, в отличии от целочисленных значений в двоичном виде. Это позволяет нам оперировать ну ооочень большими и маленькими десятичные значениями, выходящими за рамки возможного для целочисленных типов.
Давайте попробуем увидеть, как расставлены биты в типе
Так,
Однако, с точки зрения поставленной задачи, именно оно нам и нужно — тип
#cppcore
Исходя из имени этого оператора, он вводится для узкой специализации: "переосмыслить" значение, т.е. представить его в другом виде. Его используют для приведение несовместных типов: «указатель к объекту», «указатель к указателю». Из живого примера 1:
double *pointer_f64 = new double(42);Приводя типы таким оператором, мы никак его не преобразуем с точки зрения памяти. Но теперь, обращаясь к тем же байтам, как к другому типу, с ними можно работать иначе.
int64_t *pointer_i64 = reinterpret_cast<int64_t *>(pointer_f64);
int64_t value_i64 = reinterpret_cast<int64_t> (pointer_i64);
int32_t *pointer_i32 = reinterpret_cast<int32_t *>(value_i64);
Где же нам такое может понадобиться? Если не брать в пример какой-нибудь зловещий хакинг чисел с плавающей запятой на уровне битов, то в основном, при работе с сырой памятью. Например, при записи и чтении данных в файл:
void save(const double &hp)
{
file.write(reinterpret_cast<const uint8_t*>(&hp), sizeof(hp));
}
void load(double &hp)
{
file.read(reinterpret_cast<uint8_t*>(&hp), sizeof(hp));
}
Наверняка вы знаете, что числа с плавающей точкой совершенно иначе представляются в системе, в отличии от целочисленных значений в двоичном виде. Это позволяет нам оперировать ну ооочень большими и маленькими десятичные значениями, выходящими за рамки возможного для целочисленных типов.
Давайте попробуем увидеть, как расставлены биты в типе
double в живом примере 2. При решении этой задачи можно воспользоваться готовой стандартной структурой std::bitset(unsigned long long) для распечатки битов. Однако, есть нюанс! Тип данных double можно привести к соразмерному unsigned long long двумя разными способами, которые дают совершенно разный результат.Так,
static_cast отбрасывает дробную часть и преобразует к целочисленному значению, а reinterpret_cast просто иначе интерпретирует расставленные биты. В следствие этого из 42.0 мы получаем не 42, а какое-то другое и явно отличное от исходного число: 4631107791820423168. Очень похоже на то, как мы иногда в шутку пытаемся услышать слова родного языка в иностранных песнях.Однако, с точки зрения поставленной задачи, именно оно нам и нужно — тип
unsigned long long просто выступает в роли «грузового контейнера» для транспортировки 64 битов, которые std::bitset потом благополучно печатает в консоль.#cppcore
static local variables
В этом давнишнем посте кратко резюмировали все стороны "употребления" ключевого слова static. Сегодня поговорим про статические локальные переменные.
Это довольно интересная сущность, которая сочетает в себе поведение локального объекта функции и глобальной переменной.
От локального объекта она берет область видимости. То есть к этой переменной по имени никак нельзя обратиться вне ее функции. Можно, например, вернуть из функции ссылку на эту переменную и иметь возможность ее читать и модифицировать. Но по имени к ней можно обратиться только внутри функции. Соответственно, у static local variable нет никакого собственного типа линковки, это бессмысленно.
От глобальной переменной она берет статическое время жизни. То есть, начиная с момента своей инициализации, она продолжает существовать, пока не вызовется std::exit aka завершение программы.
Разберем немного цикл жизни такой переменной.
1) Она инициализируется при первом достижении исполнения ее объявления. Стандарт нам говорит:
То есть нам дается очень важная гарантия: локальные статические переменные инициализируются потокобезопасно. Это значит, что даже если несколько потоков одновременно зайдут в функцию и попытаются проинициализировать переменную, то победителем в этой истории будет только один поток, который и проведет инициализацию, все остальные будут ждать. Эта гарантия появляется вместе с появлением новой модели памяти и исполнения в С++11. И обычно реализуется с помощью паттерна блокировки с двойной проверкой.
Однако, если переменная числового типа или инициализируется с помощью константного выражения, то инициализация может произойти раньше(какой смысл ждать, если все понятно как делать и делать это просто).
2) При выходе из скоупа функции для статической локальной переменной не вызывается деструктор. Она продолжает жить не тужить и сохраняет свое значение до следующего вызова функции.
3) При повторном заходе в функцию объявление переменной просто игнорируется и выполняется весь код, помимо инициализации. Здесь мы можем повторно использовать переменную, изменить ее значение и вообще много чего с ней делать.
4) После завершения функции main переменная разрушается. Press F умершим.
Пример:
Функция BytesToHex переводит любое количество байт от заданного указателя в их hex представление. Раз мы знаем, что hex представление содержит только 16 символов и больше нигде эти символы не нужны, то очень удобно поместить массив этих символов в саму функцию в качестве локальной статической переменной. Так мы инкапсулируем данные и сохраним возможность 1 раз создать переменную и пользоваться именно этим инстансом во всех вызовах функции.
Один интересный момент, что kHexDigits инициализируется не при первом вызове функции. Потому что в первый раз исполнение не прошло через ее декларацию. И только начиная со второго вызова она начинает существовать и разрушается только после выхода из main().
Combine your best sides. Stay cool.
#cpp11 #multitasking #cppcore
В этом давнишнем посте кратко резюмировали все стороны "употребления" ключевого слова static. Сегодня поговорим про статические локальные переменные.
Это довольно интересная сущность, которая сочетает в себе поведение локального объекта функции и глобальной переменной.
От локального объекта она берет область видимости. То есть к этой переменной по имени никак нельзя обратиться вне ее функции. Можно, например, вернуть из функции ссылку на эту переменную и иметь возможность ее читать и модифицировать. Но по имени к ней можно обратиться только внутри функции. Соответственно, у static local variable нет никакого собственного типа линковки, это бессмысленно.
От глобальной переменной она берет статическое время жизни. То есть, начиная с момента своей инициализации, она продолжает существовать, пока не вызовется std::exit aka завершение программы.
Разберем немного цикл жизни такой переменной.
1) Она инициализируется при первом достижении исполнения ее объявления. Стандарт нам говорит:
such a variable is initialized the first
time control passes through its declaration; [...]
If control enters the declaration concurrently
while the variable is being initialized,
the concurrent execution shall wait for
completion of the initialization.
То есть нам дается очень важная гарантия: локальные статические переменные инициализируются потокобезопасно. Это значит, что даже если несколько потоков одновременно зайдут в функцию и попытаются проинициализировать переменную, то победителем в этой истории будет только один поток, который и проведет инициализацию, все остальные будут ждать. Эта гарантия появляется вместе с появлением новой модели памяти и исполнения в С++11. И обычно реализуется с помощью паттерна блокировки с двойной проверкой.
Однако, если переменная числового типа или инициализируется с помощью константного выражения, то инициализация может произойти раньше(какой смысл ждать, если все понятно как делать и делать это просто).
2) При выходе из скоупа функции для статической локальной переменной не вызывается деструктор. Она продолжает жить не тужить и сохраняет свое значение до следующего вызова функции.
3) При повторном заходе в функцию объявление переменной просто игнорируется и выполняется весь код, помимо инициализации. Здесь мы можем повторно использовать переменную, изменить ее значение и вообще много чего с ней делать.
4) После завершения функции main переменная разрушается. Press F умершим.
Пример:
std::string BytesToHex(const void* bytes, size_t size)
{
if (size) {
static const char kHexDigits[] = {'0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', 'A', 'B', 'C', 'D', 'E', 'F'};
std::string output;
output.reserve(size * 2);
auto c = static_cast<const uint8_t*>(bytes);
for (size_t i = 0; i < size; ++i) {
uint8_t value = *(c + i);
output.push_back(kHexDigits[value >> 4]);
output.push_back(kHexDigits[value & 0xf]);
}
return output;
}
else {
return "";
}
}
int main()
{
std::cout << BytesToHex("", 0) << std::endl;
std::cout << BytesToHex("123", 3) << std::endl;
std::cout << BytesToHex("abc", 3) << std::endl;
}
Функция BytesToHex переводит любое количество байт от заданного указателя в их hex представление. Раз мы знаем, что hex представление содержит только 16 символов и больше нигде эти символы не нужны, то очень удобно поместить массив этих символов в саму функцию в качестве локальной статической переменной. Так мы инкапсулируем данные и сохраним возможность 1 раз создать переменную и пользоваться именно этим инстансом во всех вызовах функции.
Один интересный момент, что kHexDigits инициализируется не при первом вызове функции. Потому что в первый раз исполнение не прошло через ее декларацию. И только начиная со второго вызова она начинает существовать и разрушается только после выхода из main().
Combine your best sides. Stay cool.
#cpp11 #multitasking #cppcore
Цикл жизни non-local static storage duration переменных
В прошлом посте поговорили про локальные статические переменные и их цикл жизни. Сегодня в общем рассмотрим рождение и смерть всех нелокальных глобальных переменных.
Здесь важна оговорка, что объекты со static storage duration не обязаны быть помечены ключевым словом static! Этот термин употребляется для описания объектов, лишь время жизни которых является статическим. То есть более менее всех глобальных объектов. Все они существуют от момента создания до момента завершения программы. Поэтому просто написав:
считайте, что вы объявили переменную со static storage duration.
Для краткости, вместо "объект со static storage duration" буду писать"глобальный объект".
Так вот. Для таких объектов существует строгий порядок инициализации, который состоит из определенных шагов и подшагов.
1️⃣ Статическая инициализация. В сущности, это установление значения, которое может быть проведено во время компиляции. Состоит из двух подшагов:
👉🏿 Первым, если возможно, идет константная инициализация. Проводится, когда инициализатор - константное выражение.
👉🏿 Во всех остальных случаях проводится Zero-инициализация.
2️⃣ Динамическая инициализация. Только после того, как проведена статическая инициализация, вступает в игру динамическая. Которая и является причиной static initialization order fiasco. Потому что дает очень мало гарантий по поводу порядка инициализации, одна из которых описана тут. Но в общем и целом, порядок инициализации глобальных объектов в разных юнитах трансляции не определен.
Обычно она происходит в рантайме, но если компилятор может, то он производит ее в compile-time при наличии определенных условий.
После инициализации переменная живет в течение всего времени существования программы до тех пор, пока она не завершится.
Если чуть подробнее и конкретнее про завершение, то при выходе из функции main происходят все стандартные процессы разрушения локальных переменных, но еще и вызов std::exit с возращаемым из мэйна значением в качестве аргумента. И вот std::exit одним из своих шагов триггерит вызов деструкторов глобальных объектов.
И заметьте, что деструкция глобальных переменных связана именно с завершением функции main() и ни с чем другим. Это может быть критично, если мы находимся в многопоточной среде.
Это суперобобщенно, поэтому дальше будем раскрывать все эти стадии.
Cегодня без картинки, но вместо этого можете посмотреть короткий веселый видосик про цикл жизни программиста
Define cycle of your life. Stay cool.
#cppcore #compiler
В прошлом посте поговорили про локальные статические переменные и их цикл жизни. Сегодня в общем рассмотрим рождение и смерть всех нелокальных глобальных переменных.
Здесь важна оговорка, что объекты со static storage duration не обязаны быть помечены ключевым словом static! Этот термин употребляется для описания объектов, лишь время жизни которых является статическим. То есть более менее всех глобальных объектов. Все они существуют от момента создания до момента завершения программы. Поэтому просто написав:
int var = 1;
считайте, что вы объявили переменную со static storage duration.
Для краткости, вместо "объект со static storage duration" буду писать"глобальный объект".
Так вот. Для таких объектов существует строгий порядок инициализации, который состоит из определенных шагов и подшагов.
1️⃣ Статическая инициализация. В сущности, это установление значения, которое может быть проведено во время компиляции. Состоит из двух подшагов:
👉🏿 Первым, если возможно, идет константная инициализация. Проводится, когда инициализатор - константное выражение.
👉🏿 Во всех остальных случаях проводится Zero-инициализация.
2️⃣ Динамическая инициализация. Только после того, как проведена статическая инициализация, вступает в игру динамическая. Которая и является причиной static initialization order fiasco. Потому что дает очень мало гарантий по поводу порядка инициализации, одна из которых описана тут. Но в общем и целом, порядок инициализации глобальных объектов в разных юнитах трансляции не определен.
Обычно она происходит в рантайме, но если компилятор может, то он производит ее в compile-time при наличии определенных условий.
После инициализации переменная живет в течение всего времени существования программы до тех пор, пока она не завершится.
Если чуть подробнее и конкретнее про завершение, то при выходе из функции main происходят все стандартные процессы разрушения локальных переменных, но еще и вызов std::exit с возращаемым из мэйна значением в качестве аргумента. И вот std::exit одним из своих шагов триггерит вызов деструкторов глобальных объектов.
И заметьте, что деструкция глобальных переменных связана именно с завершением функции main() и ни с чем другим. Это может быть критично, если мы находимся в многопоточной среде.
Это суперобобщенно, поэтому дальше будем раскрывать все эти стадии.
Cегодня без картинки, но вместо этого можете посмотреть короткий веселый видосик про цикл жизни программиста
Define cycle of your life. Stay cool.
#cppcore #compiler
Zero initialization
Решил начать в нулевой инициализации, так как она как будто бы самая простая и понятная.
Выполняется она после попытки выполнить константную инициализацию глобальных объектов и представляет из себя literally "зануление объекта".
Так как для этого вида установки значения объектам нет своего выделенного синтаксиса в языке, то вот примеры того, в каких ситуациях она может быть выполнена:
Примеров на самом деле больше, но так описано в стандарте, поэтому надо уважить дедов. И вот почему примеров больше.
Нулевая инициализация в любом случае проводится для всех глобальных переменных, если их нельзя константно проинициализировать, раньше всех остальных видов инициализации. То есть создали вы объект в глобальном скоупе, который динамически проинициализировали(в рантайме). В констукторе можно напихать все, что угодно(чего не было в примерах выше), но этот объект все равно будет проинициализирован нулями на этапе компиляции.
Также она проводится для массивов символьных типов, если инициализирующая строка слишком короткая. Остаток будет заполняться нулями.
Ну и про "зануление". У zero-initialization следующие эффекты:
👉🏿 Если T - скалярный тип, объект инициализируется результатом превидения численного литерала
👉🏿 Если T - кастомный тип, то:
1️⃣ все паддинги инициализируются битами-нулями.
2️⃣ для всех нестатических мемберов проводится zero-initialization(немного рекурсии, но все рано или поздно сводится к скалярным типам и массивам).
3️⃣для подобъектов каждого базы класса проводится zero-initialization.
👉🏿 Если Т - массив, то каждый элемент zero-инициализирутся.
👉🏿 Если Т - ссылка, то гоняем лысого(ЗАЧЕРКНУТЬ)ничего не делаем.
Обычно zero-инициализированные объекты находятся в .bss секции бинарника, которую иногда обзывают .zerofill секцией.
Как и говорил, довольно просто, но это знание будет полезно в дальшейших статьях.
Stay useful. Stay cool.
#cppcore
Решил начать в нулевой инициализации, так как она как будто бы самая простая и понятная.
Выполняется она после попытки выполнить константную инициализацию глобальных объектов и представляет из себя literally "зануление объекта".
Так как для этого вида установки значения объектам нет своего выделенного синтаксиса в языке, то вот примеры того, в каких ситуациях она может быть выполнена:
static T object;
T();
T t= {};
T{};
CharT array[n] = "short-sequence";
Примеров на самом деле больше, но так описано в стандарте, поэтому надо уважить дедов. И вот почему примеров больше.
Нулевая инициализация в любом случае проводится для всех глобальных переменных, если их нельзя константно проинициализировать, раньше всех остальных видов инициализации. То есть создали вы объект в глобальном скоупе, который динамически проинициализировали(в рантайме). В констукторе можно напихать все, что угодно(чего не было в примерах выше), но этот объект все равно будет проинициализирован нулями на этапе компиляции.
Также она проводится для массивов символьных типов, если инициализирующая строка слишком короткая. Остаток будет заполняться нулями.
Ну и про "зануление". У zero-initialization следующие эффекты:
👉🏿 Если T - скалярный тип, объект инициализируется результатом превидения численного литерала
0 к типу T.👉🏿 Если T - кастомный тип, то:
1️⃣ все паддинги инициализируются битами-нулями.
2️⃣ для всех нестатических мемберов проводится zero-initialization(немного рекурсии, но все рано или поздно сводится к скалярным типам и массивам).
3️⃣для подобъектов каждого базы класса проводится zero-initialization.
👉🏿 Если Т - массив, то каждый элемент zero-инициализирутся.
👉🏿 Если Т - ссылка, то гоняем лысого(ЗАЧЕРКНУТЬ)ничего не делаем.
Обычно zero-инициализированные объекты находятся в .bss секции бинарника, которую иногда обзывают .zerofill секцией.
Как и говорил, довольно просто, но это знание будет полезно в дальшейших статьях.
Stay useful. Stay cool.
#cppcore
Мотивация оптимизации пересекающихся областей памяти
В предыдущей статье было рассказано о правиле
Давайте «поиграем в компилятор» и попробуем понять логику оптимизации этой функции:
Итак, можем ли мы оптимизировать данный код?
С одной стороны, мы можем предположить, что раз мы задали
Давайте попробует измерить с помощью игрушечного бенчмарка, будет ли это как-то влиять? Опустим момент, почему я его запустил с опцией
С другой стороны, если
Вышеописанная ситуация может показаться неоднозначной. В большинстве случаев, скорее всего, она будет легальна, но для каких-то совершенно недопустима. В случае, если бы вы разрабатывали свою программу, то вы бы могли решить этот вопрос просто посмотрев, где и как используется такая функция.
Но вообще говоря, это касается не только вырванных из контекста функций с их аргументами, а любых указателей и ссылок на пересекающуюся память. Можно ли подставлять значения в последующих выражениях без перечитывания памяти?
Для вашего компилятора это одновременно и возможность офигенно ускорить исполнение программ, и головная боль: как понять, происходит наложение памяти (aliasing) и оптимизироваться нельзя?
Попробуем рассуждать дальше. Условно, этапе компиляции можно попробовать отследить какие адреса должны быть в указателях. Но вопрос особенно остро встаёт, когда мы компилируем какую-то функцию для динамической библиотеки. По сути, перед нами только сама функция и всё! Контекста вызова этой функции нет. У компилятора не так много информации, которую он может использовать, поэтому в качестве критерия выступает тип ссылки/указателя. Вероятно, что представление пересекающейся памяти совершенно разными типами - это все таки очень редкий случай в рамках одного приложения.
Комитет стандартизации C/С++ предпочел регламентировать правила, по которым можно не ограничивать программистов и предоставить лучшую производительность. Компромиссный вариант.
Компилятор не может применить оптимизацию, если соблюдается правило strict aliasing. Во всех остальных случаях компилятор по умолчанию считает любые указатели/ссылки непересекающимися областями памяти и будет их оптимизировать, если не удается явно детектировать его нарушение... Это можно сделать, преимущественно в рамках тела одной функции, когда есть полный контекст взаимодействия с указателем. В этом случае будут сгенерированы инструкции, аналогичные корректному коду: живой пример. Вероятно, именно поэтому с такой проблемой разработчики сталкиваются реже, чем могли бы.
Но вот можно ли рассчитывать на то, что в другой версии компилятора это будет работать точно так же? Раз не стандартизировано и это UB, значит нет. В общем случае, такой код становится непереносимым.
#compiler
В предыдущей статье было рассказано о правиле
strict aliasing. Предлагаю сегодня немного порассуждать, почему оптимизация имеет место быть?Давайте «поиграем в компилятор» и попробуем понять логику оптимизации этой функции:
auto set_default(int &ival, float &dval)
{
ival = 0;
dval = 2.0;
return std::pair(ival, dval);
}
Итак, можем ли мы оптимизировать данный код?
С одной стороны, мы можем предположить, что раз мы задали
ival и dval конкретные константы и больше никаких операций с этими ссылками не делали, то мы можем заранее вычислить объект std::pair(ival, dval) вот так:auto set_default(int &ival, float &dval)
{
ival = 0;
dval = 2.0;
// Вычислим в compile time
constexpr auto result = std::pair(0, 2.0);
return result;
}
Давайте попробует измерить с помощью игрушечного бенчмарка, будет ли это как-то влиять? Опустим момент, почему я его запустил с опцией
-O0, но мы видим прирост на ~30%. Получается, что наша ручная оптимизация имеет значение. И это лишь одна оптимизация, которая может комбинироваться с другими.С другой стороны, если
ival и dval ссылаются на пересекающиеся области памяти, то мы явно понимаем, что наша функция должна возвращать совершенно другие значения. Вот вам живой пример для наглядности.Вышеописанная ситуация может показаться неоднозначной. В большинстве случаев, скорее всего, она будет легальна, но для каких-то совершенно недопустима. В случае, если бы вы разрабатывали свою программу, то вы бы могли решить этот вопрос просто посмотрев, где и как используется такая функция.
Но вообще говоря, это касается не только вырванных из контекста функций с их аргументами, а любых указателей и ссылок на пересекающуюся память. Можно ли подставлять значения в последующих выражениях без перечитывания памяти?
Для вашего компилятора это одновременно и возможность офигенно ускорить исполнение программ, и головная боль: как понять, происходит наложение памяти (aliasing) и оптимизироваться нельзя?
Попробуем рассуждать дальше. Условно, этапе компиляции можно попробовать отследить какие адреса должны быть в указателях. Но вопрос особенно остро встаёт, когда мы компилируем какую-то функцию для динамической библиотеки. По сути, перед нами только сама функция и всё! Контекста вызова этой функции нет. У компилятора не так много информации, которую он может использовать, поэтому в качестве критерия выступает тип ссылки/указателя. Вероятно, что представление пересекающейся памяти совершенно разными типами - это все таки очень редкий случай в рамках одного приложения.
Комитет стандартизации C/С++ предпочел регламентировать правила, по которым можно не ограничивать программистов и предоставить лучшую производительность. Компромиссный вариант.
Компилятор не может применить оптимизацию, если соблюдается правило strict aliasing. Во всех остальных случаях компилятор по умолчанию считает любые указатели/ссылки непересекающимися областями памяти и будет их оптимизировать, если не удается явно детектировать его нарушение... Это можно сделать, преимущественно в рамках тела одной функции, когда есть полный контекст взаимодействия с указателем. В этом случае будут сгенерированы инструкции, аналогичные корректному коду: живой пример. Вероятно, именно поэтому с такой проблемой разработчики сталкиваются реже, чем могли бы.
Но вот можно ли рассчитывать на то, что в другой версии компилятора это будет работать точно так же? Раз не стандартизировано и это UB, значит нет. В общем случае, такой код становится непереносимым.
#compiler
Ретроспектива с подписчиками #2
Cегодня будет интересный формат взаимодействия с вами, когда вы можете написать свои ощущения по каналу: что нравится, что не нравится, что можно изменить.
Это довольно важная для нас активность, она помогает оставаться в контакте с аудиторией и делать некие adjustment'ы, чтобы вам больше заходил контент. Не буду лукавить, что весь канал ведется только для подписчиков. Не только. Мы из подготовки контента тоже многое для себя выносим. Но все-таки мы вещаем на довольно большую аудиторию и будет круто, если мы сможем найти точки соприкосновения с вами.👉🏿👈🏿
С прошлого раза пришло много народу, возможно коньюнктура поменялась. Возможно, вы новичкок в плюсах и хотите посты про базовые вещи, типа для чего нужен std::cout или что за монстр этот ваш std::unordered_map🤓. Возможно, вы хотите чуть разнообразнее контент. Например, нам нравится готовить длинные серии постов на одну тему. Глубокое погружение в материал дает большее понимание темы и нюансов, о которых можно вам рассказать. И нам кажется, что лучше постоянно быть в контексте одной темы, чтобы лучше ее понять и держать в голове все ее грани. И мы скорее всего не перестанем готовить посты в таком духе. Но мы можем периодически разбавлять серии постами на другие темы, если вас не будут смущать большое количество отсылок на предыдущие посты, когда серия будет возвращаться после перерыва.
Если вы хотите, чтобы мы рассказали какую-то тему - тоже пишите.
В общем, пишите все, что думаете. Ну не прям все, нам не обязательно знать, как бы вы сейчас с кайфом бабушкины блинчики с молоком хомячнули🥛🥞. Но по теме пишите все) Мы все читаем и, при достаточной поддержке, ваше предложение будет принято к сведению.
Голосовать за важность чьей либо идеи предлагаем просто пальцами: 👍или👎. Так мы поймем, что действительно важно для нас. Погнали! 👨💻
Build communication with people. Stay cool.
Cегодня будет интересный формат взаимодействия с вами, когда вы можете написать свои ощущения по каналу: что нравится, что не нравится, что можно изменить.
Это довольно важная для нас активность, она помогает оставаться в контакте с аудиторией и делать некие adjustment'ы, чтобы вам больше заходил контент. Не буду лукавить, что весь канал ведется только для подписчиков. Не только. Мы из подготовки контента тоже многое для себя выносим. Но все-таки мы вещаем на довольно большую аудиторию и будет круто, если мы сможем найти точки соприкосновения с вами.👉🏿👈🏿
С прошлого раза пришло много народу, возможно коньюнктура поменялась. Возможно, вы новичкок в плюсах и хотите посты про базовые вещи, типа для чего нужен std::cout или что за монстр этот ваш std::unordered_map🤓. Возможно, вы хотите чуть разнообразнее контент. Например, нам нравится готовить длинные серии постов на одну тему. Глубокое погружение в материал дает большее понимание темы и нюансов, о которых можно вам рассказать. И нам кажется, что лучше постоянно быть в контексте одной темы, чтобы лучше ее понять и держать в голове все ее грани. И мы скорее всего не перестанем готовить посты в таком духе. Но мы можем периодически разбавлять серии постами на другие темы, если вас не будут смущать большое количество отсылок на предыдущие посты, когда серия будет возвращаться после перерыва.
Если вы хотите, чтобы мы рассказали какую-то тему - тоже пишите.
В общем, пишите все, что думаете. Ну не прям все, нам не обязательно знать, как бы вы сейчас с кайфом бабушкины блинчики с молоком хомячнули🥛🥞. Но по теме пишите все) Мы все читаем и, при достаточной поддержке, ваше предложение будет принято к сведению.
Голосовать за важность чьей либо идеи предлагаем просто пальцами: 👍или👎. Так мы поймем, что действительно важно для нас. Погнали! 👨💻
Build communication with people. Stay cool.
bit_cast
Начиная с C++20 появилась шаблонная функция
В конкретном примере переменные
Аналогичного результата можно добиться и с помощью
В отличие от альтернативных способов, шаблонная функция
Продемонстрирую проблему на примере с
Бывает и так, что изначально некоторые типы были реализованы тривиальными, но затем (в ходе доработок) потеряли такое свойство. Встроенные проверки
Нельзя назвать
Оставляйте реакции, считаете ли вы этот пост полезным для других! А мы, как и всегда, будем рады прочитать ваши комментарии и ответить вопросы 😉
#cppcore #cpp20
Начиная с C++20 появилась шаблонная функция
std::bit_cast в заголовочном файле <bit>. Она предоставляет возможность создавать побитовые копии объектов с другим типом:#include <bit>
double src = 42.0;
uint64_t dst = std::bit_cast<uint64_t>(src);
В конкретном примере переменные
dst и src имеют одинаковый размер 8 байт, поэтому их содержимое может быть интерпретировано по-разному, в зависимости от типа представления: беззнаковое целое или число с плавающей запятой.Аналогичного результата можно добиться и с помощью
union или reinterpret_cast. Однако, это нельзя было сделать в compile time! Функция std::bit_cast поддерживает constexpr выражения. Бонусом мы получаем достаточно лаконичное приведение и не нарушаем strict aliasing.В отличие от альтернативных способов, шаблонная функция
std::bit_cast дополнительно проверяет, что исходный и целевой типы имеют одинаковый размер и могут быть тривиально скопированы. Последнее означает, что память объекта может быть просто скопирована без дополнительных действий и это будет рабочей копией. Если это не так, то такие операции могут нарушать жизненный цикл нового объекта.Продемонстрирую проблему на примере с
std::string. Объекты данного типа, в общем случае, хранят строку где-то в другом месте, а сами выступают в роли умной оболочки (RAII). Клонирование такого объекта «в лоб» создает потенциально опасную ситуацию: два объекта будут ссылаться на один и тот же уникальный ресурс и пытаться управлять им. Например, они оба попытаются освободить ресурс. У первого объекта это получится, а у второго приведет к ошибке double free: живой пример. Отсюда и вытекает ограничение, что нельзя создавать побитовых клонов нетривиально копируемых объектов. Им необходимо обязательно вызвать конструктор копирования, который выделит собственный ресурс. Бывает и так, что изначально некоторые типы были реализованы тривиальными, но затем (в ходе доработок) потеряли такое свойство. Встроенные проверки
std::bit_cast тут же сообщат о некорректности работы с таким типом.Нельзя назвать
std::bit_cast оператором приведения, т.к. эта штука все таки не включена в семантику языка (в отличие от static_cast, reinterpret_cast и т.д.) и вынесена в пространство имен библиотеки STL. Однако её стоит упомянуть в текущем цикле статей.Оставляйте реакции, считаете ли вы этот пост полезным для других! А мы, как и всегда, будем рады прочитать ваши комментарии и ответить вопросы 😉
#cppcore #cpp20
const_cast
Оператор приведения
Это достаточно специфичное действие при разработке: удалить cv-спецификатор. Естественно, в большинстве случаев это ведет к UB, т.к. компиляторы ориентируются на cv-спецификатор при генерации инструкций. Будь то предоставление данных только на чтение, привязка к устройству ввода-вывода, запрет на кеширование значений — такие изменения сопряжены с рисками получить неопределенное поведение.
Приведу простой живой пример. Хоть ссылке
В случае с read-only, заставить явно перечитать память переменной можно, например, с помощью
Оправданное использование такого приведения встречается достаточно редко. Это может быть использовано для сохранения совместимости между устаревшими версиями API, когда в действительности данные не изменяются, но этого требует интерфейс.
Я не помню, когда последний раз использовал этот оператор. Единственный раз, когда я его встретил, он был нужен, чтобы наоборот установить const квалификатор. Это, пожалуй, единственное безопасное действие, которое можно им совершить.
#cppcore
Оператор приведения
const_cast используется для добавления или удаления спецификаторов const и volatile:cpp
const int value = 42;
// or
volatile int value = 42;
int &reference = const_cast<int&>(value);
Это достаточно специфичное действие при разработке: удалить cv-спецификатор. Естественно, в большинстве случаев это ведет к UB, т.к. компиляторы ориентируются на cv-спецификатор при генерации инструкций. Будь то предоставление данных только на чтение, привязка к устройству ввода-вывода, запрет на кеширование значений — такие изменения сопряжены с рисками получить неопределенное поведение.
Приведу простой живой пример. Хоть ссылке
reference и было присвоено значение 24 на соседней строчке, далее значение 42 подставляется напрямую. Казалось бы, это можно отследить на этапе компиляции, но нет! Даже никаких оптимизаций не указано, а компилятор всё равно проигнорирует это действие и подставит константу.В случае с read-only, заставить явно перечитать память переменной можно, например, с помощью
std::launder (since C++ 17). Но можно ли гарантировать, что везде дальше по коду оно будет перечитываться? Нет, и еще раз нет, особенно при долгой поддержке решения, особенно когда хранители знаний уходят из компании.Оправданное использование такого приведения встречается достаточно редко. Это может быть использовано для сохранения совместимости между устаревшими версиями API, когда в действительности данные не изменяются, но этого требует интерфейс.
Я не помню, когда последний раз использовал этот оператор. Единственный раз, когда я его встретил, он был нужен, чтобы наоборот установить const квалификатор. Это, пожалуй, единственное безопасное действие, которое можно им совершить.
#cppcore
Константная инициализация. Ч1
Это первый шаг, который пытается выполнить компилятор, когда пробует инициализировать переменную. Для него требуется, чтобы инициализатор был константным выражением. То есть его можно было бы вычислить во время компиляции. И не путать с обычным const! Позже покажу почему.
Также гарантируется, что эта инициализация происходит до любой другой инициализации статиков. На практике же компиляторы вообще сразу в бинарь помещают предвычисленное значение объекта и во время выполнения с ним уже ничего не нужно делать. Пример:
С переменной
Точнее немного не так. Она будет проиниализирована последней, но аж 2 раза! Первый раз - zero-инициализацией на этапе компиляции, второй раз - динамической в рантайме.
Чтобы не пустословить по чем зря, покажу вырезки из ассембера, которые подкрепляют мои слова. Вот чего нашел:
Дальше мы переходим к data секции, в которой подряд инициализируются
И в последнюю очередь, уже в рантайме, динамически ини
Это рантаймовая рутина, которая запускается перед вызовом main() и инициализирует
Тут можно довольно простую аналогию провести. Константная инициализаци выполняется для тех объектов, которые можно пометить constexpr, и, не учитывая весь остальной код, компиляция после этого успешно завершится.
Define order of your life. Stay cool.
#cppcore #compiler
Это первый шаг, который пытается выполнить компилятор, когда пробует инициализировать переменную. Для него требуется, чтобы инициализатор был константным выражением. То есть его можно было бы вычислить во время компиляции. И не путать с обычным const! Позже покажу почему.
Также гарантируется, что эта инициализация происходит до любой другой инициализации статиков. На практике же компиляторы вообще сразу в бинарь помещают предвычисленное значение объекта и во время выполнения с ним уже ничего не нужно делать. Пример:
constexpr double constexpr_var{1.0};
double const_intialized_var1{constexpr_var};
const double const_var{const_intialized_var1};
double const_intialized_var2{3.0};
С переменной
constexpr_var все хорошо, константа присваивается константному выражению и инициализируется эта переменная первой. Далее устанавливается значение для const_intialized_var1. Несмотря на то, что эта переменная не константа, ее инициализатор - константное выражение, а этого достаточно для выполнения константной инициализации. Интересно, что дальше устанавливается значение переменной const_intialized_var2, а не const_var. Хоть const_var и константа, ее инициализатор не является константным выражением! Все потому, что у переменной const_intialized_var1 нет пометки const(constexpr), а значит, хоть она и проинициализирована константой, сама таковой не является. И const_var будет инициализироваться последней уже в рантайме.Точнее немного не так. Она будет проиниализирована последней, но аж 2 раза! Первый раз - zero-инициализацией на этапе компиляции, второй раз - динамической в рантайме.
Чтобы не пустословить по чем зря, покажу вырезки из ассембера, которые подкрепляют мои слова. Вот чего нашел:
.section __DATA,__data
.globl _const_intialized_var1 ## @const_intialized_var1
.p2align 3, 0x0
_const_intialized_var1:
.quad 0x3ff0000000000000 ## double 1
.globl _const_intialized_var2 ## @const_intialized_var2
.p2align 3, 0x0
_const_intialized_var2:
.quad 0x4008000000000000 ## double 3
.section __TEXT,__const
.p2align 3, 0x0 ## @_ZL13constexpr_var
__ZL13constexpr_var:
.quad 0x3ff0000000000000 ## double 1
.zerofill __DATA,__bss,__ZL9const_var,8,3 ## @_ZL9const_var
.section __DATA,__mod_init_func,mod_init_funcs
.p2align 3, 0x0
.quad __GLOBAL__sub_I_main.cpp
constexpr_var инициализируется в текстовой секции. Не смотрите, что эта секция расположена в середине, стандарт гарантирует, что ее инициализация произойдет первой(в ином случае const_intialized_var1 досталась бы фига).Дальше мы переходим к data секции, в которой подряд инициализируются
const_intialized_var1 и _const_intialized_var2. И после всего этого в секции .zerofill у нас заполняется нулями const_var.И в последнюю очередь, уже в рантайме, динамически ини
циализируется const_var.
.section __TEXT,__StaticInit,regular,pure_instructions
.p2align 4, 0x90 ## -- Begin function __cxx_global_var_init
___cxx_global_var_init: ## @__cxx_global_var_init
.cfi_startproc
## %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
movsd _const_intialized_var1(%rip), %xmm0 ## xmm0 = mem[0],zero
movsd %xmm0, __ZL9const_var(%rip)
popq %rbp
retq
.cfi_endproc
Это рантаймовая рутина, которая запускается перед вызовом main() и инициализирует
const_var.Тут можно довольно простую аналогию провести. Константная инициализаци выполняется для тех объектов, которые можно пометить constexpr, и, не учитывая весь остальной код, компиляция после этого успешно завершится.
Define order of your life. Stay cool.
#cppcore #compiler
Константная инициализация. Ч2
То, каким образом в деталях работает константная иницализация, довольно сложно понять, просто читая стандарт и другие официальные источники. И вот почему.
Вот такой пример они дают:
И говорится, что
Но видимо при проведении константной инициализации компилятор только один раз проходит сверху вниз программы. По факту,
Еще более интересные вещи происходят в ассемблер
Это внутреннее представление этих глобальных переменных. static_class_var прям глобальная, ее могу видеть и другие единицы трансляции. Поэтому она с пометкой .globl. const_var же статическая переменная, а значит ее видно видно только из текущей единицы трансляции.
Проблема в том, что
Дело в том, что здесь замешано одно интересное право компилятора. Ему в определенных случаях разрешено устанавливать начальные значения переменным в compile-time, если он уверен, что их значения не изменится на момент начала старта программы.
Этот пример и пример из прошлого поста кстати показывают, что инициализация глобальных переменных идет не совсем сверху вниз. Для каждого этап инициализации это более менее верно, но под каждый этап попадают разные подмножества переменных. Поэтому могут возникать сайд-эффекты, подобные тем, что были в этом посте.
Accept side affects. Stay cool.
#cpcore #compiler
То, каким образом в деталях работает константная иницализация, довольно сложно понять, просто читая стандарт и другие официальные источники. И вот почему.
Вот такой пример они дают:
struct S
{
static const int static_class_var;
};
static const int const_var = 10 * S::static_class_var;
const int S::static_class_var = 5;
int main()
{
std::cout << &const_var << std::endl; // ODR-use for explicit generation of symbol
std::array<int, S::static_class_var> a1; // OK
// std::array<int, const_var> a2; // ERROR
}
И говорится, что
static_class_var на момент создания const_var не имеет инициализатора. А так как компилятор в первую очередь выполняет константную инициализацию, поэтому он не может сейчас установить значение для const_var. Поэтому в начале инициализируется static_class_var. И вот уже дальше - const_var.Но видимо при проведении константной инициализации компилятор только один раз проходит сверху вниз программы. По факту,
static_class_var - константа, инициализированная константным выражением. И по всем канонам должна сама стать константным выражением. Так и получается, ведь мы можем создать std::array из нее. Но вот из const_var - не можем. Хотя эта переменная тоже проинициализирована константным выражением. Но так, как ее инициализация происходит после константной инициализации, то этот факт не дает ей шанса стать нормальным constant expression.Еще более интересные вещи происходят в ассемблер
е.
.section __TEXT,__const
.globl __ZN1S16static_class_varE ## @_ZN1S16static_class_varE
.p2align 2, 0x0
__ZN1S16static_class_varE:
.long 5 ## 0x5
.p2align 2, 0x0 ## @_ZL9const_var
__ZL9const_var:
.long 50 ## 0x32
Это внутреннее представление этих глобальных переменных. static_class_var прям глобальная, ее могу видеть и другие единицы трансляции. Поэтому она с пометкой .globl. const_var же статическая переменная, а значит ее видно видно только из текущей единицы трансляции.
Проблема в том, что
const_var выглядит такой же compile-time константой, как и static_class_var. Хотя по идее тут должна быть какая-нибудь zero-инициализация + динамическая в рантайме. Но array мы не можем создать с const_var🗿.Дело в том, что здесь замешано одно интересное право компилятора. Ему в определенных случаях разрешено устанавливать начальные значения переменным в compile-time, если он уверен, что их значения не изменится на момент начала старта программы.
Этот пример и пример из прошлого поста кстати показывают, что инициализация глобальных переменных идет не совсем сверху вниз. Для каждого этап инициализации это более менее верно, но под каждый этап попадают разные подмножества переменных. Поэтому могут возникать сайд-эффекты, подобные тем, что были в этом посте.
Accept side affects. Stay cool.
#cpcore #compiler
Идея динамического полиморфизма
«Полиморфизм (от др. греч. много видов) — возможность существования чего-либо в различных формах»
Идея динамического полиморфизма заключается в том, чтобы иметь возможность обобщенно описать поведение семейства классов. Каждый класс семейства имеет общий набор действий, но может выполнять их по своему — учитывать особенности конкретного представителя семейства.
Приведу простой пример: все подписчики канала относятся к семейству Homo sapiens. Общей чертой этого вида является возможность говорить, но все говорят по-разному! Даже если мы произносим один и тот же текст, будет отличается интонация, голос, диалект, темп... Я делаю акцент на разных способах совершения одного и того же действия. Допустим, мы хотим запрограммировать это разнообразие действий. В языке есть конкретный способ, как это можно сделать легко и понятно. Для упрощенного взаимодействия с такими семействами в язык введен динамический полиморфизм.
В рамках данной темы слово семейство подходит лучше всего. Мы можем сделать иерархию классов, связанных по смыслу. Родительский класс будет обобщать поведение для всех своих наследников. Так получается семейство, где каждый класс имеет некоторое родство с другими классами: общий набор виртуальных методов. Они могут наследоваться от предков и могут быть изменены у потомков. Такой набор представляет из себя общий интерфейс для семейства классов.
Ключевое слово
Реализация виртуального метода может быть изменена у наследников класса:
Каждый представитель семейства — это отдельный класс. Это позволяет им определять разное количество полей с разными типами. В связи с этим, их не получится традиционно положить последовательно друг за другом в какой-то контейнер, например, массив или вектор. Как минимум у них будут разные типы, что недопустимо в языке. Нельзя гарантировать, что размер объектов разных классов будет одинаковый, значит и ходить по памяти с фиксированным шагом нельзя. В этом случае, как правило, объект полиморфного класса создают на куче, а в контейнер сохраняют указатель на эту область памяти. Тип указателя выбирается таким образом, чтобы он был общим предком для всех объектов, которые будут сохраняться в конкретный контейнер. Пример:
Продолжение в комментариях 👇
#cppcore
«Полиморфизм (от др. греч. много видов) — возможность существования чего-либо в различных формах»
Идея динамического полиморфизма заключается в том, чтобы иметь возможность обобщенно описать поведение семейства классов. Каждый класс семейства имеет общий набор действий, но может выполнять их по своему — учитывать особенности конкретного представителя семейства.
Приведу простой пример: все подписчики канала относятся к семейству Homo sapiens. Общей чертой этого вида является возможность говорить, но все говорят по-разному! Даже если мы произносим один и тот же текст, будет отличается интонация, голос, диалект, темп... Я делаю акцент на разных способах совершения одного и того же действия. Допустим, мы хотим запрограммировать это разнообразие действий. В языке есть конкретный способ, как это можно сделать легко и понятно. Для упрощенного взаимодействия с такими семействами в язык введен динамический полиморфизм.
В рамках данной темы слово семейство подходит лучше всего. Мы можем сделать иерархию классов, связанных по смыслу. Родительский класс будет обобщать поведение для всех своих наследников. Так получается семейство, где каждый класс имеет некоторое родство с другими классами: общий набор виртуальных методов. Они могут наследоваться от предков и могут быть изменены у потомков. Такой набор представляет из себя общий интерфейс для семейства классов.
Ключевое слово
virtual используется для обозначения виртуальных методов:struct ParentКласс, который содержит хотя бы один виртуальный метод, в том числе наследует его от родителя, является полиморфным классом.
{
// Виртуальные методы `whoami` и `can_work`
// могут быть переопределены у наследников
// этого класса
virtual void whoami() {
std::cout << "I'm a human. ";
}
virtual void can_work() {
std::cout << "I can work hard 5 days a week. ";
}
// Невиртуальный метод
void say_hello() {
std::cout << "Hello! ";
}
// Обязательно объявляем
// виртуальный деструктор
virtual ~Parent() {;}
};
Реализация виртуального метода может быть изменена у наследников класса:
struct Child : public ParentВиртуальный метод наследника будет перегружен только тогда, когда сигнатура метода полностью совпадет с сигнатурой у родителя. То есть имя, типы и набор параметров у методов совпадает. Возвращаемый тип тоже должен совпадать, но есть одно исключение: подробнее.
{
// Методы `whoami` наследован
// без переопределения
// Метод `can_work` переопределен
void can_work() override {
std::cout << "I can't work because I'm too young. ";
}
// Метод `say_hello` наследован от родителя
// Метод, недоступный из общего интерфейса
void child_only() {
std::cout << "I can play games hard 7 days a week! ";
}
};
Каждый представитель семейства — это отдельный класс. Это позволяет им определять разное количество полей с разными типами. В связи с этим, их не получится традиционно положить последовательно друг за другом в какой-то контейнер, например, массив или вектор. Как минимум у них будут разные типы, что недопустимо в языке. Нельзя гарантировать, что размер объектов разных классов будет одинаковый, значит и ходить по памяти с фиксированным шагом нельзя. В этом случае, как правило, объект полиморфного класса создают на куче, а в контейнер сохраняют указатель на эту область памяти. Тип указателя выбирается таким образом, чтобы он был общим предком для всех объектов, которые будут сохраняться в конкретный контейнер. Пример:
Parent *humans[2] { nullptr };
// Parent - общий предок
humans[0] = new Parent();
humans[1] = new Child();
Указатель data имеет тип Parent. Почему выбран именно этот тип? В данном случае, мы сможем вызывать общие методы не только с классом Parent, но и со всеми его наследниками. Не обязательно выбирать самый базовый класс, т.к. наследник может предоставлять более широкий интерфейс, содержать больше общих методов для выбранного подсемейства.Продолжение в комментариях 👇
#cppcore
Виртуальный деструктор
В предыдущей статье в комментарии к примеру было написано, что деструктор полиморфного класса обязательно должен быть виртуальным. Зачем же? Погнали разбираться!
Объект каждого класса обладает своим жизненным циклом: начало, счастливая жизнь и конец. С началом ассоциирован - конструктор, а с концом - деструктор, о котором и пойдет речь дальше. Он вызывается автоматически, когда объект удаляется вручную или автоматически. Это даёт возможность корректно завершить работу, которую выполнял объект. Например, освободить выделенную в конструкторе память, закрыть сокет. Это позволяет поддерживать систему в валидном состоянии на протяжении всей работы программы. Это счастливый конец!
Условно, если вы поработали в мастерской, значит, уходя из неё, надо всё за собой убрать и разложить по полочкам. Иначе следующий мастер там просто не найдет нужный инструмент, запнется о мусор и еще что-нибудь испортит. Повторим это с десяток раз и можно сжигать мастерскую 😃. Кажется, что сжигать мастерскую — это перебор 🤭, но именно так и поступит система: прибьет её из-за исчерпания памяти (Out Of Memory). Это грустный конец...
Вернёмся к динамическому полиморфизму. Давайте свяжем два наблюдения:
1) Зачастую, наследники полиморфных классов могут владеть ресурсом, который обязаны вернуть системе (например, память на куче).
2) Зачастую, взаимодействие происходит через указатель на родительский класс.
Из П.1 следует, что у наследника должен быть вызван деструктор, в котором происходит возврат ресурса системе.
Из П.2 следует, что динамический тип объекта может отличаться от типа указателя.
Из этого следует, что корректное удаление объекта подразумевает вызов деструктора класса наследника. И вот как его вызвать, если тип указателя - родительский? Например тут:
Пишу тут
Есть простое встроенное решение 😊 Отмечайте деструктор родительского класса виртуальным! Пример:
Вызов виртуального деструктора приведёт к вызову цепочки деструкторов у всех наследников от родительского до динамического типа:
Если в иерархии классов деструктор не был отмечен виртуальным, то будет вызван только деструктор класса, который является типом указателя. Деструктор наследника не будет вызван вообще, следовательно, ресурс будет упущен. Добавлю живой пример, в котором количество выделяемых ресурсов не совпадает с освобождаемым. Как-нибудь напишем, как это дело проверять по-нормальному 😉
Пока деструктор останется невиртуальным, у компилятора просто нет указания, что надо заботиться о чем-то. Ну вдруг у вас умышленно очень хитрое поведение у программы?
Есть еще один тонкий момент. Кажется, что если полиморфное семейство не выделяет никаких ресурсов, то и проблем не будет. Но это пока! Пройдет время, код эволюционирует, появятся такие ресурсы и вот тогда что-то может да потечь. Короче, это чеховское ружьё 😉
Помочь избежать этих проблем поможет, как всегда, предупреждение:
#cppcore
В предыдущей статье в комментарии к примеру было написано, что деструктор полиморфного класса обязательно должен быть виртуальным. Зачем же? Погнали разбираться!
Объект каждого класса обладает своим жизненным циклом: начало, счастливая жизнь и конец. С началом ассоциирован - конструктор, а с концом - деструктор, о котором и пойдет речь дальше. Он вызывается автоматически, когда объект удаляется вручную или автоматически. Это даёт возможность корректно завершить работу, которую выполнял объект. Например, освободить выделенную в конструкторе память, закрыть сокет. Это позволяет поддерживать систему в валидном состоянии на протяжении всей работы программы. Это счастливый конец!
Условно, если вы поработали в мастерской, значит, уходя из неё, надо всё за собой убрать и разложить по полочкам. Иначе следующий мастер там просто не найдет нужный инструмент, запнется о мусор и еще что-нибудь испортит. Повторим это с десяток раз и можно сжигать мастерскую 😃. Кажется, что сжигать мастерскую — это перебор 🤭, но именно так и поступит система: прибьет её из-за исчерпания памяти (Out Of Memory). Это грустный конец...
Вернёмся к динамическому полиморфизму. Давайте свяжем два наблюдения:
1) Зачастую, наследники полиморфных классов могут владеть ресурсом, который обязаны вернуть системе (например, память на куче).
2) Зачастую, взаимодействие происходит через указатель на родительский класс.
Из П.1 следует, что у наследника должен быть вызван деструктор, в котором происходит возврат ресурса системе.
Из П.2 следует, что динамический тип объекта может отличаться от типа указателя.
Из этого следует, что корректное удаление объекта подразумевает вызов деструктора класса наследника. И вот как его вызвать, если тип указателя - родительский? Например тут:
Parent *data = new Child();
...
delete data;
Пишу тут
new и delete в ознакомительных целях. Используйте умные указатели: unique_ptr, shared_ptr.Есть простое встроенное решение 😊 Отмечайте деструктор родительского класса виртуальным! Пример:
struct Parent
{
...
virtual ~Parent() {...}
...
};
Вызов виртуального деструктора приведёт к вызову цепочки деструкторов у всех наследников от родительского до динамического типа:
... -> ~Child_2() -> ~Child_1() -> ~Parent();
Если в иерархии классов деструктор не был отмечен виртуальным, то будет вызван только деструктор класса, который является типом указателя. Деструктор наследника не будет вызван вообще, следовательно, ресурс будет упущен. Добавлю живой пример, в котором количество выделяемых ресурсов не совпадает с освобождаемым. Как-нибудь напишем, как это дело проверять по-нормальному 😉
Пока деструктор останется невиртуальным, у компилятора просто нет указания, что надо заботиться о чем-то. Ну вдруг у вас умышленно очень хитрое поведение у программы?
Есть еще один тонкий момент. Кажется, что если полиморфное семейство не выделяет никаких ресурсов, то и проблем не будет. Но это пока! Пройдет время, код эволюционирует, появятся такие ресурсы и вот тогда что-то может да потечь. Короче, это чеховское ружьё 😉
Помочь избежать этих проблем поможет, как всегда, предупреждение:
-Wdelete-non-virtual-dtor
#cppcore
Вызов переопределенных методов в конструкторе / деструкторе
Едва познакомившись с поведением динамического полиморфизма можно придумать достаточно много разных способов его применения. Здорово, если это действительно так! 😃
Вот, например, теперь мы можем в базовом классе выполнить переопределенный виртуальный метод наследованного класса:
Далее следует интересный вопрос, что будет если вызвать метод
вывелось из base_t. Почему?
Такое ограничение при вызове переопределенных методов связано с жизненным циклом объекта и порядком выполнения конструкторов и деструкторов:
При вызове переопределенного метода из конструктора или деструктора, будет вызвана реализация из этого же класса. Такое поведение явно определено в целях безопасности: иначе ваши переопределенные виртуальные методы могут использовать неинициализированную память наследников.
Сделал живой пример 2, в котором постарался наглядно продемонстрировать, что при прямом вызове перегруженной реализации мы бы прочитали невалидные данные. Если что, так делать нельзя 😉 Тут важно просто понять мотивацию ограничений.
Желаю всем, чтобы вы всегда получали ожидаемый результат исполнения ваших программ!
#cppcore
Едва познакомившись с поведением динамического полиморфизма можно придумать достаточно много разных способов его применения. Здорово, если это действительно так! 😃
Вот, например, теперь мы можем в базовом классе выполнить переопределенный виртуальный метод наследованного класса:
struct base_tБазовый класс знает, что метод
{
virtual const char* name() const
{
return "I'm base!";
}
void call_me()
{
std::cout << name() << std::endl;
}
virtual ~base_t() = default;
};
struct derived_t : base_t
{
const char* name() const override
{
return "I'm derived!";
}
};
void main()
{
derived_t object;
// Выводит "I'm derived!"
object.call_me();
}
name() - виртуальный, поэтому используя встроенный механизм виртуальных таблиц, будет вызвано его переопределение.Далее следует интересный вопрос, что будет если вызвать метод
call_me из конструктора или деструктора?virtual ~base_t()Виртуальный деструктор будет вызван в момент выхода тела
{
call_me();
}
main. Вероятно, что вы ожидаете увидеть имя из derived_t, ведь метод был переопределен. Давайте проверим в живом примере 1. Спойлер: Такое ограничение при вызове переопределенных методов связано с жизненным циклом объекта и порядком выполнения конструкторов и деструкторов:
Constructors:Следовательно, и состояние данных в классах тоже зависит от порядка инициализации / разрушения классов.
base() -> derived_1() -> derived_2() -> ...;
Destructors:
... -> ~derived_2() -> ~derived_1() -> ~base();
При вызове переопределенного метода из конструктора или деструктора, будет вызвана реализация из этого же класса. Такое поведение явно определено в целях безопасности: иначе ваши переопределенные виртуальные методы могут использовать неинициализированную память наследников.
Сделал живой пример 2, в котором постарался наглядно продемонстрировать, что при прямом вызове перегруженной реализации мы бы прочитали невалидные данные. Если что, так делать нельзя 😉 Тут важно просто понять мотивацию ограничений.
Желаю всем, чтобы вы всегда получали ожидаемый результат исполнения ваших программ!
#cppcore
Идентификатор
В статье про динамический полиморфизм мы затронули вопрос переопределения виртуальных методов. Напомню: если сигнатура виртуального метода наследника будет отличаться от сигнатуры метода родителя, то может нарушиться работа динамического полиморфизма. Если вы хотели переопределить метод, но ошиблись с сигнатурой, то будет создан новый метод. К нему нельзя получить доступ через общий интерфейс!
Может быть вы это специально задумали, может быть вы ошиблись - компилятор не знает, что именно произошло. С его точки зрения и то, и другое - возможное корректное поведение программы, что зависит только от замысла разработчика.
Вот чтобы разделять эти два состояния, переопределяемые виртуальные методы в наследниках нужно отмечать идентификатором
Так мы не только явно выражаем наше намерение для других разработчиков, но и просим компилятор проверить нас. Если по каким-то причинам нарушается правило переопределения родительского виртуального метода, то это приведёт к ошибке компиляции. Мы рекомендуем это делать в строго обязательном порядке!
В противном случае, у компилятора просто нет никаких других критериев, по которым мы можем однозначно утверждать переопределяем мы метод или нет. В живом примере продемонстрировал, что вызов ошибочно переопределенного метода не привел к вызову другой реализации.
Кажется, что проблема надуманная, но практически в любом рабочем проекте это будет запутывать. Этого стараются избегать любой ценой, и про это не упустят возможность спросить на собеседовании :) Тем не менее, иногда такое можно встретить. Например, при просмотре кода 20-летней давности. Идентификатор
Напоминать о необходимости
#cppcore
overrideВ статье про динамический полиморфизм мы затронули вопрос переопределения виртуальных методов. Напомню: если сигнатура виртуального метода наследника будет отличаться от сигнатуры метода родителя, то может нарушиться работа динамического полиморфизма. Если вы хотели переопределить метод, но ошиблись с сигнатурой, то будет создан новый метод. К нему нельзя получить доступ через общий интерфейс!
Может быть вы это специально задумали, может быть вы ошиблись - компилятор не знает, что именно произошло. С его точки зрения и то, и другое - возможное корректное поведение программы, что зависит только от замысла разработчика.
Вот чтобы разделять эти два состояния, переопределяемые виртуальные методы в наследниках нужно отмечать идентификатором
override: struct Child : public Parent
{
// Переопределяем виртуальный метод
// Parent::say_name
virtual void say_name() override
};
Так мы не только явно выражаем наше намерение для других разработчиков, но и просим компилятор проверить нас. Если по каким-то причинам нарушается правило переопределения родительского виртуального метода, то это приведёт к ошибке компиляции. Мы рекомендуем это делать в строго обязательном порядке!
В противном случае, у компилятора просто нет никаких других критериев, по которым мы можем однозначно утверждать переопределяем мы метод или нет. В живом примере продемонстрировал, что вызов ошибочно переопределенного метода не привел к вызову другой реализации.
Кажется, что проблема надуманная, но практически в любом рабочем проекте это будет запутывать. Этого стараются избегать любой ценой, и про это не упустят возможность спросить на собеседовании :) Тем не менее, иногда такое можно встретить. Например, при просмотре кода 20-летней давности. Идентификатор
override появился в C++11, а до этого писали без него. И вот тут придется потратить время, чтобы распутать клубок переопределений. Особенно остро этот вопрос встаёт, когда в наследниках так же не указывается ключевое слово virtual, что допускается стандартом. В шутку сделал вам игру лабиринт, в которой надо найти неправильно переопределенный метод.Напоминать о необходимости
override можно с помощью предупреждения:-Wsuggest-override
#cppcore
dynamic_cast
Изучая тему динамического полиморфизма нельзя не упомянуть про оператор приведения
Бывает, что в рамках работы с полиморфными классами нам необходимо выполнить приведение от указателя с одним типом к другому из этого же полиморфного семейства. Зачастую мы не можем гарантировать, что динамический тип объекта совпадает с ожидаемым. Приведение оператором static_cast сопряжено с рисками получить UB. Как же нам безопасно его выполнить?
Отличительной особенностью
Как мы видим, компилятор позволяет собрать программу, но, в случае попытки приведения к ложному потомку,
Давайте сразу договоримся о цене таких преимуществ. Как вы догадываетесь, за эдакую роскошь приходится платить тактами процессора. Это подтверждают результаты бенчмарка. Это, действительно, в несколько десятков раз медленнее, но безопаснее! Ни о каком сравнении эффективности не может быть речи, если наша программа работает неправильно.
Когда же мы можем допустить ошибку? Давайте подумаем, какие вообще могут быть сценарии приведения:
1) От наследника к предку (up cast)
2) От предка к наследнику (down cast)
3) Между ветками подсемейств полиморфных классов (cross cast, side cast)
Кейс №1 достаточно тривиален. Мы знаем иерархию наследования, текущий тип объекта и нам надо лишь вычислить смещение до полей предка. Это можно сделать даже на этапе компиляции. Тут можно применить
Кейс №2 уже сложнее тем, что динамический тип объекта неизвестен на этапе компиляции. Его можно узнать только лишь в процессе выполнения программы, прочитав виртуальный указатель. Это как раз та ситуация, когда мы должны использовать
Конечно, приведение можно попытаться выполнить с помощью оператора
Кейс №3 декомпозируется на кейсы 1 + 2: выполняем приведение к общему предку, а затем выполняем от него приведение к требуемому наследнику. Следовательно, нам так же следует использовать
Резюмируем. Оператор
#cppcore
Изучая тему динамического полиморфизма нельзя не упомянуть про оператор приведения
dynamic_cast, который создан специально для полиморфных классов.Бывает, что в рамках работы с полиморфными классами нам необходимо выполнить приведение от указателя с одним типом к другому из этого же полиморфного семейства. Зачастую мы не можем гарантировать, что динамический тип объекта совпадает с ожидаемым. Приведение оператором static_cast сопряжено с рисками получить UB. Как же нам безопасно его выполнить?
Отличительной особенностью
dynamic_cast является проверка корректности приведения во время исполнения программы. Из живого примера 1:Device *base = new Laptop();
// Try Laptop* -> Smartphone*
// Result: `derived` is `nullptr`
auto *derived = dynamic_cast<Smartphone*>(base);
...
// Try Laptop& -> Smartphone&
// Result: throw exception std::bad_cast
auto &derived = dynamic_cast<Smartphone&>(*base);
Как мы видим, компилятор позволяет собрать программу, но, в случае попытки приведения к ложному потомку,
dynamic_cast возвращает либо нулевой указатель, либо бросает исключение std::bad_cast для ссылок.Давайте сразу договоримся о цене таких преимуществ. Как вы догадываетесь, за эдакую роскошь приходится платить тактами процессора. Это подтверждают результаты бенчмарка. Это, действительно, в несколько десятков раз медленнее, но безопаснее! Ни о каком сравнении эффективности не может быть речи, если наша программа работает неправильно.
Когда же мы можем допустить ошибку? Давайте подумаем, какие вообще могут быть сценарии приведения:
1) От наследника к предку (up cast)
2) От предка к наследнику (down cast)
3) Между ветками подсемейств полиморфных классов (cross cast, side cast)
Кейс №1 достаточно тривиален. Мы знаем иерархию наследования, текущий тип объекта и нам надо лишь вычислить смещение до полей предка. Это можно сделать даже на этапе компиляции. Тут можно применить
dynamic_cast, но достаточно и static_cast. Более того, если вы примените dynamic_cast, то все равно компилятор сгенерирует инструкции, аналогичные static_cast: живой пример 2.Кейс №2 уже сложнее тем, что динамический тип объекта неизвестен на этапе компиляции. Его можно узнать только лишь в процессе выполнения программы, прочитав виртуальный указатель. Это как раз та ситуация, когда мы должны использовать
dynamic_cast, чтобы быть готовым перехватить исключение или нулевой указатель. Так же, если в иерархии классов вы используете виртуальное наследование, то static_cast неприменим, т.к. смещение неизвестно для этого кейса.Конечно, приведение можно попытаться выполнить с помощью оператора
static_cast, чтобы было побыстрее! Но чем же это грозит? Можем выстрелить себе в ногу и начать работать с полученным объектом, как с объектом другого класса. Сравним разные операторы и продемонстрируем ошибку на живом примере 3. В общем случае, мы прочитаем что-то невнятное, а если изменим данные, то ещё и испортим память, что однозначно негативно скажется на всей программе. Попытка приведения оператором static_cast к ложному потомку правомерна с точки зрения типа. Ну правда, это тип из одной иерархии, и это будет работать, если случайно динамический тип объекта включает нужного потомка. Но при работе с семейством классов, как правило, вариантов потомков больше одного. Вот будет ли это поддерживаемым кодом? Можно ли безопасно вносить изменения в иерархию классов в будущем?Кейс №3 декомпозируется на кейсы 1 + 2: выполняем приведение к общему предку, а затем выполняем от него приведение к требуемому наследнику. Следовательно, нам так же следует использовать
dynamic_cast. Вспоминаем так же об особенностях представления памяти. Прикрепляю разбор на живом примере 4. Резюмируем. Оператор
dynamic_cast имеет преимущество с точки зрения безопасности и удобства, но он работает медленнее. Тут возникает вопрос, а за что вы переплачиваете? Если вам приходится использовать dynamic_cast, то это повод подумать, насколько хорошо продумана архитектура вашего решения. Не факт, что это плохая архитектура, но это повод её пересмотреть.#cppcore
Динамическая инициализация
После статической инициализации в компайлтайме идет динамическая инициализация в рантайме. Хотелось бы сказать, что хоть здесь простой и понятный порядок, но нет. Это глобальные переменные и С++, поэтому будет немного больно.
Динамическая инициализация разделяется на 3 подгруппы:
1️⃣ Неупорядоченная динамическая инициализация. Она применяется только для статических полей шаблонных классов и шаблонных переменных, которые не специализированы явно(явно специализированные шаблоны - обычные классы). И вот порядок установки значений этих сущностей вообще неопределен. Куда понравится компилятору, туда и вставит.
2️⃣ Частично упорядоченная инициализация. Применяется для всех нешаблонных инлайн переменных. Есть 2 переменные: inline переменная А и В, которая не подходит под критерии применения первой подгруппы. Если А определена во всех единицах трансляции раньше В, то и ее инициализация происходит раньше. Здесь есть однана*бка особенность, которую мы увидим в примере.
3️⃣ Упорядоченная инициализация. Вот это то, что мы упоминали тут. Все переменные со static storage duration, которые не подходят под предыдущие подгруппы, инициализируются в порядке появления их определения в единице трансляции. Между разными единицами трансляции порядок инициализации не установлен.
Давайте на "простой" пример посмотрим:
Возможный вывод:
Здесь как раз все три типа проявляются.
Далее мы имеем уже упорядоченные вещи.
Это понятно. Но погодите:
Вот тут-то и кроется подвох: вы наверное подумали, что из факта "если А определено раньше В, то А инициализируется раньше" автоматически вытекает, что в обратном случае А инициализируется позже. Тут вас и подловили: не вытекает. Поэтому она и называется частично упорядоченной инициализацией. В обратном случае порядок неопределен.
Теперь все понятно:
Ну и статики
И теперь представьте свое лицо, когда вы сделали эти переменные зависимыми друг от друга, предполагая, что статики(со static storage duration) в одной единице трансляции инициализируются в порядке появления определения. Как минимум 🗿, а как максимум🤡.
Последние несколько постов по статикам так и наровят крикнуть: "Не используйте глобальные переменные!" Ну или хотя бы старайтесь не делать их зависимыми друг от друга. Потому что с порядком полный беспорядок, а с перекрестными зависимостями остается только надеяться, что заговор бабки-поветухи на продуктивную работу поможет не словить багов.
Decouple your program. Stay cool.
#cppcore #cpp17
После статической инициализации в компайлтайме идет динамическая инициализация в рантайме. Хотелось бы сказать, что хоть здесь простой и понятный порядок, но нет. Это глобальные переменные и С++, поэтому будет немного больно.
Динамическая инициализация разделяется на 3 подгруппы:
1️⃣ Неупорядоченная динамическая инициализация. Она применяется только для статических полей шаблонных классов и шаблонных переменных, которые не специализированы явно(явно специализированные шаблоны - обычные классы). И вот порядок установки значений этих сущностей вообще неопределен. Куда понравится компилятору, туда и вставит.
2️⃣ Частично упорядоченная инициализация. Применяется для всех нешаблонных инлайн переменных. Есть 2 переменные: inline переменная А и В, которая не подходит под критерии применения первой подгруппы. Если А определена во всех единицах трансляции раньше В, то и ее инициализация происходит раньше. Здесь есть одна
3️⃣ Упорядоченная инициализация. Вот это то, что мы упоминали тут. Все переменные со static storage duration, которые не подходят под предыдущие подгруппы, инициализируются в порядке появления их определения в единице трансляции. Между разными единицами трансляции порядок инициализации не установлен.
Давайте на "простой" пример посмотрим:
struct ShowOrderHelper {
ShowOrderHelper(int num) : data{num} {
std::cout << "Object initialized with data " << num << std::endl;
}
int data;
};
static ShowOrderHelper static_var1{3};
static ShowOrderHelper static_var2{4};
struct ClassWithInlineStaticVar {
static inline ShowOrderHelper inline_member{1};
};
inline ShowOrderHelper inline_var{2};
template <class T>
struct TemplateClassWithStaticVar {
static ShowOrderHelper static_member;
};
template <class T>
ShowOrderHelper TemplateClassWithStaticVar<T>::static_member{27};
Возможный вывод:
Object initialized with data 1
Object initialized with data 2
Object initialized with data 27
Object initialized with data 3
Object initialized with data 4
Здесь как раз все три типа проявляются.
static_member - статическое поле неспециализированного явно шаблона, поэтому установка ее значения в рандомном месте происходит.Далее мы имеем уже упорядоченные вещи.
inline_member определен раньше, чем inline_var, поэтому она и инициализируется раньше.Это понятно. Но погодите:
inline_member и inline_var определены позже статиков static_var1 и static_var2. Какого хера они инициализирутся раньше? Это же противоречит правилам частично упорядоченной динамической инициализации!Вот тут-то и кроется подвох: вы наверное подумали, что из факта "если А определено раньше В, то А инициализируется раньше" автоматически вытекает, что в обратном случае А инициализируется позже. Тут вас и подловили: не вытекает. Поэтому она и называется частично упорядоченной инициализацией. В обратном случае порядок неопределен.
Теперь все понятно:
inline_member инициализируется строго раньше inline_var, потому что определение стоит раньше. Но, как группа inline'ов, они расположены после static_var1 и static_var2 и в этом случае для них значение устанавливается в неизвестном порядке. В данном случае перед всеми инициализациями.Ну и статики
static_var1 и static_var2 инициализируются в ожидаемом порядке из-за применения упорядоченной инициализации.И теперь представьте свое лицо, когда вы сделали эти переменные зависимыми друг от друга, предполагая, что статики(со static storage duration) в одной единице трансляции инициализируются в порядке появления определения. Как минимум 🗿, а как максимум🤡.
Последние несколько постов по статикам так и наровят крикнуть: "Не используйте глобальные переменные!" Ну или хотя бы старайтесь не делать их зависимыми друг от друга. Потому что с порядком полный беспорядок, а с перекрестными зависимостями остается только надеяться, что заговор бабки-поветухи на продуктивную работу поможет не словить багов.
Decouple your program. Stay cool.
#cppcore #cpp17
Всем привет!
У нас кстати есть отдельный чат, в котором вы можете общаться, не привязываясь к постам
Там сейчас оживленное обсуждение идет, поэтому можете присоединяться и общаться на любые темы!
Вот ссылочка
Продублируем ее потом в закрепный пост
Всем хорошего вечера!
У нас кстати есть отдельный чат, в котором вы можете общаться, не привязываясь к постам
Там сейчас оживленное обсуждение идет, поэтому можете присоединяться и общаться на любые темы!
Вот ссылочка
Продублируем ее потом в закрепный пост
Всем хорошего вечера!
Инициализация статических полей класса. Ч4
Продолжение нелегендарной истории static class members initialization. Предыдущие части тут, тут и тут.
Я немного наврал, когда сказал, что статические переменные и мемберы инициализируются до входа в main(). Как Эдгар отметил в своем комменте, на самом деле тут вот что:
Стандарт дает на откуп реализациям вопрос о том, в какой конкретно момент времени происходит динамическая инициализация глобальных объектов. Единственное ограничение, что инициализация должна произойти до любого неинициализирующего odr-use действия над неинлайн переменными и функциями, определенными в той же единице трансляции, где переменная собирается инициализироваться(немного духоты). То есть до любого действия по считыванию, записи, взятию адреса и созданию ссылки от переменной или функции.
Довольно сложно воспроизвести пример, когда инициализация происходит после main(), потому что мы на это напрямую не может повлиять. Поэтому может быть вот такой потенциальный пример. Он не про статические поля класса конкретно, но зато более наглядный.
В мейне мы говорим, что где-то определен массив интов и внутри главной функции мы печатаем его содержимое.
Проблема в том, что не понятно, произойдет ли в source.cpp инициализация array до вызова main() или после. Если после, то мы вполне можем накнуться на неинициализированную память, что UB.
Подливает масло в огонь вот такое утверждение:
То есть если никакие переменные и функции не используются в юните, где переменная должна инициализироваться, ее значение вообще может быть не установлено.
Так и происходит в source.cpp. Что с бо'льшей вероятностью приведет эту программу к фрилансерскому(нерабочему) состоянию. Однако популярные компиляторы стараются сгладить углы в этом моменте и даже в таком виде у вас в 99.9 случаев из 100 будет все в порядке. Что не отменяет потенциальную угрозу, но тем не менее.
Такие проблемы скорее свойственны программам, использующим шареные библиотеки, потому что они сами по себе в рантайме подгружаются и непонятно когда это происходит. Да и стандарт никак не упоминает эти библиотеки, поэтому здесь большой простор для фантазии и поведения реализации.
Avoid dangerous situations with no gain. Stay cool.
#cppcore
Продолжение нелегендарной истории static class members initialization. Предыдущие части тут, тут и тут.
Я немного наврал, когда сказал, что статические переменные и мемберы инициализируются до входа в main(). Как Эдгар отметил в своем комменте, на самом деле тут вот что:
It is implementation-defined whether
the dynamic initialization of
a non-block non-inline variable with
static storage duration is sequenced
before the first statement of main or
is deferred. If it is deferred, it
strongly happens before any
non-initialization odr-use of any
non-inline function or non-inline
variable defined in the same
translation unit as the variable to be
initialized. It is implementation-defined
in which threads and at which points in
the program such deferred dynamic
initialization occurs.
Стандарт дает на откуп реализациям вопрос о том, в какой конкретно момент времени происходит динамическая инициализация глобальных объектов. Единственное ограничение, что инициализация должна произойти до любого неинициализирующего odr-use действия над неинлайн переменными и функциями, определенными в той же единице трансляции, где переменная собирается инициализироваться(немного духоты). То есть до любого действия по считыванию, записи, взятию адреса и созданию ссылки от переменной или функции.
Довольно сложно воспроизвести пример, когда инициализация происходит после main(), потому что мы на это напрямую не может повлиять. Поэтому может быть вот такой потенциальный пример. Он не про статические поля класса конкретно, но зато более наглядный.
// header.hpp
struct Class {
Class() : array{1, 2, 3, -1} {}
int array[4];
};
//source.cpp
#include "header.hpp"
Class var;
// main.cpp
#include <cstdio>
#include "header.hpp"
extern Class var;
int main(void)
{
for (int i = 0; var.array[i] != -1; i++) {
printf("%d\n", i);
}
}
В мейне мы говорим, что где-то определен массив интов и внутри главной функции мы печатаем его содержимое.
Проблема в том, что не понятно, произойдет ли в source.cpp инициализация array до вызова main() или после. Если после, то мы вполне можем накнуться на неинициализированную память, что UB.
Подливает масло в огонь вот такое утверждение:
If no variable or function is odr-used
from a given translation unit, the
non-local variables defined in that
translation unit may never be initialized
То есть если никакие переменные и функции не используются в юните, где переменная должна инициализироваться, ее значение вообще может быть не установлено.
Так и происходит в source.cpp. Что с бо'льшей вероятностью приведет эту программу к фрилансерскому(нерабочему) состоянию. Однако популярные компиляторы стараются сгладить углы в этом моменте и даже в таком виде у вас в 99.9 случаев из 100 будет все в порядке. Что не отменяет потенциальную угрозу, но тем не менее.
Такие проблемы скорее свойственны программам, использующим шареные библиотеки, потому что они сами по себе в рантайме подгружаются и непонятно когда это происходит. Да и стандарт никак не упоминает эти библиотеки, поэтому здесь большой простор для фантазии и поведения реализации.
Avoid dangerous situations with no gain. Stay cool.
#cppcore
