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

A>>>А толмуда с названием "Coding guidelines" у вас нет? Перегнули вы тут явно.
B>> Есть, только не талмуд, которому никто следовать не будет, а небольшой внутрифирменный документ, стандартизирующий написание кода. Над проектом работает 10 человек, ...
A>Команда из десяти человек, а сколько бюрократии. Я видел группы побольше, и никаких формальных документов не требовалось. Разумные люди сознательно не будут бардак создавать.
"Coding guidelines" есть практически везде, где работают удалённые команды, вот пример самого краткого:
Phoenix team guielines
Там же есть ссылки на другие задекларированные аспекты работы, хотя казалось бы зачем GNU разработчикам на себя такие вериги накладывать — знай себе твори. Однако история нам подсказывает — где есть толпа, там должен быть определённый закон, иначе не будет развития. Даже в Open Source движении есть координаторы проектов, своего рода князьки и рядовым разработчиком бывает порой труднее их убедить, чем коммерческого менеджера.

A>>>Самодокументированность липовая, так как проблемы в этом смысле абсолютно такие-же как и в Java, когда в одной функции спецификация меняется, и это заставляет поменять все функции, её вызывающие, а дальше и все функции их вызывающие, и т.д. В конце концов это приводит к бардаку.
B>> Тоже самое с модификатором const, сделав одну из функций неконстантной, вам прийдёться модифицировать все функции исполюзующие её. Но вы ведь не будете отрицать необходимость этого модификатора.
A>Это совсем не тоже самое. Во-первых, твоё утверждение о "модификации всех функций" неверно. Во-вторых, ответь мне, почему const входит в сигнатуру функции, а спецификация исключений нет? Я удивлен, что тебе вообще пришла идея такого сравнения в голову.
Можно вообще не использовать ни const ни throw, и всё будет работать. Но это IMHO снизит управляемость кода. А сравниваю эти два зарезервированных слова я потому что сторонник порядка. Если функция не изменят состояние объекта, то это должно быть описано; если функция может генерировать исключения, то это тоже должно быть указано.

B>>>> К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций,
A>>>Как раз таки, компилятор должен кучу кода награмаздить, чтобы проверить соответствие спецификации исключения. Тут уж ни о какой оптимизиции речи не идёт, за исключением опять-же пустого throw().
B>> На то он и компилятор, чтобы громоздить код вместо человека. Вы же не обижаетесь на автоматически код пролога и эпилога функций, и на автоматические деструкторы и операции копирования.
A>Ты говорил про оптимизации или про что? А теперь перекинулся на то, как компилятор облегчает генерацию кода. Да-с.
Что дасссс?
Современный компилятор громоздит код гораздно лучше, человека. Чего стоит только вызов деструкторов для автоматических объектов при исключении. Я давно работаю с компилятором Intel C++, и наблюдаю эволюцию их рекомендаций по написанию кода, который будет наилучшим образом оптимизирован, тенденция ведёт к упрощению, к снятию ограничений с кодера.
А вообще давай послушаем что сказали отцы throw

B>> К тому же, компиляторы эволюционируют
>>>> или для автоматической генерации кода обработки исключения.
A>>>Автоматическая генерация обработчика? std::unexpected()? Кому такая нужна?
B>>Кому не нужна, тот и не использует. Кому понадобиться, тот будет рад что такое возможно.
A>Вот и объясни мне, кому такое понадобится и зачем. Иначе, в твоих словах нет аргументов.
Как минимум — выдача диагностического сообщения о классе исключения, и если доступна контесктная информация, то и её выдача. Наверняка ты видел много сообщений "IO error" или "Divide by 0 error". Как минимум компилятору доступно имя класса исключения,что он и может использовать в обработчике по умолчанию.

B>>Во всех крупных проектах, в которых я участвовал, к конце концов формировалась своя иерархия классов-исключений.
A>Мы кажется говорим про спецификации исключений, а не про иерархии классов-исключений. Почему-то тебя все время в сторону тянет.
A>Я не противник технологий, я противник их бездумного применения. Далее прошу оставаться в рамках спецификации исключений и не перепрыгивать на смежные вопросы.
Посмотри на тему дисскусии, там про исключения вообще ничего нет
А про иерархия я говорю, потому что, не вижу смысла говорить о строительной глине, не подразумевя что из неё делают кирпичи, а из них дом. А споры нужна ли белая глина, или достаточно для всего красной, это пустая трата времени.
Вот я и говорю, что на моей практике две разных команды пришли к одному и тому же удобному для них решению — иерархии классов-исключений.