У того, что в стандарте закрепят byte == 8bit есть ещё неприятный момент для таких плформ. std::byte и char типы на этих платформах перестанут подпадать под стандарт, и начнутся проблемы с placement new и использовании std::byte в принципе :(
Комитет как всегда в своем репертуаре. Принципиально делают так чтобы было невозможно использовать без костылей и не наступая на грабли.
Тут вопрос в переносимости фичи. С атрибутами хотят позволить работать, но это одно из самых различающихся мест в фронтенде имеющихся компиляторах. Поэтому выбор был между "рефлексией в C++26 без атриботов" и "рефлексией с атрибутами незивестно когда"
^^ выглядит ужасно. Символ ` (обратный апостроф) не используется в С++ могли бы его использовать.
На моём экране он практически не отличим от одинарной кавычки :(
class Foo::Bar; // когда это будет работать?
Когда вы напишите предложение и реализуете прототип в компиляторе. Или если вы найдёте кого-то, кто захочет этим заниматься вместо вас.
А если размер векторного регистра в compile time неизвестен (скажем, ARM SVE) - будет ли size() вычисляться динамически (и насколько хорошо в целом std::simd такое поддерживает) ?
Вот в RISC-V аналогичная ситуация. Там размер регистра получается вызовом рантайм команды. В текущей версии стандарта size() всегда известен на этапе компиляции
Можно ли с std::simd написать код без явного вспомогательного скалярного цикла, чтобы дать компилятору возможность этим воспользоваться?
Думаю да. Как минимум можно проинициализировать std::simd нулями, докопировать оставшуюся часть в simd переменную и выполнить команду. Маски тоже поддерживаются
Модули хотят очень многие вендоры - возможность ускорить сборку в 3-10 раз, это очень крутое преимущество.
Но модули затрагивают сразу очень много различных частей языка, что и усложняет их внедрение и разработку:
компилятор - новый синтаксис, новое поведение с сериализацией внутреннего представления, немереное количество проблем с краевыми случаями
оптимизатор - новые области видимости позволяют новые оптимизации
линкер (или его аналог) - участвует при формировании файла модуля
сборочные тулчейны - они должны автоматически обнаруживать зависимости исходников от модуля
препроцессор - нужен режим для тулчейнов, для обнаружения модулей (порой делается отдельной утилитой)
ABI - появляются сущности, "прикреплённые" к модулю
стандартная библиотека - большая работа по созданию модуля std и его тестированию (макросы больше не экспортируются, модуль должен нормально работать с include из стандартной библиотеки)
Умножьте всё это на 2 (модули же работают в двух режимах: import "header" и import module), а для MSVC умножьте ещё на 2 (IDE использует другой компиляторный фронтенд для подсветки синтаксиса и подсказок) :-(
Но при этом придётся подменять функцию освобождения памяти исключения. А в libc++ runtime это сделать нельзя, в одном месте эта функция заинлайнивается в самом libc++ runtime. Так что возможно что не получится
Конечно коды возврата. Авторы Go и Rust могут только подтвердить
Python, C#, Java, JS и многие другие языки программирования с вами не согласятся. Да и в Rust паника - это исключение.
Статический анализ switch - хороший инструмент (есть нюансы с `default:`, и с большими кодовыми базами, с бинарными поставками). С исключениями же достаточно покрыть тестами catch блоки, которых будет значительно меньше чем проверок кодов возврата. И логика приложения не замусоривается лишними if err != nil и последующими обработками ошибок.
Так что повторюсь: исключения и коды возврата - это два разных инструмента, для разных задач. Выбирайте то, что вам подходит больше для конкретной задачи
У того, что в стандарте закрепят byte == 8bit есть ещё неприятный момент для таких плформ. std::byte и char типы на этих платформах перестанут подпадать под стандарт, и начнутся проблемы с placement new и использовании std::byte в принципе :(
Спасибо, поправил
Есть https://wg21.link/P2758R3
Все шансы что тоже окажется в C++26
Думаю C++ ещё предстоит отказаться от явного constexpr в пользу автоматического его проставления. Но в ближайшее время это не произойдёт
А что бы вы предложили использовать вместо [: :] ?
Тут вопрос в переносимости фичи. С атрибутами хотят позволить работать, но это одно из самых различающихся мест в фронтенде имеющихся компиляторах. Поэтому выбор был между "рефлексией в C++26 без атриботов" и "рефлексией с атрибутами незивестно когда"
На моём экране он практически не отличим от одинарной кавычки :(
Когда вы напишите предложение и реализуете прототип в компиляторе. Или если вы найдёте кого-то, кто захочет этим заниматься вместо вас.
Вот в RISC-V аналогичная ситуация. Там размер регистра получается вызовом рантайм команды. В текущей версии стандарта size() всегда известен на этапе компиляции
Думаю да. Как минимум можно проинициализировать std::simd нулями, докопировать оставшуюся часть в simd переменную и выполнить команду. Маски тоже поддерживаются
Перепроверил по черновику предложения
`dealias(x)` отбрасывает все алиасы любой вложенности.
Трюк с получением имени через алиас на самом деле не сработает т.к. рекомендуется отбрасывать информацию об алиасах в `type_of`. Подправил статью
Обязательно продолжу писать о новинках :)
Комиты на модули в GCC идут еженедельно. Clang тоже неплохо уже модули поддерживает.
В MSVC\STL тоже всё хорошо. Видно что модули у них в высоком приоритете https://github.com/microsoft/STL/issues/4700 и видно что процесс движется https://github.com/microsoft/STL/issues/1694
Модули хотят очень многие вендоры - возможность ускорить сборку в 3-10 раз, это очень крутое преимущество.
Но модули затрагивают сразу очень много различных частей языка, что и усложняет их внедрение и разработку:
компилятор - новый синтаксис, новое поведение с сериализацией внутреннего представления, немереное количество проблем с краевыми случаями
оптимизатор - новые области видимости позволяют новые оптимизации
линкер (или его аналог) - участвует при формировании файла модуля
сборочные тулчейны - они должны автоматически обнаруживать зависимости исходников от модуля
препроцессор - нужен режим для тулчейнов, для обнаружения модулей (порой делается отдельной утилитой)
ABI - появляются сущности, "прикреплённые" к модулю
стандартная библиотека - большая работа по созданию модуля std и его тестированию (макросы больше не экспортируются, модуль должен нормально работать с include из стандартной библиотеки)
Умножьте всё это на 2 (модули же работают в двух режимах: import "header" и import module), а для MSVC умножьте ещё на 2 (IDE использует другой компиляторный фронтенд для подсветки синтаксиса и подсказок) :-(
В этом конкретном случае мне больше по душе транслитерация :)
Но при этом придётся подменять функцию освобождения памяти исключения. А в libc++ runtime это сделать нельзя, в одном месте эта функция заинлайнивается в самом libc++ runtime. Так что возможно что не получится
Отличный вариант! Сделаю так для Boost. 1.88
Спасибо!
Python, C#, Java, JS и многие другие языки программирования с вами не согласятся. Да и в Rust паника - это исключение.
Статический анализ switch - хороший инструмент (есть нюансы с `default:`, и с большими кодовыми базами, с бинарными поставками). С исключениями же достаточно покрыть тестами catch блоки, которых будет значительно меньше чем проверок кодов возврата. И логика приложения не замусоривается лишними
if err != nilи последующими обработками ошибок.Так что повторюсь: исключения и коды возврата - это два разных инструмента, для разных задач. Выбирайте то, что вам подходит больше для конкретной задачи
Исключение в тесте не ведёт к падению программы в большинстве тестовых фреймворков. А вот стектрейс от неожиданного исключения пришёлся бы кстати
Завозят в C++26. Как раз добавляют рефлексию времени компиляции
Отличная кстати идея! Но библиотека должна работать и в C++14, а там такого инструмента нет. А вот для новых стандартов я добавлю, спасибо!
Да, есть ограничения :(
Некоторые из них обходятся в Boost.PFR
Вот так работает https://godbolt.org/z/b3TMxnj39
Требуется C++20 стандарт с поддержкой auto в шаблонных параметрах