>> Во-первых, исключения совсем для другого (хотя иногда области применения и могут перекрываться).
> вот с этого места поподробней. а то начинает закрадываться подозрение, в котором
> фигуриует слово «говнокод».Что именно "поподробней"? Страуструпа пересказывать как-то не хочется. Исключения, если уж сравнивать с переходами по меткам, то тем, которые setjmp()/longjmp() и иже с ними. Их задача - не добавляя множества явных путей, передать управление в случае нестандартной ситуации в нужное место через произвольное количество уровней на стеке. При использовании "умных" указателей и finally { ... } их можно использовать для подчистки, да. Но, во-первых, вы когда-нибудь видели в не очень-то и сложном методе пять уровней вложенности finally? Это адЪ, особенно при наличии вложенных циклов и всяких там if'ов в промежутке. А во-вторых, goto бывает полезен в неочевидных ситуациях. Верить заставлять не собираюсь. Если будет конкретное доказательство абсолютной бесполезности (даже не вреда) goto в C++ - можно будет говорить предметно.
>> Во-вторых, метки не порождают множества уровней вложенности — наоборот, они делают
>> код «плоским».
> долой циклы! и вообще блоки. только метки, только плоский код! (пардон, не
> удержался)
:-P Пардон пардоном, а из контекста вырывать нехорошо.
> goto в c++ всё равно приходится увязывать с объявлениями более-менее сложных объектов.
> в итоге получается каша. которую чаще проще и красивей можно решить
> при помощи декомпозиции, грамотного применения return и да — исключений.
Такая каша возникает обычно из-за смешивания уровней логики. Частая проблема - неумение, а порой и практическая невозможность, произвести декомпозицию функции/метода приводит к гипертрофированию оного. В этом случае goto действительно становятся бОльшим злом, нежели умные обёртки и многоступенчатые try { ... }.
>> что добавление поддержки исключений утяжеляет программу чисто из-за добавления соответствующего
>> кода компилятором, что для мелких утилит (Unix-way, всё такое) весьма заметно.
> зачем писать мелкие утилиты на цпп? если используются фичи библиотек цпп, то
> утилита и так распухнет. а если нет — то чего было
> выпендриваться?
Утяжеление не только за счёт размера кода, но ещё и за счёт дополнительно работающего кода (снижение производительности, все дела). Хотя заранее соглашусь, потери сравнительно небольшие, если не запускать процессы тысячу раз в секунду. :)
>> C++ — это швейцарский нож.
> скорее голландский сыр
... а кому и свиной хрящик. Дело вкуса.
>> Попытки использовать C++, скажем, чисто для ООП, с избеганием даже тени процедурного подхода, выглядят грустно.
> потому что нормального ООП там нет. дурацкий симула-подход, который растиражировали остальные
> — костыль-пародия.
Ну нет. И что? Программы на C++ почему-то продолжают исправно работать несмотря на свою не-ООПность. Хуже того - такой языковой кошмар для любителей элегантности, как Perl, тоже продолжает существовать вместе с тоннами написанного на нём кода - и далеко не всегда такого уж плохого.
Я готов согласиться с тем, что C++ - это мегакостыль. Возможно, самый большой костыль за всю историю программирования. Но пока ничего глобально лучшего нет - только нишевые решения. Так что увы.
