Это ещё один повод спросить, почему в процессе разработки рецептов для этих библиотек (они чудовищно сложны) не был создан 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 (и ожидать от новых библиотек, что они тоже будут его поддерживать)?
Потому что никому (кроме особо упоротых) не хочется поддерживать свою сисетму сборки по множеству причин, начиная от обязанности отслеживать абсолютно все изменения в оригинальной системе сборки и заканчивая всякими аудитами безопасности.
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, которая иногда будет неправильно работать?Я вам секрет открою, чтобы приложение работало под астрой не обязательно собирать его под астрой.
В каких случаях нужна нестрогая работа с юникодом?
Вообще-то всё правильно было, вы просто заменили явное приведение signed -> unsigned неявным.
Юлия Якубеня уронила отварную сосиску
А ведь кроме Астры есть ещё АльтерОС, который до начала этого года был клоном CentOS 7. И люди на нём всё ещё сидят...
Реклама в видеопотоке будет палиться по появлению всяких кнопок для перехода/заказа/скачивания и т.п.
Ну и на кой эта статья в хабе C++?
Вы только что scope_exit
Я вас конечно поздравляю, но это свинство.
Скрытый текст