классов и структур, потому что если оно используется в классе хотя бы для одного метода, то и во всех остальных (инфа 80%) тоже будет.. чо для каждого метода индивидуально код "пачкать"
А потом кто-нибудь из Ваших коллег случайно напишет не-noexcept метод...
я так полагаю идея в том, чтобы это вызывало ошибку компиляции?
А компилятору всё дерево вызовов проверить? Так тогда нужно начинать с обязательной диагностики не-noexcept вызовов внутри noexcept-функций (и всё ещё неясно, что делать с C API)
достаточно проверить noexcept во всех методах...
Идея ТС как раз в том, чтобы у метода это не указывать :))
например fs и нетворк вряд ли будут полагаться на исключения, скорее на коды ошибок, а раз так, то все сущности будут noexcept.. ну, или возьми другую область, где отказываются от исключений.. тогда какой резон каждому методу прописывать доп.аттрибут, если можно кучей? в D можно написать nothrow { куча кода } // или nothrow: // и весь код ниже будет nothrow
fs и нетворк вряд ли будут полагаться на исключения Ох уж эта диванная аналитика...
зачем дерево, если можно все диагностики сломать простым if (!vec.empty()) vec.at(0);
А в чём смысл такого действия? Если у вас шаблонный хитрый код, то noexcept вы скорее всего будете проверять на специальных методах (конструкторах и присваиваниях). Они уже автоматически выводятся при = default; Если вы хотите меньший объём бинарников и лучшую оптимизацию, то LTO даст намного больше профита и сам выведет noexcept
исходя из этого noexcept ваще не нужен, потому что компилер и так может его вывести
нужен, но в основном на специальных функциях
кстати, про оптимизацию - видел в 16-м clang новую фичу под названием BOLT. Вроде как публичная. Но пока что нигде не всплывало в статьях/обзорах, только у них самих (в качестве примера применения к clang)
Я кстати как-то удивился, что clang тащит с собой какой-то болт. Пытался найти инфу о том, как я могу это применить, но не нашёл. В итоге забил
забили болт на болт?
как это нигде не всплывала, если эта тулза по сути фейсбуком разработана, а в монорепе LLVM он оказалася уже потом, когда все было готово https://research.facebook.com/publications/bolt-a-practical-binary-optimizer-for-data-centers-and-beyond/ https://discourse.llvm.org/t/preparing-bolt-for-llvm-monorepo/59196
у них достаточно развёрнутое описание. Сильно напоминает PGO сперва, но потом выглядит вообще круто. Типа, BOLT берёт профайл и перелинкует _существующий_ бинарь, чтобы он работал быстрее. Причём не только текущей сборки, но и будущих (чем больше расхождение, тем меньше точность). И вот при всём при этом - новость про него не всплыла ни в каких новостях (если оно и в самом деле так круто).
Обсуждают сегодня