Задача OpenSSL - опубликовать релиз и иметь инструкцию по сборке, с ней они справились. Как подключить в ваш проект - это ваша головная боль, OpenSSL не должен пытаться усидеть на как минимум четырёх стульях: CMake, meson, bazel и autotools.
Патч != система сборки. Рецепт != система сборки. Даже при наличии CMakeLists.txt нужен рецепт. Патчи существуют в т.ч. для того, чтобы подогнать установку под свои представления о прекрасном (installation layout, протягивание флаги компиляции и т.п.) Ну и роль MS во всём этом скорее проревьювить изменения и нажать кнопку merge, сами правки вносят обычные люди и те самые компании, о которых вы не знаете.
Это ещё один повод спросить, почему в процессе разработки рецептов для этих библиотек (они чудовищно сложны) не был создан CMakeLists.txt
Потому что никому (кроме особо упоротых) не хочется поддерживать свою сисетму сборки по множеству причин, начиная от обязанности отслеживать абсолютно все изменения в оригинальной системе сборки и заканчивая всякими аудитами безопасности.
Т.е. Вы на проекте под Astra Linux 1.7.x используете компилятор GCC 8.3.0
Нет конечно. Я с самого начала написал: чтобы приложение работало под астрой не обязательно собирать его под астрой. Приложение собирается GCC 14, в котором есть практически полная поддержка C++20.
Ну, если один человек участвует параллельно в разработке "несколько сотен библиотек" - это нездоровая ситуация.
Я нигде не писал, что занимаюсь разработкой в одиночку. Конечно же это не так.
но где-то читал мнение профессионального игрового разработчика (эксперта), который писал что-то вроде критики новых стандартов C++
У меня тоже много предъяв к некоторым фичам новых стандартов, но их можно просто не использовать. К экспертам в C++ стоит относиться настороженно, потому что они зачастую коммерческой разработкой и не занимаются.
почему игрострой всё ещё остаётся на старых его стандартах
Статью я разумееся читал, но в ней пишут не про то, что геймдев сидит на старых компиляторах, а про то, что в геймдеве очень консервативный подход к использованию фич новых стандартов. Что в принципе логично - core language развивается медленно, STL используется по минимуму.
Если Вы C++-разработчик, то, видимо, у Вас просто ещё не было такого опыта вынужденной поддержки "старых" ОС или дистрибутивов. Ну, всё можно наработать (по необходимости, разумеется).
Приложение, над которым я работаю, запускается на любом линуксе с glibc >= 2.17 (в т.ч. и Астра 1.7), при этом в нём уже несколько лет активно используется C++20. На всякий случай: это не один бинарник, это несколько сотен библиотек, половина из которых сторонние. Так что я уже навидался разного. И добиться этого не так уж и сложно.
Кто-то и на более старых стандартах пишет. Где-то проблемы с кодовой базой (которая писалась ещё с 90-х), а где-то предпочитают стандарт C++11 не без оснований (например, в контексте скорости, оптимизации и прочих причуд). У всех разные ситуации когда тот или иной стандарт использовать.
Ну Бог им судья. Не вижу причин не использовать новые стандарты. Если не позволяет руководство - это нездоровая ситуация. Если проблемы в коде - это нездоровая ситуация. Если завербовала секта свидетелей более лучших оптимизаций на старых стандартах - это тоже нездоровая ситуация.
Так я и говорю, что это плохой пример, потому что искусственное ограничение. С таким же успехом можно было написать RHEL7 с его GCC 4.8, но это же не повод в 2025 году оставаться на C++11 (и ожидать от новых библиотек, что они тоже будут его поддерживать)?
В chromite недавно завезли поддержку расширений. Первым делом порезал всю "не рекламу" на Хабре.
Что? Строка со счётчиком ссылок в стандартном C++? Знакомьтесь: std::runtime_error.
Вы что, cout не заметили? /s
Они и open source релизы делают, правда с задержкой в год. 31 октября вышла версия 5.15.18.
Игнорировать атрибуции - не по-джентльменски.
Задача OpenSSL - опубликовать релиз и иметь инструкцию по сборке, с ней они справились. Как подключить в ваш проект - это ваша головная боль, OpenSSL не должен пытаться усидеть на как минимум четырёх стульях: CMake, meson, bazel и autotools.
Патч != система сборки. Рецепт != система сборки. Даже при наличии CMakeLists.txt нужен рецепт.
Патчи существуют в т.ч. для того, чтобы подогнать установку под свои представления о прекрасном (installation layout, протягивание флаги компиляции и т.п.)
Ну и роль MS во всём этом скорее проревьювить изменения и нажать кнопку merge, сами правки вносят обычные люди и те самые компании, о которых вы не знаете.
Эмм... А обновляться оно само будет?
Можете не представлять, а увидеть воочию: https://github.com/microsoft/vcpkg/commits/master/ports/openssl
Согласен, поменять номер версии и хэш архива с исходниками - это очень сложно.
Потому что никому (кроме особо упоротых) не хочется поддерживать свою сисетму сборки по множеству причин, начиная от обязанности отслеживать абсолютно все изменения в оригинальной системе сборки и заканчивая всякими аудитами безопасности.
vcpkg install openssl opusИ правда, хотя не все компиляторы такие умные (осуждающе смотрю на MSVC).
emplace_back - шаблонная функция, поэтому на каждый тип будет генерироваться новая функция.
Всё понятно.
Нет конечно. Я с самого начала написал: чтобы приложение работало под астрой не обязательно собирать его под астрой. Приложение собирается GCC 14, в котором есть практически полная поддержка C++20.
Я нигде не писал, что занимаюсь разработкой в одиночку. Конечно же это не так.
У меня тоже много предъяв к некоторым фичам новых стандартов, но их можно просто не использовать. К экспертам в C++ стоит относиться настороженно, потому что они зачастую коммерческой разработкой и не занимаются.
Статью я разумееся читал, но в ней пишут не про то, что геймдев сидит на старых компиляторах, а про то, что в геймдеве очень консервативный подход к использованию фич новых стандартов. Что в принципе логично - core language развивается медленно, STL используется по минимуму.
Приложение, над которым я работаю, запускается на любом линуксе с glibc >= 2.17 (в т.ч. и Астра 1.7), при этом в нём уже несколько лет активно используется C++20. На всякий случай: это не один бинарник, это несколько сотен библиотек, половина из которых сторонние. Так что я уже навидался разного. И добиться этого не так уж и сложно.
Ну Бог им судья. Не вижу причин не использовать новые стандарты. Если не позволяет руководство - это нездоровая ситуация. Если проблемы в коде - это нездоровая ситуация. Если завербовала секта свидетелей более лучших оптимизаций на старых стандартах - это тоже нездоровая ситуация.
Так я и говорю, что это плохой пример, потому что искусственное ограничение. С таким же успехом можно было написать RHEL7 с его GCC 4.8, но это же не повод в 2025 году оставаться на C++11 (и ожидать от новых библиотек, что они тоже будут его поддерживать)?
Смысл тогда был приплетать астру с её древним компилятором?
Ну вы же реализовали алгоритмы перевода строки в разные регистры, вот я и пытаюсь понять для кого. Или это "чтобы было"?
Ок, какие проекты, в которых есть перевод строк в верхний регистр, устроит использование
std::towupper, которая иногда будет неправильно работать?