Здравствуйте, alexkro, Вы писали:

A>А толмуда с названием "Coding guidelines" у вас нет? Перегнули вы тут явно.
Есть, только не талмуд, которому никто следовать не будет, а небольшой внутрифирменный документ, стандартизирующий написание кода. Над проектом работает 10 человек, каждому из которых доступен весь общий код. Каждый разработчик — представитель своей школы программирования, и если он будет применять сугубо свой стиль, особенно не в своих модулях, то это будет полнейший бардак, а код будет выглядеть как перелатанное одеяло.
Поэтому существует внутрифирменное соглашение-стандарт на написание кода. И каждый может представить своё обоснованное предложение на его усовершенствование или изменению. Да и опыт команды растёт, что отражаеться на эволюции "Coding guidelines".

A>Самодокументированность липовая, так как проблемы в этом смысле абсолютно такие-же как и в Java, когда в одной функции спецификация меняется, и это заставляет поменять все функции, её вызывающие, а дальше и все функции их вызывающие, и т.д. В конце концов это приводит к бардаку.
Тоже самое с модификатором const, сделав одну из функций неконстантной, вам прийдёться модифицировать все функции исполюзующие её. Но вы ведь не будете отрицать необходимость этого модификатора.

B>> К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций,
A>Как раз таки, компилятор должен кучу кода награмаздить, чтобы проверить соответствие спецификации исключения. Тут уж ни о какой оптимизиции речи не идёт, за исключением опять-же пустого throw().
На то он и компилятор, чтобы громоздить код вместо человека. Вы же не обижаетесь на автоматически код пролога и эпилога функций, и на автоматические деструкторы и операции копирования.
К тому же, компиляторы эволюционируют

>> или для автоматической генерации кода обработки исключения.
A>Автоматическая генерация обработчика? std::unexpected()? Кому такая нужна?
Кому не нужна, тот и не использует. Кому понадобиться, тот будет рад что такое возможно.

Во всех крупных проектах, в которых я участвовал, к конце концов формировалась своя иерархия классов-исключений.
Хлтя если вы вообще противник технологии исключений, то можем прикратить нашу дисскусию.