При чем здесь Кнут? Предложенные автором типы никак не уменьшают производительность. Даже больше, такой тип, это дополнительная информация о типе. Для оптимизирующего компилятора такой тип, если он является встроенным - это громадное пространство для оптимизаций, в том числе и упаковка std::optional в sizeof(int).
Ну и C и C++ - это языки высокого уровня. Ни больше ни меньше. Соответствие ассемблеру вещь весьма растяжимая. Пространство для compile time оптимизаций у C++ не такое большое, как принято считать. Да, Java или C# безнадежно хуже из-за ссылочных типов данных или своей модели памяти. Да и вообще, собрать их "без рантайма" ещё нужно постараться.
Но это не значит, что C и C++ идеальны или достаточно хороши в этом плане. Чтобы "ускорить" эти языки добавили дыры (UB) в стандарт, чтобы у компилятора было больше информации. Например, числовые знаковые числа в языках C и C++ довольно абстрактны. В стандарте не определено, что будет происходить при переполнении. Может происходить вообще всё что угодно.
О каком соответствии ассемблеру идёт речь? Различные системы команд могут разительно отличаться. Регистр с флагом переполнения может быть, а может и не быть. Может использоваться совсем другая модель памяти с несколькими адресными пространствами.
Там где мощностей мало, без расширений семантики С или C++ достаточно сложно писать. Иначе, когда тебе нужно сделать какую-то специфичную для процессора вещь, ты просто теряешься в догадках, а не сломается ли твой код из-за UB, когда тебе нужно потрогать стек поинтер.
Там сейчас много планов по балансу, да и кампании ещё будут делать
Там скорее всего код отслеживания уже давно в рантайме юнити.
При чем здесь Кнут? Предложенные автором типы никак не уменьшают производительность. Даже больше, такой тип, это дополнительная информация о типе. Для оптимизирующего компилятора такой тип, если он является встроенным - это громадное пространство для оптимизаций, в том числе и упаковка std::optional в sizeof(int).
Ну и C и C++ - это языки высокого уровня. Ни больше ни меньше. Соответствие ассемблеру вещь весьма растяжимая. Пространство для compile time оптимизаций у C++ не такое большое, как принято считать. Да, Java или C# безнадежно хуже из-за ссылочных типов данных или своей модели памяти. Да и вообще, собрать их "без рантайма" ещё нужно постараться.
Но это не значит, что C и C++ идеальны или достаточно хороши в этом плане. Чтобы "ускорить" эти языки добавили дыры (UB) в стандарт, чтобы у компилятора было больше информации. Например, числовые знаковые числа в языках C и C++ довольно абстрактны. В стандарте не определено, что будет происходить при переполнении. Может происходить вообще всё что угодно.
О каком соответствии ассемблеру идёт речь? Различные системы команд могут разительно отличаться. Регистр с флагом переполнения может быть, а может и не быть. Может использоваться совсем другая модель памяти с несколькими адресными пространствами.
Там где мощностей мало, без расширений семантики С или C++ достаточно сложно писать. Иначе, когда тебе нужно сделать какую-то специфичную для процессора вещь, ты просто теряешься в догадках, а не сломается ли твой код из-за UB, когда тебе нужно потрогать стек поинтер.