Еще одно отличие С от С++
Это вот прям такое, мажорное отличие. Скажете его на собесе - все охренеют, вам руку пожмут через вебку и возьмут вас на работу сразу же(но это не точно).
В языке С нет проблемы Static initialization order fiasco!
Как же так? В С тоже есть статики и тоже есть разные единицы трансляции. Почему так?
Таким образом, в С статическая переменная со скалярным типом может быть инициализирована только константным выражением. Это не constexpr, а просто выражение, которое компилятор в состоянии вычислить во время компиляции. Если тип переменной представляет собой массив со скалярным типом элемента, то каждый инициализатор должен быть константным выражением и так далее. Поскольку такие выражения не могут ни вызывать побочных эффектов, ни зависеть от побочных эффектов, вызванных любыми другими вычислениями, изменение порядка вычисление константных выражений не влияет на результат. А значит и никакого фиаско нет!
Единственные неконстантные выражения, которые могут быть вычислены перед main, - это те, которые вызываются из среды выполнения C. Вот почему объекты FILE, на которые указывают stdin, stdout и stderr, уже доступны для использования сразу же после начала main.
Стандартный C не позволяет пользователям регистрировать свой собственный код запуска перед основным, хотя GCC предоставляет расширение под названием constructor (возможна массонская связь с конструкторами из C++), которое вы можете использовать для воссоздания SIOF в C. Но это, как говорится, НЕСТАНДАРТ и у каждого свой путь в могилу.
Целью Страуструпа было сделать пользовательские типы пригодными для использования везде, где есть встроенные типы. Это означало, что C++ должен был разрешать глобальным переменным быть кастомными типами, что означает, что их конструкторы будут вызываться во время запуска программы. Поскольку в начале C++ не было функций constexpr, такие вызовы конструкторов никогда не могли быть постоянными выражениями. И так, родилось чудовище, погубившее много наших ребят - Static initialization order fiasco.
В процессе стандартизации C++ вопрос о порядке выполнения статической инициализации был спорной темой. Я думаю, что вы согласитесь с тем, что идеальная ситуация - это когда каждая статическая переменная была инициализирована до ее использования. К сожалению, для этого требуется технология компоновки, которой в те дни не существовало (и, вероятно, до сих пор не существует?). Инициализация статической переменной может включать вызовы функций, и эти функции могут быть определены в другой TU, что означает, что вам нужно будет выполнить анализ всей программы, чтобы успешно отсортировать статические переменные в порядке зависимостей. Стоит отметить, что даже если бы C++ мог быть разработан таким образом, он все равно не полностью предотвратил бы проблемы с порядком инициализации. Представьте, если бы у вас была какая-то библиотека, где предварительным условием функции использования было то, что функция init() была вызвана в какой-то момент в прошлом и повлияла на нужную для инициализацию переменную. Компилятор не может увидеть такие зависимости, которые есть только у программиста в голове. По коду этого совсем не видно. Поэтому, думаю, что даже полноценный анализ кода не помог бы решить проблему.
В конечном счете, ограниченные гарантии порядка инициализации, которые мы получили в C++98, были лучшими, которые мы могли получить в данных обстоятельствах. С помощью народного "а вот сделали бы по-человечески", возможно, многие из нас высказали пару ласковых о том, что тот стандарт не был полным без функций constexpr и что статические переменные должны иметь только константную инициализацию. Но такого рода размышления надо оставить это нытикам и нюням. А настоящие программисты прогают на том, что есть. В тех условиях, в которых возможно.
Don't complain to your life. Work on it and stay cool.
#cppcore #goodoldc
Это вот прям такое, мажорное отличие. Скажете его на собесе - все охренеют, вам руку пожмут через вебку и возьмут вас на работу сразу же(но это не точно).
В языке С нет проблемы Static initialization order fiasco!
Как же так? В С тоже есть статики и тоже есть разные единицы трансляции. Почему так?
All the expressions in an initializer
for an object that has static storage
duration or in an initializer list for an
object that has aggregate or union type
shall be constant expressions.
Таким образом, в С статическая переменная со скалярным типом может быть инициализирована только константным выражением. Это не constexpr, а просто выражение, которое компилятор в состоянии вычислить во время компиляции. Если тип переменной представляет собой массив со скалярным типом элемента, то каждый инициализатор должен быть константным выражением и так далее. Поскольку такие выражения не могут ни вызывать побочных эффектов, ни зависеть от побочных эффектов, вызванных любыми другими вычислениями, изменение порядка вычисление константных выражений не влияет на результат. А значит и никакого фиаско нет!
Единственные неконстантные выражения, которые могут быть вычислены перед main, - это те, которые вызываются из среды выполнения C. Вот почему объекты FILE, на которые указывают stdin, stdout и stderr, уже доступны для использования сразу же после начала main.
Стандартный C не позволяет пользователям регистрировать свой собственный код запуска перед основным, хотя GCC предоставляет расширение под названием constructor (возможна массонская связь с конструкторами из C++), которое вы можете использовать для воссоздания SIOF в C. Но это, как говорится, НЕСТАНДАРТ и у каждого свой путь в могилу.
Целью Страуструпа было сделать пользовательские типы пригодными для использования везде, где есть встроенные типы. Это означало, что C++ должен был разрешать глобальным переменным быть кастомными типами, что означает, что их конструкторы будут вызываться во время запуска программы. Поскольку в начале C++ не было функций constexpr, такие вызовы конструкторов никогда не могли быть постоянными выражениями. И так, родилось чудовище, погубившее много наших ребят - Static initialization order fiasco.
В процессе стандартизации C++ вопрос о порядке выполнения статической инициализации был спорной темой. Я думаю, что вы согласитесь с тем, что идеальная ситуация - это когда каждая статическая переменная была инициализирована до ее использования. К сожалению, для этого требуется технология компоновки, которой в те дни не существовало (и, вероятно, до сих пор не существует?). Инициализация статической переменной может включать вызовы функций, и эти функции могут быть определены в другой TU, что означает, что вам нужно будет выполнить анализ всей программы, чтобы успешно отсортировать статические переменные в порядке зависимостей. Стоит отметить, что даже если бы C++ мог быть разработан таким образом, он все равно не полностью предотвратил бы проблемы с порядком инициализации. Представьте, если бы у вас была какая-то библиотека, где предварительным условием функции использования было то, что функция init() была вызвана в какой-то момент в прошлом и повлияла на нужную для инициализацию переменную. Компилятор не может увидеть такие зависимости, которые есть только у программиста в голове. По коду этого совсем не видно. Поэтому, думаю, что даже полноценный анализ кода не помог бы решить проблему.
В конечном счете, ограниченные гарантии порядка инициализации, которые мы получили в C++98, были лучшими, которые мы могли получить в данных обстоятельствах. С помощью народного "а вот сделали бы по-человечески", возможно, многие из нас высказали пару ласковых о том, что тот стандарт не был полным без функций constexpr и что статические переменные должны иметь только константную инициализацию. Но такого рода размышления надо оставить это нытикам и нюням. А настоящие программисты прогают на том, что есть. В тех условиях, в которых возможно.
Don't complain to your life. Work on it and stay cool.
#cppcore #goodoldc
Решение static initialization order fiasco
Раз есть проблема - должно быть и решение. Сегодня поговорим о паре-тройке вариантов. Пост вдохновлен этим комментом нашего подписчика Антона.
Очевидно, что в комментах немного поразгоняли эту тему. Поэтому вот небольшое саммари, плюс немного от себя.
1️⃣ Самое очевидное - дропнуть дурнопахнущие статики. Ну или стараться по-максимуму уменьшать их количество. Человечество давно осознало, что глобальные переменные - зло, а со злом нужно бороться и побеждать его. Используйте ООП, группируйте данные вместе. И не ленитесь передавать объекты в функции. И это поможет вам избавиться о большинства глобальных переменных. Способ, я бы сказал, идеальный. Но наш мир таковым не является и в реальном коде будут продолжать жить статики и надо уметь с ними правильно обходиться.
2️⃣ Делайте свои глобальные объекты constexpr. Глобальные изменяемые объекты - зло. Но вот умные константы, для которых можно проводить вычисления на этапе компиляции - тема богоугодная. Константны в коде так или иначе нужны, а в современных стандартах много уделяется внимания вычислениям на этапе компиляции и не зря. Вряд ли вам на этапе инициализации программы нужно делать что-то суперсложное, зависящее от внешнего мира. Зачастую, много чего можно вычислить в compile-time и не заботиться об опасностях динамической инициализации. К тому же их инициализация безопасна и предсказуема.
3️⃣ Иметь один хэдэр со всеми глобальными переменными и определить их все в одной единице трансляции. В пределах единицы трансляции порядок полностью определен, поэтому никаких проблем не будет. Однако есть один момент, что это решение будет сильно связывать друг с другом несвязанный по смыслу код. Держать все переменные в одном месте может показаться удобным на первый взгляд. Это еще сильнее развязывает руки разработчикам в плане увеличения количества связей между переменными. И в будущем распутывать эти связи будет еще сложнее. Single responsibility ушел в закат...
Да и банально разрабатывать сложнее. Удобно, когда код разбит на модули и каждый модуль максимально изолирован от остальных, чтобы не провоцировать мерж конфликты. А в этот суперфайл будут лезть буквально все и будут постоянные пересечения в изменениях разных разработчиков. Плюс можно так замержиться, что можно сломать логику работы глобальных переменных и все сильно пойдет по одному месту, потому что тесты хрен напишешь на них, а отлавливать баги в глобальных переменных - очень сложно.
Способ хоть и рабочий и много где используется, но далеко не идеальный.
4️⃣ Construct on first use idiom. Помните, как мы говорили про то, что статические локальные переменные функций инициализируются при первом вызове функции? Так вот эту особенность можно использовать, чтобы никогда не использовать объект в неинициализированном виде. Если у вас есть переменная А, инициализация которой зависит от переменной В, то есть вероятность, что В еще не инициализирована. Тогда можно переменную В обернуть в глобальную функцию-геттер, в которой эта переменная будет хранится в виде статическом локальной переменной и ее значение будет возвращаться наружу. Таким образом любое использование переменной будет проходить через вызов этой функции и нам гарантируется, что переменная создастся в момент первого вызова функции. Техника заслуживает отдельный пост, который выйдет чуть позже.
Solve your problems. Stay cool.
#cppcore
Раз есть проблема - должно быть и решение. Сегодня поговорим о паре-тройке вариантов. Пост вдохновлен этим комментом нашего подписчика Антона.
Очевидно, что в комментах немного поразгоняли эту тему. Поэтому вот небольшое саммари, плюс немного от себя.
1️⃣ Самое очевидное - дропнуть дурнопахнущие статики. Ну или стараться по-максимуму уменьшать их количество. Человечество давно осознало, что глобальные переменные - зло, а со злом нужно бороться и побеждать его. Используйте ООП, группируйте данные вместе. И не ленитесь передавать объекты в функции. И это поможет вам избавиться о большинства глобальных переменных. Способ, я бы сказал, идеальный. Но наш мир таковым не является и в реальном коде будут продолжать жить статики и надо уметь с ними правильно обходиться.
2️⃣ Делайте свои глобальные объекты constexpr. Глобальные изменяемые объекты - зло. Но вот умные константы, для которых можно проводить вычисления на этапе компиляции - тема богоугодная. Константны в коде так или иначе нужны, а в современных стандартах много уделяется внимания вычислениям на этапе компиляции и не зря. Вряд ли вам на этапе инициализации программы нужно делать что-то суперсложное, зависящее от внешнего мира. Зачастую, много чего можно вычислить в compile-time и не заботиться об опасностях динамической инициализации. К тому же их инициализация безопасна и предсказуема.
3️⃣ Иметь один хэдэр со всеми глобальными переменными и определить их все в одной единице трансляции. В пределах единицы трансляции порядок полностью определен, поэтому никаких проблем не будет. Однако есть один момент, что это решение будет сильно связывать друг с другом несвязанный по смыслу код. Держать все переменные в одном месте может показаться удобным на первый взгляд. Это еще сильнее развязывает руки разработчикам в плане увеличения количества связей между переменными. И в будущем распутывать эти связи будет еще сложнее. Single responsibility ушел в закат...
Да и банально разрабатывать сложнее. Удобно, когда код разбит на модули и каждый модуль максимально изолирован от остальных, чтобы не провоцировать мерж конфликты. А в этот суперфайл будут лезть буквально все и будут постоянные пересечения в изменениях разных разработчиков. Плюс можно так замержиться, что можно сломать логику работы глобальных переменных и все сильно пойдет по одному месту, потому что тесты хрен напишешь на них, а отлавливать баги в глобальных переменных - очень сложно.
Способ хоть и рабочий и много где используется, но далеко не идеальный.
4️⃣ Construct on first use idiom. Помните, как мы говорили про то, что статические локальные переменные функций инициализируются при первом вызове функции? Так вот эту особенность можно использовать, чтобы никогда не использовать объект в неинициализированном виде. Если у вас есть переменная А, инициализация которой зависит от переменной В, то есть вероятность, что В еще не инициализирована. Тогда можно переменную В обернуть в глобальную функцию-геттер, в которой эта переменная будет хранится в виде статическом локальной переменной и ее значение будет возвращаться наружу. Таким образом любое использование переменной будет проходить через вызов этой функции и нам гарантируется, что переменная создастся в момент первого вызова функции. Техника заслуживает отдельный пост, который выйдет чуть позже.
Solve your problems. Stay cool.
#cppcore
Empty base optimization
В этом посте мы рассказали, о том, сколько весит объект пустого класса. Настоятельно рекомендую вернуться к этому посту, чтобы быть в контексте.
Теперь возникает вопрос: что будет, если мы отнаследуемся от пустого класса? Каким образом будет учитываться этот один байт в наследнике и где он будет расположен?
Вообще говоря, ненулевой размер объекта пустого класса нужен просто для нормальной его адресации. Никакой полезной нагрузки он не несет и нужен, чтобы "просто работало". Однако, когда мы наследуется от такого класса, и, например, размещаем в наследнике какие-то поля, то наследник уже не нуждается в фейковом байте, чтобы нормально работать. У него это и так получится прекрасно. Получается, что этот 1 байт будет, как жабры на теле млекопитающего: предкам были нужны, а сейчас вообще ни к селу, ни к пгт.
Поэтому есть такое понятие, как empty base class optimization. Если мы наследуемся от пустого класса, то размер класса наследника будет ровно таким же, как как будто бы он ни от чего не наследовался.
Пример:
Вывод консоли:
Вроде бы очень логичная штука и даже почти интуитивная штука, но немногие знают в ее в профиль и анфас, поэтому сегодня исправили этот момент)
Optimize your life. Stay cool.
#cppcore #optimization
В этом посте мы рассказали, о том, сколько весит объект пустого класса. Настоятельно рекомендую вернуться к этому посту, чтобы быть в контексте.
Теперь возникает вопрос: что будет, если мы отнаследуемся от пустого класса? Каким образом будет учитываться этот один байт в наследнике и где он будет расположен?
Вообще говоря, ненулевой размер объекта пустого класса нужен просто для нормальной его адресации. Никакой полезной нагрузки он не несет и нужен, чтобы "просто работало". Однако, когда мы наследуется от такого класса, и, например, размещаем в наследнике какие-то поля, то наследник уже не нуждается в фейковом байте, чтобы нормально работать. У него это и так получится прекрасно. Получается, что этот 1 байт будет, как жабры на теле млекопитающего: предкам были нужны, а сейчас вообще ни к селу, ни к пгт.
Поэтому есть такое понятие, как empty base class optimization. Если мы наследуемся от пустого класса, то размер класса наследника будет ровно таким же, как как будто бы он ни от чего не наследовался.
Пример:
struct EmptyClass {
void MethodMeantJustNotToLeaveClassDeadInside() {}
};
struct Derived : public EmptyClass {
int a;
char b;
double c;
};
struct SizeReference {
int a;
char b;
double c;
};
int main() {
EmptyClass a;
Derived b;
SizeReference c;
std::cout << "EmptyClass object size: " << sizeof(a) << std::endl;
std::cout << "Derived object size: " << sizeof(b) << std::endl;
std::cout << "SizeReference object size: " << sizeof(c) << std::endl;
}
Вывод консоли:
EmptyClass object size: 1
Derived object size: 16
SizeReference object size: 16
Вроде бы очень логичная штука и даже почти интуитивная штука, но немногие знают в ее в профиль и анфас, поэтому сегодня исправили этот момент)
Optimize your life. Stay cool.
#cppcore #optimization
Идентификатор
#новичкам
Продолжаем серию постов! Ранее мы уже упоминали идентификатор со специальным значением
Запретить переопределение метода в наследниках можно с помощью идентификатора
Ограничивать переопределения виртуальных методов может показаться неочевидным действием. Казалось бы, вот к чему это? Этот вопрос стоит рассматривать с технической и смысловой точки зрения. Начнем с последнего.
Код, который вы пишите, может быть достаточно глубоко осмыслен и выразителен. В частности, в семействе вашего класса можно выделить подсемейство со специфичным и фиксированным поведением.
В качестве примера, давайте рассмотрим семейство датчиков умного дома. Пусть была разработана открытая библиотека, которая предоставляет некоторый набор интерфейсов для разных типов датчиков. Например, для подсемейства пожарных датчиков. Производители устройств могут наследовать специальный интерфейс и реализовать прошивку для своего девайса. Как у них работает этот сенсор — никто не знает, но главное, что в случае срабатывания такого датчика происходит важное, в рамках этого подсемейства, действие - вызывается бригада пожарных. Это достаточно важный смысл, который может быть заложен в наследника класса и ограничен в переопределении для производителя:
Думаю, обосновывать важность этого ограничения не стоит. Если производитель по каким-то причинам захочет вызвать бригаду стриптизёров вместо пожарных, то до жаркой вечеринки дело не дойдёт!
Конечно, можно написать комментарии к коду, в надежде, что их прочитают... Но вот практика показывает, что их периодически игнорируют. Если какое-то ограничение не срабатывает во время компиляции и доходит до ревью, то разработка затягивается. Пока это увидят, пока переделают... Да и вообще, это сработает, только если у проверяющего достаточно компетенций / внимательности.
Кстати, хоть
С помощью идентификатора
#cppcore #cpp11
final
для виртуальных методов#новичкам
Продолжаем серию постов! Ранее мы уже упоминали идентификатор со специальным значением
final
в рамках наследования классов — запрещали создавать наследников того или иного класса. Это поведение распространялось на весь класс целиком, в том числе и на все его методы. Это может быть слишком строгим ограничением в какой-то ветке нашего подсемейства. Например, мы хотим его продолжать развивать, но точечно зафиксировать поведение одного конкретного переопределенного метода.Запретить переопределение метода в наследниках можно с помощью идентификатора
final
(С++ 11 и выше):struct Child : public Parent
{
void method_name() override final;
};
Ограничивать переопределения виртуальных методов может показаться неочевидным действием. Казалось бы, вот к чему это? Этот вопрос стоит рассматривать с технической и смысловой точки зрения. Начнем с последнего.
Код, который вы пишите, может быть достаточно глубоко осмыслен и выразителен. В частности, в семействе вашего класса можно выделить подсемейство со специфичным и фиксированным поведением.
В качестве примера, давайте рассмотрим семейство датчиков умного дома. Пусть была разработана открытая библиотека, которая предоставляет некоторый набор интерфейсов для разных типов датчиков. Например, для подсемейства пожарных датчиков. Производители устройств могут наследовать специальный интерфейс и реализовать прошивку для своего девайса. Как у них работает этот сенсор — никто не знает, но главное, что в случае срабатывания такого датчика происходит важное, в рамках этого подсемейства, действие - вызывается бригада пожарных. Это достаточно важный смысл, который может быть заложен в наследника класса и ограничен в переопределении для производителя:
// Датчик возгорания
struct IFireSensor : public ISensor
{
// В случае срабатывания, вызываем пожарных
void onAlarm(control_panel_t *ctrl) override final
{
ctrl->call_fireman();
}
};
Думаю, обосновывать важность этого ограничения не стоит. Если производитель по каким-то причинам захочет вызвать бригаду стриптизёров вместо пожарных, то до жаркой вечеринки дело не дойдёт!
Конечно, можно написать комментарии к коду, в надежде, что их прочитают... Но вот практика показывает, что их периодически игнорируют. Если какое-то ограничение не срабатывает во время компиляции и доходит до ревью, то разработка затягивается. Пока это увидят, пока переделают... Да и вообще, это сработает, только если у проверяющего достаточно компетенций / внимательности.
Кстати, хоть
final
и может быть применён только к виртуальному методу, мы не можем с помощью него проверить действительно ли мы переопределяем метод. Идентификатор final
может быть применён к новому объявленному методу, а override
нельзя. Следовательно, мы можем добиться такой ситуации: живой пример.С помощью идентификатора
final
можно расширить список гарантий, которые предоставляет выделенная ветка семейства классов. Это может оказаться полезным не только для разработчиков, но и для компилятора. Так можно выполнить некоторые оптимизации, ускоряющие работу вашей программы. Поговорим об этом в следующих постах.#cppcore #cpp11
Telegram
Грокаем C++
Всем привет! Мы в очередной раз подготовили серию грокательных постов о простом и не очень. В ближайшее время нас ждут следующие посты:
1. Память наследованных классов
2. Память виртуально наследованных классов
3. Девиртуализация доступа к полям виртуально…
1. Память наследованных классов
2. Память виртуально наследованных классов
3. Девиртуализация доступа к полям виртуально…
Construct on first use idiom
Давайте здесь по-подробнее остановимся. Вещь важная. Предыдущий пост. #опытным
Название говорящее и говорит оно нам, что объект будет конструироваться при первом использовании, а не когда-то заранее. То есть это ленивые вычисления.
Суть в том, чтобы создавать объект только в тот момент, когда он нам понадобиться. Так мы можем четко контролировать момент его инициализации. Делается это с помощью статических локальных переменных.
Мы помним, что они инициализируются при первом вызове функции и существуют они до смерти всей программы. Таким образом, если мы из функции будем возвращать ссылку на эту переменную, то есть сделаем такой геттер, то мы функционально будем иметь глобальную переменную, для которой мы контролируем начало ее жизни.
Вернемся к примеру и посмотрим, как это выглядит. Было так:
а теперь стало так:
Переменная
Теперь следите за руками: мы берем и оборачивает переменную, задающую значение, в функцию-геттер, которая просто выдает наружу значение этой переменной. Но инициализироваться
Теперь результат компиляции не зависит от порядка файлов, которые передаются на вход. Что так
Если у класса есть статическое поле и создание класса зависит от этого статического поля, то попробуйте перенести это поле внутрь статической функции(пример из этого поста):
Теперь во всех местах использования бывшего статического поля, мы вызывает статический метод. Таким образом наша мапа создается ровно по первому нашему хотению и создавать статический объект класса InitializationTest теперь абсолютно безопасно.
Если у вас есть 2 статических объекта пользовательского типа и инициализация одного из них предполагает использование другого, то можно сделать так(пример нагло украден у подписчика Бобра из этого коммента)
В этом примере создание объекта класса AnotherSingleton зависит от объекта Singleton. Поэтому мы запрещаем плебесам создавать объекты класса Singleton, а создаем его один раз в статической функции геттера инстанса объекта и дальше везде используем только этот инстанс.
Заключение в комментах
Solve your problems. Stay cool.
#cppcore #goodpractice #design
Давайте здесь по-подробнее остановимся. Вещь важная. Предыдущий пост. #опытным
Название говорящее и говорит оно нам, что объект будет конструироваться при первом использовании, а не когда-то заранее. То есть это ленивые вычисления.
Суть в том, чтобы создавать объект только в тот момент, когда он нам понадобиться. Так мы можем четко контролировать момент его инициализации. Делается это с помощью статических локальных переменных.
Мы помним, что они инициализируются при первом вызове функции и существуют они до смерти всей программы. Таким образом, если мы из функции будем возвращать ссылку на эту переменную, то есть сделаем такой геттер, то мы функционально будем иметь глобальную переменную, для которой мы контролируем начало ее жизни.
Вернемся к примеру и посмотрим, как это выглядит. Было так:
// source.cpp
int quad(int n) {
return n * n;
}
auto staticA = quad(5);
// main.cpp
#include <iostream>
extern int staticA;
auto staticB = staticA;
int main() {
std::cout << "staticB: " << staticB << std::endl;
}
а теперь стало так:
// source.cpp
int quad(int n) {
return n * n;
}
int& GetStaticA() {
static int staticA = quad(5);
return staticA;
}
// main.cpp
#include <iostream>
int& GetStaticA();
static auto staticB = GetStaticA();
// just omit main
Переменная
staticB
зависит от значения staticA
и это может вызвать проблемы, если инициализации staticB
произойдет первой.Теперь следите за руками: мы берем и оборачивает переменную, задающую значение, в функцию-геттер, которая просто выдает наружу значение этой переменной. Но инициализироваться
staticA
будет ровно в момент первого вызова функции GetStaticA
. Таким образом, мы форсим рантайм инициализировать staticA первым
при любых обстоятельствах.Теперь результат компиляции не зависит от порядка файлов, которые передаются на вход. Что так
g++ main.cpp source.cpp
, что так g++ source.cpp main.cpp
, результат будет staticB: 25
.Если у класса есть статическое поле и создание класса зависит от этого статического поля, то попробуйте перенести это поле внутрь статической функции(пример из этого поста):
using Map = std::map<std::string, std::unique_ptr<InitializationTest>>;
class InitializationTest {
public:
static Map& GetMap() {
static Map map;
return map;
}
static bool Create(std::string ID) {
GetMap().insert({ID, std::move(std::unique_ptr<InitializationTest>{new InitializationTest})});
return true;
}
private:
static Map map;
Test() = default;
};
static bool creation_result = InitializationTest::Create("qwe");
int main() {}
Теперь во всех местах использования бывшего статического поля, мы вызывает статический метод. Таким образом наша мапа создается ровно по первому нашему хотению и создавать статический объект класса InitializationTest теперь абсолютно безопасно.
Если у вас есть 2 статических объекта пользовательского типа и инициализация одного из них предполагает использование другого, то можно сделать так(пример нагло украден у подписчика Бобра из этого коммента)
// singleton.h
class Singleton {
public:
static Singleton& instance() {
static Singleton inst{};
return inst;
}
int makeSomethingUsefull(){}
private:
Singleton() = default;
};
//another_singleton.h
#include "singleton.h"
class AnotherSingleton {
public:
static AnotherSingleton& instance() {;
static AnotherSingleton inst{Singleton::instance().makeSomethingUsefull()};
return inst;
}
private:
AnotherSingleton(int param) : data{param} {};
int data;
};
В этом примере создание объекта класса AnotherSingleton зависит от объекта Singleton. Поэтому мы запрещаем плебесам создавать объекты класса Singleton, а создаем его один раз в статической функции геттера инстанса объекта и дальше везде используем только этот инстанс.
Заключение в комментах
Solve your problems. Stay cool.
#cppcore #goodpractice #design
Telegram
Грокаем C++
Решение static initialization order fiasco
Раз есть проблема - должно быть и решение. Сегодня поговорим о паре-тройке вариантов. Пост вдохновлен этим комментом нашего подписчика Антона.
Очевидно, что в комментах немного поразгоняли эту тему. Поэтому вот…
Раз есть проблема - должно быть и решение. Сегодня поговорим о паре-тройке вариантов. Пост вдохновлен этим комментом нашего подписчика Антона.
Очевидно, что в комментах немного поразгоняли эту тему. Поэтому вот…
Как работает динамический полиморфизм?
#новичкам
Продолжаем серию постов! В предыдущих статьях мы немного познакомились с возможностями полиморфных классов. Давайте подумаем, как же эта штука работает? По возможности, на собеседованиях интересуются этим вопросом 😉
Наверняка у вас так или иначе пробегал вопрос в голове: как же во время выполнения программы получается выбрать нужную реализацию метода, обращаясь к указателю лишь базового класса?
Это подталкивает к мысли, что объект полиморфного класса хранит какой-то секретик и владеет информацией о том, какие реализации методов надо вызывать.
Объекты полиморфных классов отличаются тем, что содержат в себе скрытый указатель на дополнительный участок памяти. В частности, размер объекта полиморфного класса немного больше:
Несмотря на то, что в
Данный скрытый указатель ведет в статическую область памяти, где лежит таблица виртуальных методов. Эта таблица представляет собой массив указателей на методы полиморфных наследников, в том числе и переопределенные. В общем случае, компилятор генерирует такие инструкции, которые будут разыменовывать эти указатели и совершать вызов нужной реализации. Это называется косвенным вызовом, indirect call.
Независимо от типа указателя на объект полиморфного класса, его скрытый указатель будет смотреть именно на ту таблицу, которая ассоциирована с конструированным классом:
Таким образом, и получается отвязать тип указателя от набора методов, которые должны быть вызваны.
Таблицы виртуальных методов генерируются на каждый полиморфный класс (не объект!), чтобы учесть все переопределения методов. Компилятор анализирует объявленные виртуальные методы и пронумеровывает их, а затем в этом порядке размещает в таблице. Например, для базового класса она будет выглядеть так:
А для наследованного класса уже вот так:
В конкретно взятых табличках всего две ячейки, которые хранят адрес на свою реализацию виртуального метода. В момент вызова, нам будет известен порядковый номер виртуального метода, а значит и его ячейку в таблице.
В общем случае, без каких либо оптимизаций, вызов виртуального метода состоит из следующих шагов:
1. Прочитать скрытый виртуальный указатель на таблицу
2. Сместить значение загруженного указателя до записи в таблице с адресом вызываемого метода
3. Прочитать адрес метода
4. Выполнить косвенный вызов по прочитанному адресу
Давайте мысленно препарируем участок вызывающего кода:
Думаю, что по моим комментариям к коду, а именно п. 6, видно, что даже сама программа не знает, что именно она вызывает, пока этого не сделает. Именно поэтому эта механика называется динамический полиморфизм.
Продолжение в комментариях 👇
#howitworks #cppcore
#новичкам
Продолжаем серию постов! В предыдущих статьях мы немного познакомились с возможностями полиморфных классов. Давайте подумаем, как же эта штука работает? По возможности, на собеседованиях интересуются этим вопросом 😉
Наверняка у вас так или иначе пробегал вопрос в голове: как же во время выполнения программы получается выбрать нужную реализацию метода, обращаясь к указателю лишь базового класса?
struct Base
{
virtual void vmethod_1();
virtual void vmethod_2();
};
struct Derived : public Base
{
void vmethod_2() override;
};
Base *data = new Derived();
// Calls Derived::vmethod_2()
data->vmethod_2();
Это подталкивает к мысли, что объект полиморфного класса хранит какой-то секретик и владеет информацией о том, какие реализации методов надо вызывать.
Объекты полиморфных классов отличаются тем, что содержат в себе скрытый указатель на дополнительный участок памяти. В частности, размер объекта полиморфного класса немного больше:
sizeof(Base) // returns 8
Несмотря на то, что в
Base
нет никаких полей, в данном случае размер не будет равен одному байту. Класс Base
формально пуст, но как раз под этот скрытый указатель резервируется доп. память: живой пример. На платформе x86-64 размер указателя равен 8 байт.Данный скрытый указатель ведет в статическую область памяти, где лежит таблица виртуальных методов. Эта таблица представляет собой массив указателей на методы полиморфных наследников, в том числе и переопределенные. В общем случае, компилятор генерирует такие инструкции, которые будут разыменовывать эти указатели и совершать вызов нужной реализации. Это называется косвенным вызовом, indirect call.
Независимо от типа указателя на объект полиморфного класса, его скрытый указатель будет смотреть именно на ту таблицу, которая ассоциирована с конструированным классом:
// Скрытый указатель объекта
// смотрит на vtable класса Base
Base *data = new Base();
// Скрытый указатель объекта
// смотрит на vtable класса Derived
Base *data = new Derived();
Таким образом, и получается отвязать тип указателя от набора методов, которые должны быть вызваны.
Таблицы виртуальных методов генерируются на каждый полиморфный класс (не объект!), чтобы учесть все переопределения методов. Компилятор анализирует объявленные виртуальные методы и пронумеровывает их, а затем в этом порядке размещает в таблице. Например, для базового класса она будет выглядеть так:
| vtable of Base |
|---------------------|
| &Base::vmethod_1 |
|---------------------|
| &Base::vmethod_2 |
А для наследованного класса уже вот так:
| vtable of Derived |
|---------------------|
| &Base::vmethod_1 |
|---------------------|
| &Derived::vmethod_2 |
В конкретно взятых табличках всего две ячейки, которые хранят адрес на свою реализацию виртуального метода. В момент вызова, нам будет известен порядковый номер виртуального метода, а значит и его ячейку в таблице.
В общем случае, без каких либо оптимизаций, вызов виртуального метода состоит из следующих шагов:
1. Прочитать скрытый виртуальный указатель на таблицу
2. Сместить значение загруженного указателя до записи в таблице с адресом вызываемого метода
3. Прочитать адрес метода
4. Выполнить косвенный вызов по прочитанному адресу
Давайте мысленно препарируем участок вызывающего кода:
void virtual_call(Base *object)
{
// 1. Разыменовываем указатель `data` на класс `Base`
// 2. Читаем указатель на vtable
// 3. Смещаемся на величину 1 указателя
// 4. Читаем указатель на `vmethod_2`
// 5. Вызываем данный метод
// 6. Ого! Оказывается, это была переопределение Derived::vmethod_2
object->vmethod_2();
}
Думаю, что по моим комментариям к коду, а именно п. 6, видно, что даже сама программа не знает, что именно она вызывает, пока этого не сделает. Именно поэтому эта механика называется динамический полиморфизм.
Продолжение в комментариях 👇
#howitworks #cppcore
Проблема Construct on first use idiom
#опытным
Прошлый пост показывает решение проблемы static initialization order fiasco. Однако даже этот прием имеет свои проблемы.
Дело в том, что мы сильно фокусировались на инициализации объекта и решали проблемы с ней. Но как насчет разрушения объекта? Мы подумали об этом? Not really.
Давайте возьмем классы, которые могут быть использованы для создания и статических объектов и любых других.
У нас все также 2 класса, но они уже не синглтоны, а могут создаваться в какой угодно области. Нам нужны статические объекты этих классов. И мы, как умные дяди, оградили себя от проблемы инициализации статиков, используя construct on first use idiom. Однако замечу, что в деструкторах наших классов они используют глобальную переменную another_global. И например, для объектов с автоматическим временем жизни это вообще не проблема, они свободно создаются и разрушаются.
Но что же будет, если так получится, что another_global удалится раньше, чем статические объекты наших классов? Правильно. Static deinitialization order fiasco. Обращение к уже разрушенному объекту - такое же UB, как и обращение к еще не инициализированному.
Кому-то очень сильно сейчас может свести багскулы, потому что логирование в деструкторах объектов, которые могут быть статиками - очень частая вещь, а соотвественно и потенциальная проблема. Подписчики могут подтвердить это в комментах.
Я сознательно тут в пример не ставлю синглтоны, потому что для них еще как-то можно осознать потенциальную проблему самостоятельно: объект один, мы четко понимаем, как он себя ведет, и можем подумать о его разрушении. Но в сегодняшнем примере при создании подобных классов обычно сильно не задумываются, что объект могут создать в статической области, а значит и о статической деинициализации не думают. Такая невнимательность может привести к трудноотловимым багам.
И это проблема не идиомы в целом, а подхода к созданию объекта. Есть и другой способ это делать:
Обратите внимание на магию. Мы внутри статических функций определяем не статические объекты, а статические указатели, к которым при первом вызове прикрепляем динамически созданные объекты. Вроде ничего кардинально не поменялось, но это на первый взгляд.
Мы никогда не вызываем delete. В конце программы разрушится только указатель, но не объект, на который он указывает. Обычно такая ситуация называется data leak, но в этом случае "вы не понимаете, это другое". Потому что при завершении программы ОС сама освобождает всю память, которая была занята программой и на самом деле ничего не утекает. Утечка памяти - это постоянное увеличение использования памяти программы со временем ее жизни. А тут мы один раз захватили эту память(и только эту!), но просто не отдали. Потребление памяти в течение программы не увеличивается. Как говорится: "Это норма!".
Этот вариант конечно не подойдет для тех случаев, если вам прям обязательно как-то сигнализировать о разрушении всех-превсех объектов этого класса и без этого никуда. Но он совершенно точно избавит вас от потенциальных проблем деинициализации(ее просто не будет хехе), если вам не важен деструктор статических объектов.
See drawbacks of your solutions. Stay cool.
#goodpractice #design #cppcore
#опытным
Прошлый пост показывает решение проблемы static initialization order fiasco. Однако даже этот прием имеет свои проблемы.
Дело в том, что мы сильно фокусировались на инициализации объекта и решали проблемы с ней. Но как насчет разрушения объекта? Мы подумали об этом? Not really.
Давайте возьмем классы, которые могут быть использованы для создания и статических объектов и любых других.
// ClassA.h
class ClassA {
public:
int makeSomethingUsefull(){}
~ClassA() { another_global.use_it();}
};
static ClassA& GetStaticClassA() {
static ClassA inst{};
return inst;
}
//another_singleton.h
#include "singleton.h"
class ClassB {
public:
ClassB(int param) : data{param} {};
~ClassB() { another_global.use_it();}
private:
int data;
};
static ClassB& GetStaticClassB() {;
static ClassB inst{GetStaticClassA().makeSomethingUsefull()};
return inst;
}
У нас все также 2 класса, но они уже не синглтоны, а могут создаваться в какой угодно области. Нам нужны статические объекты этих классов. И мы, как умные дяди, оградили себя от проблемы инициализации статиков, используя construct on first use idiom. Однако замечу, что в деструкторах наших классов они используют глобальную переменную another_global. И например, для объектов с автоматическим временем жизни это вообще не проблема, они свободно создаются и разрушаются.
Но что же будет, если так получится, что another_global удалится раньше, чем статические объекты наших классов? Правильно. Static deinitialization order fiasco. Обращение к уже разрушенному объекту - такое же UB, как и обращение к еще не инициализированному.
Кому-то очень сильно сейчас может свести багскулы, потому что логирование в деструкторах объектов, которые могут быть статиками - очень частая вещь, а соотвественно и потенциальная проблема. Подписчики могут подтвердить это в комментах.
Я сознательно тут в пример не ставлю синглтоны, потому что для них еще как-то можно осознать потенциальную проблему самостоятельно: объект один, мы четко понимаем, как он себя ведет, и можем подумать о его разрушении. Но в сегодняшнем примере при создании подобных классов обычно сильно не задумываются, что объект могут создать в статической области, а значит и о статической деинициализации не думают. Такая невнимательность может привести к трудноотловимым багам.
И это проблема не идиомы в целом, а подхода к созданию объекта. Есть и другой способ это делать:
// ClassA.h
// Here Class A definition
static ClassA& GetStaticClassA() {
static ClassA* inst = new ClassA{};
return *inst;
}
//another_singleton.h
#include "singleton.h"
// Here ClassB definition
static ClassB& GetStaticClassB() {;
static ClassB* inst = new ClassB{GetStaticClassA().makeSomethingUsefull()};
return *inst;
}
Обратите внимание на магию. Мы внутри статических функций определяем не статические объекты, а статические указатели, к которым при первом вызове прикрепляем динамически созданные объекты. Вроде ничего кардинально не поменялось, но это на первый взгляд.
Мы никогда не вызываем delete. В конце программы разрушится только указатель, но не объект, на который он указывает. Обычно такая ситуация называется data leak, но в этом случае "вы не понимаете, это другое". Потому что при завершении программы ОС сама освобождает всю память, которая была занята программой и на самом деле ничего не утекает. Утечка памяти - это постоянное увеличение использования памяти программы со временем ее жизни. А тут мы один раз захватили эту память(и только эту!), но просто не отдали. Потребление памяти в течение программы не увеличивается. Как говорится: "Это норма!".
Этот вариант конечно не подойдет для тех случаев, если вам прям обязательно как-то сигнализировать о разрушении всех-превсех объектов этого класса и без этого никуда. Но он совершенно точно избавит вас от потенциальных проблем деинициализации(ее просто не будет хехе), если вам не важен деструктор статических объектов.
See drawbacks of your solutions. Stay cool.
#goodpractice #design #cppcore
Еще один способ решения Static Initialization Order Fiasco
#опытным
Предыдущий пост навел меня на еще один метод решения SIOF. Это в догонку к этому посту с решениями.
Суть в чем. Как верно указал наш подписчик xiran в этом комментарии - управлять временем жизни глобальных динамически созданных объектов намного проще, чем временем жизни статиков. Поэтому можно объявить не статические переменные, а статические указатели. Указатель можно инициализировать nullptr и оставить его в таком состоянии хоть на месяц. И вы можете его инициализировать в любой подходящий для вас момент времени.
Это позволит вам в одном месте инициализировать связанные объекты сразу и в том порядке, в котором это не вызовет неприятных эффектов. Вы полностью контролируете ситуацию.
Примерно так это все выглядит. Если раньше, при обычной инициализации статиков в разных единицах трансляции, у нас порядок зависел от разумения линкера, то сейчас как ни компилируй, как ни линкуй, как ни меняй версию компилятора - все будет работать. Расширяйте этот пример как угодно, тема рабочая.
Правда тут есть одна загвоздочка, как вы могли заметить. У нас статиками являются обычные указатели и при разрушении всех статиков освободится лишь те 8 байт, которые были отведены этому указателю и никакого delete вызвано не будет. Как бы ситуация не очень, но нам и не всегда нужны эффекты от удаления статических объектов.
И эту загвоздочку прекрасно решают умные указатели. Сергей в своем комменте заванговал их использование. Покажу на примере unique_ptr. При деинициализации статиков вызовется деструктор unique_ptr, который за собой потянет деструктор объекта. Тут тоже могут быть проблемы с индирекцией данных и более медленным доступом к ним, но это настолько редкий кейс с плохим дизайном, что не хочется это даже обсуждать.
Вот так это выглядит в "идеале". Можете дальше пользоваться своими глобальными переменными(осуждаем), но хотя бы безопасно.
Stay safe. Stay cool.
#cpprore #cpp11 #STL #pattern
#опытным
Предыдущий пост навел меня на еще один метод решения SIOF. Это в догонку к этому посту с решениями.
Суть в чем. Как верно указал наш подписчик xiran в этом комментарии - управлять временем жизни глобальных динамически созданных объектов намного проще, чем временем жизни статиков. Поэтому можно объявить не статические переменные, а статические указатели. Указатель можно инициализировать nullptr и оставить его в таком состоянии хоть на месяц. И вы можете его инициализировать в любой подходящий для вас момент времени.
Это позволит вам в одном месте инициализировать связанные объекты сразу и в том порядке, в котором это не вызовет неприятных эффектов. Вы полностью контролируете ситуацию.
// header.hpp
struct Class {
Class(int num) : field{num} {}
int field;
};
// source.cpp
Class * static_ptr2 = nullptr;
//main.cpp
int * static_ptr1;
extern Class * static_ptr2;
void Init() {
static_ptr1 = new int{6};
static_ptr2 = new Class{*static_ptr1};
}
int main() {
Init();
std::cout << static_ptr2->field << std::endl;
}
Примерно так это все выглядит. Если раньше, при обычной инициализации статиков в разных единицах трансляции, у нас порядок зависел от разумения линкера, то сейчас как ни компилируй, как ни линкуй, как ни меняй версию компилятора - все будет работать. Расширяйте этот пример как угодно, тема рабочая.
Правда тут есть одна загвоздочка, как вы могли заметить. У нас статиками являются обычные указатели и при разрушении всех статиков освободится лишь те 8 байт, которые были отведены этому указателю и никакого delete вызвано не будет. Как бы ситуация не очень, но нам и не всегда нужны эффекты от удаления статических объектов.
И эту загвоздочку прекрасно решают умные указатели. Сергей в своем комменте заванговал их использование. Покажу на примере unique_ptr. При деинициализации статиков вызовется деструктор unique_ptr, который за собой потянет деструктор объекта. Тут тоже могут быть проблемы с индирекцией данных и более медленным доступом к ним, но это настолько редкий кейс с плохим дизайном, что не хочется это даже обсуждать.
// header.hpp
struct Class {
Class(int num) : field{num} {}
int field;
};
// source.cpp
std::unique_ptr<Class> static_ptr2 = nullptr;
//main.cpp
std::unique_ptr<int> static_ptr1 = nullptr;
extern std::unique_ptr<Class> static_ptr2;
void Init() {
static_ptr1 = std::make_unique<int>(6);
static_ptr2 = std::make_unique<Class>(*static_ptr1);
}
int main() {
Init();
std::cout << static_ptr2->field << std::endl;
}
Вот так это выглядит в "идеале". Можете дальше пользоваться своими глобальными переменными(осуждаем), но хотя бы безопасно.
Stay safe. Stay cool.
#cpprore #cpp11 #STL #pattern
Как работает dynamic_cast? RTTI!
#опытным #fun
Продолжаем серию! В прошлой статье мы познакомились с таблицей виртуальных методов. Помимо этой таблицы, в этой же области памяти скрывается еще одна структура.
Как мы видели ранее, для полиморфных объектов существует специальный оператор dynamic_cast. Стандарт не регламентирует его реализацию, но чаще всего, для работы требуется дополнительная информация о типе полиморфного объекта RTTI (Run Time Type Information). Посмотреть эту структуру можно с помощью оператора
Содержимое RTTI зависит от компилятора, но как минимум там хранится
Операторы
Как же нам найти начало объекта RTTI? Не боги горшки обжигают, есть просто специальный указатель, который расположен прямо перед началом таблицы виртуальных методов. Он и ведёт к объекту RTTI:
Получив доступ к дополнительной информации остаётся выполнить приведение типа: upcast, downcast, sidecast/crosscast. Эта задача требует совершить поиск в ориентированном ациклическом графе (DAG, directed acyclic graph), что в рамках этой операции может быть трудоёмким, но необходимым для обработки общего случая. Теперь мы можем даже ответить, почему
Можем ли мы как-то ускорить работу? Мы можем просто запретить использовать
И такое ограничение будет автоматически подталкивать к пересмотру полученной архитектуры решения или разработке собственного механизма приведения типов.
На счет последнего надо много и долго думать. На стыке двух динамических библиотек, которые могут ничего не знать друг о друге, придется как-то проверять, что лежит в динамическом типе. Так же необходимо учитывать особенности множественного и виртуального наследования. От них можно и в принципе отказаться, но как запретить вышеупомянутые виды наследования в коде? Меня бы в первую очередь интересовала автономная и независимая жизнь проекта без пристального надзора хранителей знаний. Это задача, которая имеет много подводных камней или требует введения в проект ограничений, дополнительного контроля.
Если
#cppcore #howitworks
#опытным #fun
Продолжаем серию! В прошлой статье мы познакомились с таблицей виртуальных методов. Помимо этой таблицы, в этой же области памяти скрывается еще одна структура.
Как мы видели ранее, для полиморфных объектов существует специальный оператор dynamic_cast. Стандарт не регламентирует его реализацию, но чаще всего, для работы требуется дополнительная информация о типе полиморфного объекта RTTI (Run Time Type Information). Посмотреть эту структуру можно с помощью оператора
typeid
:cppОбратите внимание,
const auto &RTTI = typeid(object);
typeid
возвращает read-only ссылку на объект std::type_info
, т.к. эту область памяти нельзя изменять — она была сгенерирована компилятором на этапе компиляции.Содержимое RTTI зависит от компилятора, но как минимум там хранится
hash
полиморфного класса и его имя, которые доступны из std::type_info
. Маловероятно, что вам на этом потребуется построить какую-то логику приложения, но эта штука могла бы быть вам полезна при отладке / подсчёте статистики и т.д. Операторы
dynamic_cast
и typeid
получают доступ к этой структуре так же через скрытый виртуальный указатель, который подшивается к объектам полиморфного класса. Как мы знаем, этот указатель смотрит на начало таблицы виртуальных методов, коих может быть бесчисленное множество и варьироваться от наследника к наследнику.Как же нам найти начало объекта RTTI? Не боги горшки обжигают, есть просто специальный указатель, который расположен прямо перед началом таблицы виртуальных методов. Он и ведёт к объекту RTTI:
┌-─| ptr to RTTI | vtable pointer
| |----------------| <- looks here
| | vtable methods |
| |----------------|
└─>| RTTI object |
Получив доступ к дополнительной информации остаётся выполнить приведение типа: upcast, downcast, sidecast/crosscast. Эта задача требует совершить поиск в ориентированном ациклическом графе (DAG, directed acyclic graph), что в рамках этой операции может быть трудоёмким, но необходимым для обработки общего случая. Теперь мы можем даже ответить, почему
dynamic_cast
такой медленный.Можем ли мы как-то ускорить работу? Мы можем просто запретить использовать
dynamic_cast
😄 Это можно сделать, отключив RTTI с помощью флага компиляции:-fno-rtti
И такое ограничение будет автоматически подталкивать к пересмотру полученной архитектуры решения или разработке собственного механизма приведения типов.
На счет последнего надо много и долго думать. На стыке двух динамических библиотек, которые могут ничего не знать друг о друге, придется как-то проверять, что лежит в динамическом типе. Так же необходимо учитывать особенности множественного и виртуального наследования. От них можно и в принципе отказаться, но как запретить вышеупомянутые виды наследования в коде? Меня бы в первую очередь интересовала автономная и независимая жизнь проекта без пристального надзора хранителей знаний. Это задача, которая имеет много подводных камней или требует введения в проект ограничений, дополнительного контроля.
Если
dynamic_cast
становится бутылочным горлышком, то в первую очередь стоит пересмотреть именно архитектуру решения, а оптимизации оставить на крайний случай.#cppcore #howitworks
Еще одна проблема при разрушении статиков
#опытным
Идею для поста подкинул Михаил в этом комменте
Суть в чем. Все глобальные переменные, не помеченные thread_local, создаются и уничтожаются в главном потоке, в котором выполняется main(). Но использовать мы их можем и в других потоках, адресное пространство-то одно. И вот здесь скрывается опасность: мы можем использовать в другом потоке глобальную переменную, которая уже была уничтожена!
Вы просите объяснений? Их есть у меня.
Для начала нужно понять, при каких условиях мы можем получить ситуацию, при которой статическая переменная уже удалилась, программа еще не завершилась, а другой тред продолжает использовать переменную.
По пунктам
1️⃣ Статические переменные удаляются при вызове std::exit, что происходит после завершения main(). Значит, нам нужно выйти из main'а.
2️⃣ Получается, что второй поток должен продолжать выполняться даже после завершения main. Тут только один вариант: отделить тред от его объекта, чтобы его не нужно было джойнить. Делается это с помощью метода detach().
3️⃣ Использование переменной вторым потоком должно быть между разрушением глобальной переменной и завершением std::exit, потому что эта функция завершает процесс. И естественно, что после завершения процесса уже никакие потоки выполняться не могут.
Вот такие незамысловатые условия. Давайте посмотрим на примере.
Быстренькое пояснение. Создал 2 простеньких класса, которые позволят наглядно показать процесс удаления переменной и использования ее после удаления. Деструктор первого класса заставляет главный тред уснуть на 5 секунд, что помещает программу в опасное состояние как раз между ее завершением и разрушением статиков. Второй класс мы как раз и будем использовать для создания шаренного объекта, который использует второй тред. У него в деструкторе выводится сообщение-индикатор удаления. Давайте посмотрим на вывод:
Поймана за хвост, паршивка! Мы используем поле удаленного объекта, что чистой воды UB!
Собсна, это еще одна причина отказываться от статических объектов в пользу инкапсуляции их в классы и прокидывания явным образом во все нужные места. Потому что даже такая базовая вещь, как логгер, может сильно подпортить жизнь.
Если я что-то упустил, то пусть Михаил меня поправит в комментах.
Avoid dangerous practices. Stay cool.
#cppcore #cpp11 #concurrency
#опытным
Идею для поста подкинул Михаил в этом комменте
Суть в чем. Все глобальные переменные, не помеченные thread_local, создаются и уничтожаются в главном потоке, в котором выполняется main(). Но использовать мы их можем и в других потоках, адресное пространство-то одно. И вот здесь скрывается опасность: мы можем использовать в другом потоке глобальную переменную, которая уже была уничтожена!
Вы просите объяснений? Их есть у меня.
Для начала нужно понять, при каких условиях мы можем получить ситуацию, при которой статическая переменная уже удалилась, программа еще не завершилась, а другой тред продолжает использовать переменную.
По пунктам
1️⃣ Статические переменные удаляются при вызове std::exit, что происходит после завершения main(). Значит, нам нужно выйти из main'а.
2️⃣ Получается, что второй поток должен продолжать выполняться даже после завершения main. Тут только один вариант: отделить тред от его объекта, чтобы его не нужно было джойнить. Делается это с помощью метода detach().
3️⃣ Использование переменной вторым потоком должно быть между разрушением глобальной переменной и завершением std::exit, потому что эта функция завершает процесс. И естественно, что после завершения процесса уже никакие потоки выполняться не могут.
Вот такие незамысловатые условия. Давайте посмотрим на примере.
struct A {
~A() {
std::this_thread::sleep_for(std::chrono::seconds(5));
}
};
struct B {
std::string str = "Use me";
~B() {
std::cout << "B dtor" << std::endl;;
}
};
A global_for_waiting_inside_globals_dectruction;
B violated_global;
void Func() {
for (int i = 0; i < 20; ++i) {
std::cout << violated_global.str << std::endl;
std::this_thread::sleep_for(std::chrono::seconds(1));
}
}
int main() {
std::thread th{Func};
th.detach();
std::this_thread::sleep_for(std::chrono::seconds(3)); // aka some usefull work
}
Быстренькое пояснение. Создал 2 простеньких класса, которые позволят наглядно показать процесс удаления переменной и использования ее после удаления. Деструктор первого класса заставляет главный тред уснуть на 5 секунд, что помещает программу в опасное состояние как раз между ее завершением и разрушением статиков. Второй класс мы как раз и будем использовать для создания шаренного объекта, который использует второй тред. У него в деструкторе выводится сообщение-индикатор удаления. Давайте посмотрим на вывод:
Use me
Use me
Use me
B dtor
Use me
Use me
Use me
Use me
Use me
Поймана за хвост, паршивка! Мы используем поле удаленного объекта, что чистой воды UB!
Собсна, это еще одна причина отказываться от статических объектов в пользу инкапсуляции их в классы и прокидывания явным образом во все нужные места. Потому что даже такая базовая вещь, как логгер, может сильно подпортить жизнь.
Если я что-то упустил, то пусть Михаил меня поправит в комментах.
Avoid dangerous practices. Stay cool.
#cppcore #cpp11 #concurrency
Задача
Эх, давно мы вам задачек не задавали. В канале значительно прибавилось народу с тех пор, поэтому стоит пояснить. Мы возвращаем многим полюбившуюся рубрику #задачки, где подписчики совместно в комментах решают поставленные нами задачи. Они не обязательно относятся к программированию. Математические и логические тоже горячо принимаются публикой. Главное, чтобы интересно было! И сегодня как раз такой случай.
Снова у нас главный герой - царь. Деспотом был этот царь и любил издеваться над своими подданными. В этот раз он решил поиздеваться над самыми светлыми умами в царстве - мудрецами. Собрал царь 20 мудрецов и сказал им следующее: "Я хочу проверить и протестировать вашу мудрость, мои мудрецы. Вы будете выстроены в одну колонну друг за другом лицом к затылку, да так, чтобы никто не смел оборачиваться назад. А то казню! Каждый сможет видеть только впереди стоящих мудрецов. Первый не видит никого. Последний видит всех, крое себя. На каждом из вас будет шляпа одного из двух цветов: черного и белого, которую вы не сможете увидеть. Каждый из вас должен будет угадать цвет своей шляпы. То есть каждый должен будет сказать всего одно монотонное слово: либо "белая", либо "черная". Если не угадаете - голову с плеч! Но Я хочу протестировать вашу мудрость - Я даю вам возможность посовещаться и выбрать стратегию ответов, а также кто и в каком порядке будет давать ответ. Во время нашей забавы вы сможете услышать ответы своих товарищей, но трогать вы никого не можете. Посмотрим, так ли вы мудры, как о вас молвят люди."
Мудрецы знатно наложили в штаны, но ничего не сделаешь, придется прибегать к своему профессиональному навыку - думанью.
Ни один из мудрецов умирать не хочет. Поэтому им кровь из носу нужно придумать такую стратегию, при которой умрет наименьшее их количество.
Собственно, задача для вас - придумать такую стратегию поведения.
Напомню формат: под этим постом идут обсуждения ваших решений. Большая просьба для людей, которые уже слышали решение этой задачи - не спойлерите людям процесс думанья!
Вечером выйдет пост с ответом, где уже все могут обсуждать, что угодно.
В целом, это все условия и правила.
Раз, два, три - мудрецам ты помоги! Погнали решать!
Challenge yourself. Stay cool.
Эх, давно мы вам задачек не задавали. В канале значительно прибавилось народу с тех пор, поэтому стоит пояснить. Мы возвращаем многим полюбившуюся рубрику #задачки, где подписчики совместно в комментах решают поставленные нами задачи. Они не обязательно относятся к программированию. Математические и логические тоже горячо принимаются публикой. Главное, чтобы интересно было! И сегодня как раз такой случай.
Снова у нас главный герой - царь. Деспотом был этот царь и любил издеваться над своими подданными. В этот раз он решил поиздеваться над самыми светлыми умами в царстве - мудрецами. Собрал царь 20 мудрецов и сказал им следующее: "Я хочу проверить и протестировать вашу мудрость, мои мудрецы. Вы будете выстроены в одну колонну друг за другом лицом к затылку, да так, чтобы никто не смел оборачиваться назад. А то казню! Каждый сможет видеть только впереди стоящих мудрецов. Первый не видит никого. Последний видит всех, крое себя. На каждом из вас будет шляпа одного из двух цветов: черного и белого, которую вы не сможете увидеть. Каждый из вас должен будет угадать цвет своей шляпы. То есть каждый должен будет сказать всего одно монотонное слово: либо "белая", либо "черная". Если не угадаете - голову с плеч! Но Я хочу протестировать вашу мудрость - Я даю вам возможность посовещаться и выбрать стратегию ответов, а также кто и в каком порядке будет давать ответ. Во время нашей забавы вы сможете услышать ответы своих товарищей, но трогать вы никого не можете. Посмотрим, так ли вы мудры, как о вас молвят люди."
Мудрецы знатно наложили в штаны, но ничего не сделаешь, придется прибегать к своему профессиональному навыку - думанью.
Ни один из мудрецов умирать не хочет. Поэтому им кровь из носу нужно придумать такую стратегию, при которой умрет наименьшее их количество.
Собственно, задача для вас - придумать такую стратегию поведения.
Напомню формат: под этим постом идут обсуждения ваших решений. Большая просьба для людей, которые уже слышали решение этой задачи - не спойлерите людям процесс думанья!
Вечером выйдет пост с ответом, где уже все могут обсуждать, что угодно.
В целом, это все условия и правила.
Раз, два, три - мудрецам ты помоги! Погнали решать!
Challenge yourself. Stay cool.
Решение задачи с мудрецами
Давайте для начала решим, кто из колонны мудрецов будет иметь самую большую осведомленность о цветах всех шляп мудрецов. Очевидно, что последний в колонне может видеть всех остальных мудрецов и их шляпы. И так как он знает все цвета, кроме своего, то он может эту информацию передать дальше. Следующий по осведомленности идет мудрец, стоящий сразу перед последним. Он видит всех, кроме себя и позади стоящего. Рассуждая такой логикой мы имеем ситуацию, когда больше всего информации об обстановке у последнего в шеренге, а меньше всего - у первого. Так давайте же назначим порядок ответов мудрецом в соответствии с убыванием количества знаний об обстановке. То есть сначала отвечает самый последний мыслитель, у которого сзади никого нет, затем предпоследний и так далее до первого.
Теперь осталось только научиться передавать информацию об обстановке от последнего до первого мыслителя. Если мы выработаем такую стратегию, при которой каждый последующий мудрец на основе подсказки предыдущего и своих знаний сможет дать верный ответ, то мы спасем целых 19 мудрецов! Ну и последнему не очень повезло. Он в таком случае просто не сможет гарантировано остаться в живых. Но зато этот герой отдаст свою жизнь ради интеллектуального будущего царства!
И такая стратегия есть)
Мыслители договорились, что последний из них скажет, что у него белая шляпа, если он увидит перед собой четное количество белых шляп. И если увидит нечетное количество белых шляп, то ответит, что у него она черная.
После этого следующий мудрец будет знать четность количества белых шляп всех впереди стоящих мыслителей(он их видит) и общую четность белых шляп включая его собственную. Сопоставляя эти четности он четко сможет понять какая у него шляпа и даст правильный ответ.
И все последующие мудрецы на основе ответов своих предыдущих коллег смогут дать правильный ответ. Приведу сразу пример для наглядности.
Рассмотрим колонну из 5 мудрецов. Для большей длины все будет аналогично. Б - мудрец с белой шляпой, Ч - с черной. Поставили их вот так:
1 2 3 4 5
Б<-Ч<-Ч<-Б<-Ч
Справа - последний, он видит четверых предыдущих. Слева первый, который никого не видит.
Последний сосчитал количество белых шляп впереди - 2. 2 - четное число, поэтому он говорит, что у него белая шляпа. Ему отрубают голову(R.I.P).
4-ый знает, что когда последний говорит белая, значит впереди него четное число белых шляп. Он смотрит вперед и видит всего одну шляпу. Это нечетное число. Получается, что четность белых шляп изменилась, а значит у него самого белая шляпа. Он дает правильный ответ.
3-ий знает, что на предыдущем мудреце четность количества белых шляп изменилась. Значит у трех мудрецов, включая его, нечетное их количество. Он видит перед собой одну белую, понимает, что четность не поменялась и говорит "черная". И это правильный ответ!
2-ой знает, что на предыдущем шаге сказали "черная", значит белых должно быть также нечетное количество. Перед собой он видит белую шляпу, поэтому, не стесняясь, говорит: "черная". И оказывается прав.
1-ый знает, что белых шляп все еще нечетное число, поэтому говорит: "белая". И оказывается в стане спасенных.
Думаю, что схему вы поняли. Любой ответ "белая" меняет ожидаемую четность на противоположную. Сопоставляя эту четность с количеством белых шляп впереди можно однозначно дать правильный ответ.
Тут есть интересный edge case. Если нет ни одной белой шляпы среди 19-ти впереди стоящих мудрецов, последний должен сказать "белая". То есть посчитать ноль четным числом. Тогда следующий не увидит перед собой белых шляп, но будет знать, что их должно быть четное количество. И единственный вариант, когда это возможно - впереди последнего были все черные шляпы.
Такая задачка. Делитесь эмоциями от ее решения в комментах. И не скупитесь на лайки!
Solve your problems. Stay cool.
Давайте для начала решим, кто из колонны мудрецов будет иметь самую большую осведомленность о цветах всех шляп мудрецов. Очевидно, что последний в колонне может видеть всех остальных мудрецов и их шляпы. И так как он знает все цвета, кроме своего, то он может эту информацию передать дальше. Следующий по осведомленности идет мудрец, стоящий сразу перед последним. Он видит всех, кроме себя и позади стоящего. Рассуждая такой логикой мы имеем ситуацию, когда больше всего информации об обстановке у последнего в шеренге, а меньше всего - у первого. Так давайте же назначим порядок ответов мудрецом в соответствии с убыванием количества знаний об обстановке. То есть сначала отвечает самый последний мыслитель, у которого сзади никого нет, затем предпоследний и так далее до первого.
Теперь осталось только научиться передавать информацию об обстановке от последнего до первого мыслителя. Если мы выработаем такую стратегию, при которой каждый последующий мудрец на основе подсказки предыдущего и своих знаний сможет дать верный ответ, то мы спасем целых 19 мудрецов! Ну и последнему не очень повезло. Он в таком случае просто не сможет гарантировано остаться в живых. Но зато этот герой отдаст свою жизнь ради интеллектуального будущего царства!
И такая стратегия есть)
Мыслители договорились, что последний из них скажет, что у него белая шляпа, если он увидит перед собой четное количество белых шляп. И если увидит нечетное количество белых шляп, то ответит, что у него она черная.
После этого следующий мудрец будет знать четность количества белых шляп всех впереди стоящих мыслителей(он их видит) и общую четность белых шляп включая его собственную. Сопоставляя эти четности он четко сможет понять какая у него шляпа и даст правильный ответ.
И все последующие мудрецы на основе ответов своих предыдущих коллег смогут дать правильный ответ. Приведу сразу пример для наглядности.
Рассмотрим колонну из 5 мудрецов. Для большей длины все будет аналогично. Б - мудрец с белой шляпой, Ч - с черной. Поставили их вот так:
1 2 3 4 5
Б<-Ч<-Ч<-Б<-Ч
Справа - последний, он видит четверых предыдущих. Слева первый, который никого не видит.
Последний сосчитал количество белых шляп впереди - 2. 2 - четное число, поэтому он говорит, что у него белая шляпа. Ему отрубают голову(R.I.P).
4-ый знает, что когда последний говорит белая, значит впереди него четное число белых шляп. Он смотрит вперед и видит всего одну шляпу. Это нечетное число. Получается, что четность белых шляп изменилась, а значит у него самого белая шляпа. Он дает правильный ответ.
3-ий знает, что на предыдущем мудреце четность количества белых шляп изменилась. Значит у трех мудрецов, включая его, нечетное их количество. Он видит перед собой одну белую, понимает, что четность не поменялась и говорит "черная". И это правильный ответ!
2-ой знает, что на предыдущем шаге сказали "черная", значит белых должно быть также нечетное количество. Перед собой он видит белую шляпу, поэтому, не стесняясь, говорит: "черная". И оказывается прав.
1-ый знает, что белых шляп все еще нечетное число, поэтому говорит: "белая". И оказывается в стане спасенных.
Думаю, что схему вы поняли. Любой ответ "белая" меняет ожидаемую четность на противоположную. Сопоставляя эту четность с количеством белых шляп впереди можно однозначно дать правильный ответ.
Тут есть интересный edge case. Если нет ни одной белой шляпы среди 19-ти впереди стоящих мудрецов, последний должен сказать "белая". То есть посчитать ноль четным числом. Тогда следующий не увидит перед собой белых шляп, но будет знать, что их должно быть четное количество. И единственный вариант, когда это возможно - впереди последнего были все черные шляпы.
Такая задачка. Делитесь эмоциями от ее решения в комментах. И не скупитесь на лайки!
Solve your problems. Stay cool.
Девиртуализация вызовов. Ч2
#опытным
В предыдущем посте мы столкнулись с невозможностью девиртуализировать функцию
Получается, что нам достаточно ограничить внешнее связывание? Рассмотрим в примерах дальше 😊
Запрет на внешнее связывание 1
Итак, мы ведь знаем, что для конкретной функции можно запретить внешнее связывание, например, с помощью
Вызов функции
Кстати, П.2 может быть доказан лишь частично! Например,
В данном случае, с учетом всех наборов аргументов при вызове
Запрет на внешнее связывание 2
В предыдущих способах можно заметить, что сложности возникают с доказательством П.2 и П.4. Компилятор опасается, что в других единицах трансляции появятся либо новые перегрузки, либо будут вызваны функции с объектами других наследников полиморфных классов.
Учитывая особенности сборки проекта, разработчик может намеренно сообщить компилятору, что других единиц трансляции не будет. В частности, для LLVM Clang можно применить следующие опции:
В GCC можно вообще указать, что компилируемая единица и есть вся программа с помощью флага:
Он буквально разрешает считать, что компилятор знает ВСЕ известные перегрузки и их вызовы. Короче, отметит все функции ключевым словом
Запрет на внешнее связывание 3
Еще один способ показать компилятору, что новых полиморфных перегрузок не появится. Можно использовать unnamed namespace:
Теперь данное семейство полиморфных классов будет скрыто от других единиц трансляции, что доказывает компилятору П.3 и П.4, а так же П.2 по месту требования.
Вот такими несложными действиями можно сократить количество обращений к таблице виртуальных методов и ускорить выполнение вашего приложения 😉
#cppcore #hardcore #howitworks
#опытным
В предыдущем посте мы столкнулись с невозможностью девиртуализировать функцию
bar
, т.к. мы не могли гарантировать отсутствие вызовов из других единиц трансляции.Получается, что нам достаточно ограничить внешнее связывание? Рассмотрим в примерах дальше 😊
Запрет на внешнее связывание 1
Итак, мы ведь знаем, что для конкретной функции можно запретить внешнее связывание, например, с помощью
static
. Из живого примера:// direct call!
static void bar(Base &da, Base &db)
{
// push rbx
// mov rax, [rdi]
// mov rbx, rsi
da.vmethod(); // call DerivedA::vmethod()
// mov rdi, rbx
// pop rbx
db.vmethod(); // jmp DerivedB::vmethod()
}
Вызов функции
bar
- единственный в данной единице трансляции, с конкретными наследниками Base
. Следовательно, мы можем доказать П.2, П.4, П.3 (терминология из первой части).Кстати, П.2 может быть доказан лишь частично! Например,
bar
можно вызывать с разными аргументами, тогда оптимизация будет совершена лишь частично:// indirect + direct call
static void bar(Base &da, Base &db)
{
// push rbx
// mov rax, [rdi]
// mov rbx, rsi
da.vmethod(); // call [[rax]]
// mov rdi, rbx
// pop rbx
db.vmethod(); // jmp DerivedB::vmethod()
}
В данном случае, с учетом всех наборов аргументов при вызове
foo
, только второй vmethod
может быть оптимизирован.Запрет на внешнее связывание 2
В предыдущих способах можно заметить, что сложности возникают с доказательством П.2 и П.4. Компилятор опасается, что в других единицах трансляции появятся либо новые перегрузки, либо будут вызваны функции с объектами других наследников полиморфных классов.
Учитывая особенности сборки проекта, разработчик может намеренно сообщить компилятору, что других единиц трансляции не будет. В частности, для LLVM Clang можно применить следующие опции:
-flto -fwhole-program-vtables -fvisibility=hidden
В GCC можно вообще указать, что компилируемая единица и есть вся программа с помощью флага:
-fwhole-program
Он буквально разрешает считать, что компилятор знает ВСЕ известные перегрузки и их вызовы. Короче, отметит все функции ключевым словом
static
: живой пример.Запрет на внешнее связывание 3
Еще один способ показать компилятору, что новых полиморфных перегрузок не появится. Можно использовать unnamed namespace:
namespace
{
struct Base
{
virtual void vmethod();
};
struct Derived : public Base
{
void vmethod() override;
};
}
Теперь данное семейство полиморфных классов будет скрыто от других единиц трансляции, что доказывает компилятору П.3 и П.4, а так же П.2 по месту требования.
Вот такими несложными действиями можно сократить количество обращений к таблице виртуальных методов и ускорить выполнение вашего приложения 😉
#cppcore #hardcore #howitworks
C-style cast
#новичкам
Как уже неоднократно было нами отмечено, что язык C++ разрабатывался с поддержкой обратной совместимости языка C. В частности, в C++ поддерживается приведение в стиле C:
Это достаточно короткий и, на первый взгляд, интуитивно понятный оператор, за что его необоснованно любят использовать в C++.
Вот давайте вспомним все операторы приведения, про которые мы успели рассказать? У нас были посты про:
- static_cast
- reinterpret_cast
- const_cast
- dynamic_cast
У каждого из них есть своя область применения и соответствующий алгоритм приведения, а так же наборы проверок! Т.к. C-style cast сочетает в себе все вышеперечисленные операторы, то большая часть проверок просто отсутствует... Они не проверяют конкретный случай, что является очень опасным моментом.
В случае невозможности желаемого приведения, C-style cast совершит другое подходящее. Рассмотрим ошибку из живого примера:
Мы хотели привести
Давайте вспомним про приведение между ветками ромбовидного наследования из статьи про
Опустим тему с
И вот ладно, дело во внимательности и понимании предназначения операторов... C-style cast позволяет выполнить приведение к приватным предкам класса: живой пример. Вот от вас намеренно хотели скрыть возможность вмешательства в поведение предка, а вы это ограничение обошли и даже не заметили подвоха. Увидеть это на ревью так же сложно! Это ведет к очень забагованному поведению программы.
Оператор C-style cast скрывает в себе достаточно неочевидное поведение в некоторых ситуациях. Его сложно заметить, его сложно отлаживать. Возможно, что будет проще отказаться от него вовсе, чем помнить о всех подводных камнях. Предупреждения вам в помощь! Добавляйте опцию компилятора:
#cppcore #goodpractice
#новичкам
Как уже неоднократно было нами отмечено, что язык C++ разрабатывался с поддержкой обратной совместимости языка C. В частности, в C++ поддерживается приведение в стиле C:
int value = (int)arg;
Это достаточно короткий и, на первый взгляд, интуитивно понятный оператор, за что его необоснованно любят использовать в C++.
Вот давайте вспомним все операторы приведения, про которые мы успели рассказать? У нас были посты про:
- static_cast
- reinterpret_cast
- const_cast
- dynamic_cast
У каждого из них есть своя область применения и соответствующий алгоритм приведения, а так же наборы проверок! Т.к. C-style cast сочетает в себе все вышеперечисленные операторы, то большая часть проверок просто отсутствует... Они не проверяют конкретный случай, что является очень опасным моментом.
В случае невозможности желаемого приведения, C-style cast совершит другое подходящее. Рассмотрим ошибку из живого примера:
cpp
using PPrintableValue = PrintableValue *;
...
auto data = (PPrintableValue)value;
Мы хотели привести
value
к типу PrintableValue
(int64_t
-> int32_t
). Но в результате неудачного нейминга псевдонима мы ошиблись. Вдруг клавиша P
залипла просто? Вдруг рефакторинг неудачно прошел? В итоге мы собрали программу, смогли её запустить и привели int64_t
к int32_t*
, а дальше его попытались разыменовать. На первый взгляд, ошибка непонятна: мы ожидали static_cast
, а получили reinterpret_cast
. В больших продуктах такие ошибки могут оставаться незамеченными, пока не будет проведено полное тестирование продукта (вами или клиентом).Давайте вспомним про приведение между ветками ромбовидного наследования из статьи про
dynamic_cast
. Использование C-style приведения бездумно выполнит то, что от него попросили и вляпается в ошибку, хоть красненьким и не подчеркивается :) На самом деле он выполнит reinterpret_cast
, но это логическая ошибка! Нам очевидно, что этот оператор не подходит по смыслу, но может подойти static_cast
. Если мы попробуем это сделать, будет ошибка компиляции:error: invalid 'static_cast' from type 'Mother*' to type 'Father*':
Father *switched_son_of_father = static_cast<Father*>(son_of_mother);
Опустим тему с
const_cast
, думаю, тут и так все понятно. И вот ладно, дело во внимательности и понимании предназначения операторов... C-style cast позволяет выполнить приведение к приватным предкам класса: живой пример. Вот от вас намеренно хотели скрыть возможность вмешательства в поведение предка, а вы это ограничение обошли и даже не заметили подвоха. Увидеть это на ревью так же сложно! Это ведет к очень забагованному поведению программы.
Оператор C-style cast скрывает в себе достаточно неочевидное поведение в некоторых ситуациях. Его сложно заметить, его сложно отлаживать. Возможно, что будет проще отказаться от него вовсе, чем помнить о всех подводных камнях. Предупреждения вам в помощь! Добавляйте опцию компилятора:
-Wold-style-cast
#cppcore #goodpractice
Double-Checked Locking Pattern. Мотивация
#новичкам
Михаил на ретро предложил идею посмотреть в прошлое на определенную проблему и понять, как изменялись подходы к решению проблемы. Тут не прям сильно далеко пойдем и сильно много итераций будем рассматривать, но все же. Также были запросы на многопоточку и паттерны плюсовые. Собсна, все это комбинируя с большой темой статиков, начинаем изучать паттерн Блокировки с двойной проверкой.
Начнем с того, что в стародавние времена до С++11 у нас была довольно примитивная модель памяти, которая вообще не знала о существовании потоков. И не было вот этой гарантии для статических локальных переменных:
Поэтому раньше люди не могли писать такой простой код:
и надеяться на то, что объект будет создаваться потокобезопасно.
Самое простое, что можно здесь придумать - влепить замок и не париться.
У нас есть какая-то своя RAII обертка Lock над каким-то мьютексом(до С++11 ни std::mutex, ни std::lock_guard не существовало, приходилось велосипедить(ну или бустовать, кому как удобнее)).
Обратите внимание, как это работает. Статические указатели автоматически zero-инициализируются нулем, поэтому в начале inst_ptr равен NULL. Дальше нужно проверить, если указатель еще нулевой, то значит мы ничего не проинициализировали и нужно создать объект. И делать это должен один тред. Но куда поставить лок? На весь скоуп или только внутри условия на создание объекта?
Дело в том, что может получиться так, что несколько потоков одновременно войдут в условие. Но только один из них успешно возьмет лок. Создаст объект и отпустит мьютекс. Но другие потоки-то уже вошли в условие. И когда настанет их черед выполняться, то они просто будут пересоздавать объекты и мы получим бог знает какие сайдэффекты. Плюс утечку памяти, так как изначально созданные объект потеряется навсегда. Плюс получается, что наш синглтон не такой уж и сингл...
Именно поэтому замок должен стоять с самого начала, чтобы только один поток вошел в условие. И создал объект. А все остальные потоки будут просто пользоваться этим объектом, обходя условие.
Однако теперь возникает проблема. Нам, вообще говоря, этот замок нахрен не сдался после того, как мы создали объект. Захват и освобождение мьютекса - довольно затратные операции и не хотелось бы их каждый раз выполнять, когда мы просто хотим получить доступ к нашему объекту-одиночке. И было бы очень удобно перенести этот лок в условие. Но в текущей реализации это невозможно...
Здесь-то и приходит на помощь шаблон блокировки с двойной проверкой, о котором подробнее поговорим в следующих статьях.
Solve your problems. Stay cool.
#multitasking #cppcore #cpp11
#новичкам
Михаил на ретро предложил идею посмотреть в прошлое на определенную проблему и понять, как изменялись подходы к решению проблемы. Тут не прям сильно далеко пойдем и сильно много итераций будем рассматривать, но все же. Также были запросы на многопоточку и паттерны плюсовые. Собсна, все это комбинируя с большой темой статиков, начинаем изучать паттерн Блокировки с двойной проверкой.
Начнем с того, что в стародавние времена до С++11 у нас была довольно примитивная модель памяти, которая вообще не знала о существовании потоков. И не было вот этой гарантии для статических локальных переменных:
...
If control enters the declaration concurrently
while the variable is being initialized,
the concurrent execution shall wait for
completion of the initialization.
Поэтому раньше люди не могли писать такой простой код:
Singleton& GetInstance() {
static Singleton inst{};
return inst;
}
и надеяться на то, что объект будет создаваться потокобезопасно.
Самое простое, что можно здесь придумать - влепить замок и не париться.
class Singleton {
public:
static Singleton* instance() {
Lock lock;
if (inst_ptr == NULL) {
inst_ptr = new Singleton;
}
return inst_ptr;
}
private:
Singleton() = default;
static Singleton* inst_ptr;
};
У нас есть какая-то своя RAII обертка Lock над каким-то мьютексом(до С++11 ни std::mutex, ни std::lock_guard не существовало, приходилось велосипедить(ну или бустовать, кому как удобнее)).
Обратите внимание, как это работает. Статические указатели автоматически zero-инициализируются нулем, поэтому в начале inst_ptr равен NULL. Дальше нужно проверить, если указатель еще нулевой, то значит мы ничего не проинициализировали и нужно создать объект. И делать это должен один тред. Но куда поставить лок? На весь скоуп или только внутри условия на создание объекта?
Дело в том, что может получиться так, что несколько потоков одновременно войдут в условие. Но только один из них успешно возьмет лок. Создаст объект и отпустит мьютекс. Но другие потоки-то уже вошли в условие. И когда настанет их черед выполняться, то они просто будут пересоздавать объекты и мы получим бог знает какие сайдэффекты. Плюс утечку памяти, так как изначально созданные объект потеряется навсегда. Плюс получается, что наш синглтон не такой уж и сингл...
Именно поэтому замок должен стоять с самого начала, чтобы только один поток вошел в условие. И создал объект. А все остальные потоки будут просто пользоваться этим объектом, обходя условие.
Однако теперь возникает проблема. Нам, вообще говоря, этот замок нахрен не сдался после того, как мы создали объект. Захват и освобождение мьютекса - довольно затратные операции и не хотелось бы их каждый раз выполнять, когда мы просто хотим получить доступ к нашему объекту-одиночке. И было бы очень удобно перенести этот лок в условие. Но в текущей реализации это невозможно...
Здесь-то и приходит на помощь шаблон блокировки с двойной проверкой, о котором подробнее поговорим в следующих статьях.
Solve your problems. Stay cool.
#multitasking #cppcore #cpp11
Double-Checked Locking Pattern Classic
#опытным
Ядро идеи этого паттерна - тот факт, что решение из предыдущего поста неоптимально. Нам на самом деле нужно всего один раз взять замок для того, чтобы создать объект и потом не возвращаться к этом шагу. Если кто-то увидит, что наш указатель - ненулевой, то он даже не будет пытаться что-то делать и сразу вернется из функции.
Поэтому в паттерне блокировки с двойной проверкой, нулёвость указателя проверяется перед локом. Таким образом мы откидываем просадку производительности для подавляющего большинства вызова геттера синглтона. Однако у нас теперь остается узкое место - момент инициализации. И вот где появляется вторая проверка(всю обертку уже не буду писать для краткости).
Таким образом, даже если 2 потока войдут в первое условие и первый из них проинициализирует указатель, то второй поток будет вынужден проверить еще раз, можно ли ему создать объект. И грустный вернется из геттера, потому что ему нельзя.
Это классическая реализация, многие подписчики, думаю, видели ее. Однако от того, что она классическая, не следует, что она корректная.
Давайте посмотрим на вот эту строчку поближе:
Что здесь происходит? На самом деле происходят 3 шага:
1️⃣ Аллокация памяти под объект.
2️⃣ Вызов его конструктора на аллоцированной памяти.
3️⃣ Присваивание inst_ptr'у нового значения.
И вот мы, как наивные чукотские мальчики, думаем, что все эти 3 шага происходят в этом конкретном порядке. А вот фигушки! Компилятор, мать его ети. Иногда он может просто взять и переставить шаги 2 и 3 местами! И вот к чему это может привести.
Давайте посмотрим эквивалентный плюсовый код, когда компилятор переставил шаги:
Че здесь происходит. Здесь просто явно показаны шаги. С помощью operator new мы выделяем память(1 шаг), дальше присваиваем указатель на эту память inst_ptr'у(шаг 3). И в конце конструируем объект. И напомню, это не программист так пишет. Это эквивалентный код тому, что может сгенерировать компилятор.
И этот код совсем не эквивалентен тому, что было изначально. Потому что конструктор Singleton может кинуть исключение и очень важно, чтобы есть он это сделает, то inst_ptr останется нетронутым. А он как бы изменяется. Поэтому, в большинстве случаев, компилятору нельзя генерировать такой код. Но при определенных условиях, он может это сделать. Например, если докажет сам себе, что конструктор не может кинуть исключение. И вот тогда происходит magic.
Тред №1 входит в первое условие, берет лок и выполняет шаги 1 и 3 и потом засыпает по воле планировщика. И мы имеем состояние, когда указатель проинициализирован, а объекта на этой памяти еще нет(шаг 2 не выполнен).
Тред №2 входит в функцию, видит, что указатель ненулевой и возвращает его наружу. А внешний код потом берет и разыименовывает указатель с непроинициализированной памятью. Уупс. UB.
Что можно сделать? Вообще говоря, ничего. Если сам язык не подразумевает многопоточности, то компилятор даже не думает о таких штуках и с его точки зрения все валидно. Даже volatile предотвращает реордеринг инструкций в рамках только одного потока. Но мы же в многоядерной среде и там существуют совершенно другие эффекты, о которых "безпоточные" С и С++ в душе не знают. Напоминаю, что мы до сих пор в эре до С++11. Завтра чуть ближе посмотрим на конкретные проблемы, при которых мы сталкиваемся, находясь в многопоточном окружении.
Criticize your solutions. Stay cool.
#concurrency #cppcore #compiler #cpp11
#опытным
Ядро идеи этого паттерна - тот факт, что решение из предыдущего поста неоптимально. Нам на самом деле нужно всего один раз взять замок для того, чтобы создать объект и потом не возвращаться к этом шагу. Если кто-то увидит, что наш указатель - ненулевой, то он даже не будет пытаться что-то делать и сразу вернется из функции.
Поэтому в паттерне блокировки с двойной проверкой, нулёвость указателя проверяется перед локом. Таким образом мы откидываем просадку производительности для подавляющего большинства вызова геттера синглтона. Однако у нас теперь остается узкое место - момент инициализации. И вот где появляется вторая проверка(всю обертку уже не буду писать для краткости).
static Singleton* Singleton::instance() {
if (inst_ptr == NULL) {
Lock lock;
if (inst_ptr == NULL) {
inst_ptr = new Singleton;
}
}
return inst_ptr;
}
Таким образом, даже если 2 потока войдут в первое условие и первый из них проинициализирует указатель, то второй поток будет вынужден проверить еще раз, можно ли ему создать объект. И грустный вернется из геттера, потому что ему нельзя.
Это классическая реализация, многие подписчики, думаю, видели ее. Однако от того, что она классическая, не следует, что она корректная.
Давайте посмотрим на вот эту строчку поближе:
inst_ptr = new Singleton;
Что здесь происходит? На самом деле происходят 3 шага:
1️⃣ Аллокация памяти под объект.
2️⃣ Вызов его конструктора на аллоцированной памяти.
3️⃣ Присваивание inst_ptr'у нового значения.
И вот мы, как наивные чукотские мальчики, думаем, что все эти 3 шага происходят в этом конкретном порядке. А вот фигушки! Компилятор, мать его ети. Иногда он может просто взять и переставить шаги 2 и 3 местами! И вот к чему это может привести.
Давайте посмотрим эквивалентный плюсовый код, когда компилятор переставил шаги:
static Singleton* Singleton::instance() {
if (inst_ptr == NULL) {
Lock lock;
if (inst_ptr == NULL) {
inst_ptr = // step 3
operator new(sizeof(Singleton)); // step 1
new(inst_ptr) Singleton; // step 2
}
}
return inst_ptr;
}
Че здесь происходит. Здесь просто явно показаны шаги. С помощью operator new мы выделяем память(1 шаг), дальше присваиваем указатель на эту память inst_ptr'у(шаг 3). И в конце конструируем объект. И напомню, это не программист так пишет. Это эквивалентный код тому, что может сгенерировать компилятор.
И этот код совсем не эквивалентен тому, что было изначально. Потому что конструктор Singleton может кинуть исключение и очень важно, чтобы есть он это сделает, то inst_ptr останется нетронутым. А он как бы изменяется. Поэтому, в большинстве случаев, компилятору нельзя генерировать такой код. Но при определенных условиях, он может это сделать. Например, если докажет сам себе, что конструктор не может кинуть исключение. И вот тогда происходит magic.
Тред №1 входит в первое условие, берет лок и выполняет шаги 1 и 3 и потом засыпает по воле планировщика. И мы имеем состояние, когда указатель проинициализирован, а объекта на этой памяти еще нет(шаг 2 не выполнен).
Тред №2 входит в функцию, видит, что указатель ненулевой и возвращает его наружу. А внешний код потом берет и разыименовывает указатель с непроинициализированной памятью. Уупс. UB.
Что можно сделать? Вообще говоря, ничего. Если сам язык не подразумевает многопоточности, то компилятор даже не думает о таких штуках и с его точки зрения все валидно. Даже volatile предотвращает реордеринг инструкций в рамках только одного потока. Но мы же в многоядерной среде и там существуют совершенно другие эффекты, о которых "безпоточные" С и С++ в душе не знают. Напоминаю, что мы до сих пор в эре до С++11. Завтра чуть ближе посмотрим на конкретные проблемы, при которых мы сталкиваемся, находясь в многопоточном окружении.
Criticize your solutions. Stay cool.
#concurrency #cppcore #compiler #cpp11
Что опасного в многопоточке?
#новичкам
Монстры, морские чудовища, жуткие болезни... Все это снится разработчику, ломающему голову над проблемой в его многопоточном коде. Что же такого трудного для понимания и для отлавливания может произойти?
Одна из многих проблем - когерентность кэша. У нас есть много вычислительных юнитов. У каждого из них есть свой кэш. И все они шарят общее адресное пространство процесса. Кэши напрямую не связаны с другими вычислительными юнитами, только со своими(это про кэши низких уровней). В такой архитектуре нужно четко определить механизм, по которому изменения одного кэша станут видны другому ядру. Такие механизмы есть. Например, упрощенный вариант того, что сейчас есть - модель MESI. Непростая штука и мы пока не будем разбираться в деталях. Важно вот что: на процесс, охватывающий промежуток от изменения одной кэш линии до того, как эти изменения станут доступны другому ядру, тратится время. И это не атомарная операция! То есть нет такого, что при каждом изменении кэш линии информация об этом инциденте моментально доходит до других юнитов и они тут же первым приоритетом подгружают новое значение. Это очень неэффективно. Поэтому может случиться такая ситуация, при которой переменная в одном кэше процессора уже изменилась, а в другом кэше еще осталась ее старая копия, которая используется другим процессором. Это и есть одна из граней проблемы когерентности кэша.
Если с одной операцией-то тяжко, то еще более bizarre ситуация становится, когда мы начинаем рассматривать две связанных операции. Представим себе такую картину:
Функция fun выполняется в каком-то потоке и и меняет значения переменной. Логично, что в начале выполняется создание объекта, а потом присвоение указателя. Но это актуально лишь для этого потока и так это видит соотвествующее ядро. Мы ведь в многопоточной среде, здесь убивают...
Может произойти так, что данные в другой процессор подтянутся в обратном порядке. То есть в начале появится инициализированный указатель, указывающий на какую-то память, а потом подтянется инфа об созданном на этой памяти объекте. Вот и получается, что этот другой поток может сделать проверку:
И код войдет в условие, потому что указатель ненулевой. Но память по этому указателю будет еще не инициализирована. А это, друзья, наше любимое UB.
И это в точности то, что может происходить с нашим беднягой синглтоном! Если вы думаете, что lock на мьютексе вас спасет, то нет, не спасет!
Да, лок подразумевает барьеры памяти и при unlock'e изменения флашатся. Но на незащищенном чтении-то они подтягиваются без барьеров! Это был небольшой спойлер для шарящих за барьеры. О них не сегодня.
Именно поэтому даже если мы все вместе обмажемсямаслом и начнем бороться volatile и будем везде его пихать, то это все равно не поможет. Жонглирование указателями тоже. Тут проблема даже не в том, что компилятор как-то переставляет инструкции. Помимо всего прочего и сам процессор может менять местами инструкции для большей производительности. На такие штуки мы уже никак не влияем. Просто смиритесь с тем, что природа многопоточного мира такая и с этим надо уметь работать и решать такие проблемы.
Завтра как раз об этом и поговорим.
Be able to work in multitasking mode. Stay cool.
#concurrency #cppcore
#новичкам
Монстры, морские чудовища, жуткие болезни... Все это снится разработчику, ломающему голову над проблемой в его многопоточном коде. Что же такого трудного для понимания и для отлавливания может произойти?
Одна из многих проблем - когерентность кэша. У нас есть много вычислительных юнитов. У каждого из них есть свой кэш. И все они шарят общее адресное пространство процесса. Кэши напрямую не связаны с другими вычислительными юнитами, только со своими(это про кэши низких уровней). В такой архитектуре нужно четко определить механизм, по которому изменения одного кэша станут видны другому ядру. Такие механизмы есть. Например, упрощенный вариант того, что сейчас есть - модель MESI. Непростая штука и мы пока не будем разбираться в деталях. Важно вот что: на процесс, охватывающий промежуток от изменения одной кэш линии до того, как эти изменения станут доступны другому ядру, тратится время. И это не атомарная операция! То есть нет такого, что при каждом изменении кэш линии информация об этом инциденте моментально доходит до других юнитов и они тут же первым приоритетом подгружают новое значение. Это очень неэффективно. Поэтому может случиться такая ситуация, при которой переменная в одном кэше процессора уже изменилась, а в другом кэше еще осталась ее старая копия, которая используется другим процессором. Это и есть одна из граней проблемы когерентности кэша.
Если с одной операцией-то тяжко, то еще более bizarre ситуация становится, когда мы начинаем рассматривать две связанных операции. Представим себе такую картину:
struct Class {
Class(int a, int b, int c) : x{a}, y{b}, z{c} {}
int x;
int y;
int z;
};
Class * shared;
void fun() {
shared = new Class{1, 2, 3};
}
Функция fun выполняется в каком-то потоке и и меняет значения переменной. Логично, что в начале выполняется создание объекта, а потом присвоение указателя. Но это актуально лишь для этого потока и так это видит соотвествующее ядро. Мы ведь в многопоточной среде, здесь убивают...
Может произойти так, что данные в другой процессор подтянутся в обратном порядке. То есть в начале появится инициализированный указатель, указывающий на какую-то память, а потом подтянется инфа об созданном на этой памяти объекте. Вот и получается, что этот другой поток может сделать проверку:
if (shared)
// do smt with object
И код войдет в условие, потому что указатель ненулевой. Но память по этому указателю будет еще не инициализирована. А это, друзья, наше любимое UB.
И это в точности то, что может происходить с нашим беднягой синглтоном! Если вы думаете, что lock на мьютексе вас спасет, то нет, не спасет!
Да, лок подразумевает барьеры памяти и при unlock'e изменения флашатся. Но на незащищенном чтении-то они подтягиваются без барьеров! Это был небольшой спойлер для шарящих за барьеры. О них не сегодня.
Именно поэтому даже если мы все вместе обмажемся
Завтра как раз об этом и поговорим.
Be able to work in multitasking mode. Stay cool.
#concurrency #cppcore
Рабочий Double-Checked Locking Pattern
#опытным
Мы уже довольно много говорим о нем и его проблемах. Давайте же сегодня обсудим решение.
Общее решение для проблем с когерентностью кэшей - использование барьеров памяти. Это инструкции, которые ограничивают виды переупорядочиваний операций, которые могут возникнуть при чтении и записи шареной памяти в многопроцессорной системе.
Даже просто применительно к этому паттерну коротко, но в деталях разобрать работу барьеров - задача нереальная, потому что барьеры памяти, сами по себе, не самая простая тема для понимания. Поэтому сегодня ограничимся лишь поверхностными пояснениями.
Вот как выглядела бы более менее работающая реализация паттерна блокировки с двойной проверкой до нашей эры(до С++11). Так как в то время в языке и стандартной библиотеке не было ничего, что связано с потоками, то для барьеров приходилось использовать platform-specific инструкции, часто с ассемблерными вставками.
Acquire барьер предотвращает переупорядочивание любого чтения, которое находится сверху от него, с любыми чтением/записью, которые следуют после барьера. Одна из проблем кода без барьеров: мы можем считать ненулевой указатель в tmp, но при этом результат операции инициализации объекта к нам еще не подтянется. Мы вернем из геттера неинициализированный указатель, что UB. Именно для предотвращения такого эффекта, в данном случае такой барьер нужен сверху для того, чтобы мы подтянули инициализированный объект из кэша другого ядра в случае, если мы все-таки считали ненулевой указатель.
Плюс он еще нужен, чтобы мы именно первой инструкцией считывали указатель и процессор не менял местами эту операцию со следующими. Может произойти так, что процессор поставит проверки всех условий перед записью указателя в tmp и это приведет к повторной инициализации синглтона.
Release барьер предотвращает переупорядочивание любого чтения/записи, которое находится сверху от него, с любой записью, которые следуют после барьера. Здесь также 2 составляющие. Первая: предотвращает переупорядочивание иницализации синглтона с присваиванием его указателя к
Объяснения не самые подробные и точные, но опять же, не было такой цели. Кто понимает - поймет, а кто не понимает - ждите статьи по модели памяти)
И вот как выглядела бы реализация этого паттерна на современном С++, если бы статические локальные переменные не гарантировали бы потокобезопасной инициализации:
Здесь мы только на всякий случай обернули указатель синглтона в атомик указатель, чтобы полностью быть так сказать в lock-free контексте. Барьеры на своих местах, а для залочивания мьютекса используем стандартный std::lock_guard с CTAD из 17-х плюсов.
Ставьте шампусик, если вам заходят такие посты с многопоточкой. Думаю, редко где в ру сегменте об этом пишут.
Establish your barriers. Stay cool.
#concurrency #cpp11 #cpp17
#опытным
Мы уже довольно много говорим о нем и его проблемах. Давайте же сегодня обсудим решение.
Общее решение для проблем с когерентностью кэшей - использование барьеров памяти. Это инструкции, которые ограничивают виды переупорядочиваний операций, которые могут возникнуть при чтении и записи шареной памяти в многопроцессорной системе.
Даже просто применительно к этому паттерну коротко, но в деталях разобрать работу барьеров - задача нереальная, потому что барьеры памяти, сами по себе, не самая простая тема для понимания. Поэтому сегодня ограничимся лишь поверхностными пояснениями.
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance;
... // insert acquire memory barrier
if (tmp == NULL) {
Lock lock;
tmp = m_instance;
if (tmp == NULL) {
tmp = new Singleton;
... // insert release memory barrier
m_instance = tmp;
}
}
return tmp;
}
Вот как выглядела бы более менее работающая реализация паттерна блокировки с двойной проверкой до нашей эры(до С++11). Так как в то время в языке и стандартной библиотеке не было ничего, что связано с потоками, то для барьеров приходилось использовать platform-specific инструкции, часто с ассемблерными вставками.
Acquire барьер предотвращает переупорядочивание любого чтения, которое находится сверху от него, с любыми чтением/записью, которые следуют после барьера. Одна из проблем кода без барьеров: мы можем считать ненулевой указатель в tmp, но при этом результат операции инициализации объекта к нам еще не подтянется. Мы вернем из геттера неинициализированный указатель, что UB. Именно для предотвращения такого эффекта, в данном случае такой барьер нужен сверху для того, чтобы мы подтянули инициализированный объект из кэша другого ядра в случае, если мы все-таки считали ненулевой указатель.
Плюс он еще нужен, чтобы мы именно первой инструкцией считывали указатель и процессор не менял местами эту операцию со следующими. Может произойти так, что процессор поставит проверки всех условий перед записью указателя в tmp и это приведет к повторной инициализации синглтона.
Release барьер предотвращает переупорядочивание любого чтения/записи, которое находится сверху от него, с любой записью, которые следуют после барьера. Здесь также 2 составляющие. Первая: предотвращает переупорядочивание иницализации синглтона с присваиванием его указателя к
m_instance
. Это дает четкий порядок: в начале создаем объект, а потом m_instance
указываем на него. Вторая гарантирует нам правильный порядок "отправки" изменений из текущего треда в точки назначения.Объяснения не самые подробные и точные, но опять же, не было такой цели. Кто понимает - поймет, а кто не понимает - ждите статьи по модели памяти)
И вот как выглядела бы реализация этого паттерна на современном С++, если бы статические локальные переменные не гарантировали бы потокобезопасной инициализации:
std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance.load(std::memory_order_relaxed);
std::atomic_thread_fence(std::memory_order_acquire);
if (tmp == nullptr) {
std::lock_guard lock(m_mutex);
tmp = m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton;
std::atomic_thread_fence(std::memory_order_release);
m_instance.store(tmp, std::memory_order_relaxed);
}
}
return tmp;
}
Здесь мы только на всякий случай обернули указатель синглтона в атомик указатель, чтобы полностью быть так сказать в lock-free контексте. Барьеры на своих местах, а для залочивания мьютекса используем стандартный std::lock_guard с CTAD из 17-х плюсов.
Ставьте шампусик, если вам заходят такие посты с многопоточкой. Думаю, редко где в ру сегменте об этом пишут.
Establish your barriers. Stay cool.
#concurrency #cpp11 #cpp17
Ассемблер инициализации статических локальных переменных
#опытным
Пример из предыдущего поста - рабочая версия паттерна. Однако, нам, вообще говоря, можно всего этого не писать. Ведь начиная с С++11 нам гарантируют тред-сэйф инициализацию статических локальных переменных и можно просто писать:
Мы посмотрели, как вся защита может выглядеть на уровне С++ кода. Но в примере сверху никакой защиты на этом уровне нет. А это значит, что она лежит ниже, на уровне машинных инструкций. Которые мы можем с горем-пополам прочитать в виде ассемблера.
Сейчас будет очень страшно, но я попытался оставить самые важные куски и места и опустил неважное. Показываю ассемблер под x86-64, сгенерированный gcc.
Так как код оперирует объектом, а не указателем, то и в ассемблере это отражено. Но да не особо это важно. Сейчас все поймете. Для удобства обращения к коду, пометил строчки номерами.
Итак, мы входим в функцию. И тут же на первой строчке у нас появляется строжевая гвардия для переменной
На метке .L19 мы берем лок с помощью вызова __cxa_guard_acquire, которая используется для залочивания мьютексов. И снова проверяем переменную-гард на пустоту(напоминаем себе, что она в eax загружена), если до сих пор она нулевая, то прыгаем в .L20. Если уже не ноль, то есть переменная инициализирована, то проваливаемся в .L9, где кладем созданную переменную в регистр возврата значения на 9-й строчке и выходим из функции(10 и 11). Это была вторая проверка
На метке .L20 мы на 12-й строчке кладем наш неинициализированный синглтон в регистр для последующей обработки, а именно для конструирования объекта. На 13-й строчке кладем адрес гарда в регистр, чтобы чуть позже записать туда ненулевое значение aka синглтон инициализирован. Далее мы отпускаем лок с помощью __cxa_guard_release, делаем все необходимые завершающие действия и выходим из функции.
Повторю, что тут много всего пропущено для краткости и наглядности, но вы уже сейчас можете сравнить этот ассемблер с плюсовым кодом из вчерашнего поста и сразу же заметите практически однозначное соответствие. Именно так и выглядит DCLP на ассемблере.
Стоит еще раз обратить внимание на то, что __cxa_guard_acquire и __cxa_guard_release - это не барьеры памяти! Это захват мьютекса. Барьеры памяти напрямую здесь не нужны. Нам важно только защитить гард-переменную для синглтона, потому что проверяется только она.
Для пытливых читателей оставлю ссылочку на годболт с примером, чтобы желающие могли поиграться.
Dig deeper. Stay cool.
#concurrency #cppcore
#опытным
Пример из предыдущего поста - рабочая версия паттерна. Однако, нам, вообще говоря, можно всего этого не писать. Ведь начиная с С++11 нам гарантируют тред-сэйф инициализацию статических локальных переменных и можно просто писать:
Singleton& Singleton::getInstance() {
static Singleton instance;
return instance;
}
Мы посмотрели, как вся защита может выглядеть на уровне С++ кода. Но в примере сверху никакой защиты на этом уровне нет. А это значит, что она лежит ниже, на уровне машинных инструкций. Которые мы можем с горем-пополам прочитать в виде ассемблера.
Сейчас будет очень страшно, но я попытался оставить самые важные куски и места и опустил неважное. Показываю ассемблер под x86-64, сгенерированный gcc.
Singleton::getInstance():
1 movzbl guard variable for Singleton::getInstance()::instance(%rip), %eax
2 testb %al, %al
3 je .L19
4 movl $Singleton::getInstance()::instance, %eax
5 ret
.L19:
...
6 call __cxa_guard_acquire
7 testl %eax, %eax
8 jne .L20
.L9:
9 movl $Singleton::getInstance()::instance, %eax
10 popq %rbx
11 ret
.L20:
12 movl $Singleton::getInstance()::instance, %esi
{Constructor}
13 movl $guard variable for Singleton::getInstance()::instance, %edi
14 call __cxa_guard_release
{safe instance and return}
Так как код оперирует объектом, а не указателем, то и в ассемблере это отражено. Но да не особо это важно. Сейчас все поймете. Для удобства обращения к коду, пометил строчки номерами.
Итак, мы входим в функцию. И тут же на первой строчке у нас появляется строжевая гвардия для переменной
instance
. Гвардия защищена барьером памяти и она показывает, инициализирована уже instance
или нет. Так как мы без указателей, то вместо загрузки указателя и установки барьера памяти тут просто происходит загрузка гард-переменной для instance
в регистр eax. Дальше на второй строчке мы проверяем, была ли инициализирована instance
. al - это младший байт регистра eax. Соотвественно, если al - ноль, то инструкция testb выставляет zero-flag и в условном прыжке на 3-ей строчке мы прыгаем по метке. Если al - не ноль, то наш синглтон уже инициализирован и мы можем вернуть его из функции. Получается, что это наша первая проверка на ноль.На метке .L19 мы берем лок с помощью вызова __cxa_guard_acquire, которая используется для залочивания мьютексов. И снова проверяем переменную-гард на пустоту(напоминаем себе, что она в eax загружена), если до сих пор она нулевая, то прыгаем в .L20. Если уже не ноль, то есть переменная инициализирована, то проваливаемся в .L9, где кладем созданную переменную в регистр возврата значения на 9-й строчке и выходим из функции(10 и 11). Это была вторая проверка
На метке .L20 мы на 12-й строчке кладем наш неинициализированный синглтон в регистр для последующей обработки, а именно для конструирования объекта. На 13-й строчке кладем адрес гарда в регистр, чтобы чуть позже записать туда ненулевое значение aka синглтон инициализирован. Далее мы отпускаем лок с помощью __cxa_guard_release, делаем все необходимые завершающие действия и выходим из функции.
Повторю, что тут много всего пропущено для краткости и наглядности, но вы уже сейчас можете сравнить этот ассемблер с плюсовым кодом из вчерашнего поста и сразу же заметите практически однозначное соответствие. Именно так и выглядит DCLP на ассемблере.
Стоит еще раз обратить внимание на то, что __cxa_guard_acquire и __cxa_guard_release - это не барьеры памяти! Это захват мьютекса. Барьеры памяти напрямую здесь не нужны. Нам важно только защитить гард-переменную для синглтона, потому что проверяется только она.
Для пытливых читателей оставлю ссылочку на годболт с примером, чтобы желающие могли поиграться.
Dig deeper. Stay cool.
#concurrency #cppcore
Named Constructor Idiom
Конструкторы - вещь хорошая, но довольно ограниченная. Если вы хотите создать объект класса ТяжеленнаяФиговина, то логично было бы ввести разные конструкторы для разных систем измерения. Ну например, чтобы фиговина могла создаваться из киллограммов и из фунтов. Но это невозможно.
Дело в том, что конструктор класса - такая же функция, как и все остальные. У него есть имя(имя класса), список аргументов(включая неявный this) и пустое возвращаемое значение. В языке С++ конструкторы вообще ничего не возвращают, но они так или иначе реализованы на обычных ассемблерных функциях, а они имеют все эти обязательные характеристики.
А раз это функция и неизменяемым именем, то различать разные конструкторы мы можем только с помощью разного списка параметров.
И это становится проблемой, когда конструкторов много и их уже сложно отличать друг от друга, либо как в нашем примере с ТяжелойФиговиной мы просто не можем два конструктра с одинаковым списком параметров, но эти параметры будут иметь разное назначение.
Допустим, что с фиговиной помогут справиться strong typedefs. Но со сложностью различий конструкторов для пользователя они не помогут. А вот что может помочь.
Named Constructor Idiom. Давайте дадим имена конструкторам!
Точнее мы немного схитрим. Добавим именные статические функции-фабрики, которые и будут конструировать наши объекты, и переместим все конструкторы в private секцию.
Покажу на примере фиговины, чтобы было по-проще и по-короче
Да, придется немного букав пописать, но для столкнувшихся с такой проблемой это - выход. Можно еще поиграться с возвращаемым значением. Например, сделать его уникальным указателем. Но это уже детали.
Make convenient interfaces. Stay cool.
#design
Конструкторы - вещь хорошая, но довольно ограниченная. Если вы хотите создать объект класса ТяжеленнаяФиговина, то логично было бы ввести разные конструкторы для разных систем измерения. Ну например, чтобы фиговина могла создаваться из киллограммов и из фунтов. Но это невозможно.
Дело в том, что конструктор класса - такая же функция, как и все остальные. У него есть имя(имя класса), список аргументов(включая неявный this) и пустое возвращаемое значение. В языке С++ конструкторы вообще ничего не возвращают, но они так или иначе реализованы на обычных ассемблерных функциях, а они имеют все эти обязательные характеристики.
А раз это функция и неизменяемым именем, то различать разные конструкторы мы можем только с помощью разного списка параметров.
И это становится проблемой, когда конструкторов много и их уже сложно отличать друг от друга, либо как в нашем примере с ТяжелойФиговиной мы просто не можем два конструктра с одинаковым списком параметров, но эти параметры будут иметь разное назначение.
Допустим, что с фиговиной помогут справиться strong typedefs. Но со сложностью различий конструкторов для пользователя они не помогут. А вот что может помочь.
Named Constructor Idiom. Давайте дадим имена конструкторам!
Точнее мы немного схитрим. Добавим именные статические функции-фабрики, которые и будут конструировать наши объекты, и переместим все конструкторы в private секцию.
Покажу на примере фиговины, чтобы было по-проще и по-короче
struct HeavyThing {
static HeavyThing ConstructFromKilos(float kilos) {
return HeavyThing(kilos);
}
static HeavyThing ConstructFromPounds(float pounds) {
return HeavyThing(0,453592 * pounds);
}
private:
HeavyThing(float kilos) : kilos_{kilos} {}
float kilos_;
};
int main() {
HeavyThing a = HeavyThing::ConstructFromKilos(100500.0);
HeavyThing b = HeavyThing::ConstructFromPounds(12345678.0);
}
Да, придется немного букав пописать, но для столкнувшихся с такой проблемой это - выход. Можно еще поиграться с возвращаемым значением. Например, сделать его уникальным указателем. Но это уже детали.
Make convenient interfaces. Stay cool.
#design