Т.е. Вы на проекте под 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 (и ожидать от новых библиотек, что они тоже будут его поддерживать)?
Читаю-читаю про употребление колючек conan'а, думаю ну вот сейчас автор наконец напишет "а давайте теперь попробуем vcpkg" но вот что-то не написал и продолжил употреблять колючки и делать какие-то выводы :(
Если в наличии есть C++20, то подход из статьи https://dfrib.github.io/a-foliage-of-folly/ мне кажется проще и выразительнее. Кстати никакой из встреченных мной способов не умеет работать с битовыми полями (потому что нельзя взять адрес на такое поле), так что параноики могут использовать это для защиты от таких трюков (но вам не защититься от тех, кто эксплуатирует ODR мухахахаха)!
Нет конечно. Я с самого начала написал: чтобы приложение работало под астрой не обязательно собирать его под астрой. Приложение собирается 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
Я вас конечно поздравляю, но это свинство.
Скрытый текст
Читаю-читаю про употребление колючек conan'а, думаю ну вот сейчас автор наконец напишет "а давайте теперь попробуем vcpkg" но вот что-то не написал и продолжил употреблять колючки и делать какие-то выводы :(
Да, видимо проморгал.
Готовое решение тоже указано в статье: https://github.com/dfrib/accessprivate
Если в наличии есть C++20, то подход из статьи https://dfrib.github.io/a-foliage-of-folly/ мне кажется проще и выразительнее.
Кстати никакой из встреченных мной способов не умеет работать с битовыми полями (потому что нельзя взять адрес на такое поле), так что параноики могут использовать это для защиты от таких трюков (но вам не защититься от тех, кто эксплуатирует ODR мухахахаха)!
Ну то есть писать шлак, чтобы его же потом и минусовать.
Какой-то поток сознания и героическая борьба против чтения документации. https://doc.qt.io/qt-6/custom-types.html