Open raidenluikang opened 1 year ago
Например, если программу соберём без RTTI,
#include <typeinfo>
-- либо должен быть ошибка компиляция либо не должен импортировать ничего.
std::type_info
класс не должен существовать.
dynamic_cast
-- должен быть ошибка компиляция, либо полности удалим ключегово слово dynamic_cast
при без RTTI
typeid
- ключевого слово не должен существовать.
не сгенрировать type_info для полиморфный типах. Экономится памяти виртульный таблице.
все методы который возвращает std::type_info - не должен существовать, их вызов будет ошибка компиляция. Это касается std::function :: target_type , target методы.
Про try-catch блоки забыли. Как я понимаю не так просто это ввести из за костылей в модели памяти и допущений. Например инициализация всех статический перемененных и констант по стандарту должна быль потоко-безопасной, т.е. компилятор должен добавить вызов кода ABI с мьютеском, это системный вызов и потенциально может вызвать ошибку которую нечем обработать кроме как исключением, иначе придется вводить альтернативный механизм обработки непредвиденной ошибки в ABI, вроде вызова универсальной функции синего экрана. Все примерно как и с оператором new который может бросить bad alloc, из за чего ввели костыль new (std::nothrow)
+Хотелось что-бы что-бы std::move_if_noexcept и им подобные работали оптимально при -fno-exceptions. Все функции и методы помечались как noexcept или std::is_nothrow... и им подобные считали, что всё помечено как noexcept
Некоторые страдает изза RTTI и exceptions (исключение), embedded, mobile, ioT разработчики, еще у некоторые компании не разрешается использовать RTTI and exceptions.
Почти все 3 большие компиляторы (GCC, Clang, MSVC) поддерживает -fno-rtti , -fno-exceptions. Но это не предусмотрено в стандарте, если не ошибаюсь.
Предлагаю стандартном уровне их сделать опциональные фича, Определить каждый случае без исключение или без RTTI.
Да это очень трудноёмкая задача, зато точно знаем что будет если включим -fno-rtti, -fno-exceptions.