fix typo

runtime/static_initialization_order_fiasco.md

@@ -191,9 +191,9 @@ g++ -std=c++17 -o test2 logger.cpp main.cpp
 
 ----------
 
-В этом примере очень злобная ошибка с нарушение порядка инициализации статических объектов. C++11 гарантирует, что объекты `std::cin`, `std::cout`, `std::cerr` и их «широкие» аналоги будут инициализированы ДО любого статического объекта, объявленного в вашем файле, ТОЛЬКО ЕСЛО заголовок `<iostream>` подключен ПЕРЕД объявлением ваших объектов. Достигается это в глубинах `<iostream>` созданием статического объекта `std::ios_base::Init`. До C++11 гарантий не было. Темные времена.
+В этом примере очень злобная ошибка с нарушение порядка инициализации статических объектов. C++11 гарантирует, что объекты `std::cin`, `std::cout`, `std::cerr` и их «широкие» аналоги будут инициализированы ДО любого статического объекта, объявленного в вашем файле, ТОЛЬКО ЕСЛИ заголовок `<iostream>` подключен ПЕРЕД объявлением ваших объектов. Достигается это в глубинах `<iostream>` созданием статического объекта `std::ios_base::Init`. До C++11 гарантий не было. Темные времена.
 
 В своей заботе о минимизации зависимостей и размере обработанных препроцессором исходников (или просто последовав совету линтера), вы не включили `iostream` в интерфейсный заголовок библиотеки, но использовали его в реализации. Пользователь, не знающий об этом, получает проблемы. Не самое удачное решение.
 
 Объекты стандартных потоков не единственная возможность для подобных ошибок. Любая библиотека, использующая глобальные статические объекты, не позаботивщаяся об их инициализации ДО любых действий пользователя — потенциальный источник проблем.
-Если вы автор библиотеки, внимательнее относитесь к проектированию ее интерфейса. В C++ он не ограничивается только лишь сигнатурами функций и описанием классов.
+Если вы автор библиотеки, внимательнее относитесь к проектированию ее интерфейса. В C++ он не ограничивается только лишь сигнатурами функций и описанием классов.