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

E>>Ну допустим. Тогда следующий вопрос: пусть в d() catch выполняет нормальную обработку и восстановление после исключения some_exception_t (т.е. из catch ничего не выбрасывается). Что тогда делать с another_exception_t, которое так же было в исходном множестве исключений?

D>Ничего. catch ведь отработал => цирк уехал.

Вам самому не смешно?
Сначала в программе выбрасывается, например, исключение о том, что у текущего пользователя нет прав для проведения текущей операции. В процессе раскрутки стека выскакивает исключение о том, что коннект к БД был потерян (совпадение, допустим). Это исключение обрабатывается, а о нарушении прав доступа мы благополучно забываем -- ну не было его, совсем.

D>Логика примерно такая же, как в случае ловли исключения по базовому классу. Реально пойманный объект ведь может быть совсем другого типа, и даже многих других типов (приветствуем множественное наследование ), но catch рассматривает только контракт базового класса.

Интересная у вас логика. Только не правильная. Исключения по базовому классу ловятся для других целей.

Но, позволю себе напомнить, что мы сейчас говорим о разных исключениях.

D>*Такими темпами я Вам скоро целый язык спроектирую

Не льстите себе.

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

D>>Потому что 10К нетривиальных автоматических объектов за раз.
E>Офигеть. 10K объектов -- это вообще ничто.

Не в количестве вопрос, а в том что Вы делаете с этим количеством за одну операцию. Ну представьте 10К вложенных finally в коде на Java/C#...

E>Более того, аналогия с переполнение стека не корректна. Переполнение стека можно cпрогнозировать.

10К исключений тоже можно спрогнозировать.

E>И можно с ним бороться увеличением стека при порождении новых нитей приложения.

Ага-ага, особенно с рекурсиями неограниченной явно глубины...

E>А вот с исключениями в деструкторе, когда у системы не хватает памяти, чтобы собрать их воедино, может получиться трудновоспроизводимое поведение: иногда приложение будет падать при 10K исключений, иногда не будет, а иногда будет падать при 5K.

А если в деструкторе написать рандомный exit(0) всё будет ещё хуже.

E>>>А чем первое лучше любого другого? В частности, последнего?
D>>"Чем лучше ? Чем армяне" (с) народ
E>Т.е. четкого обоснования не будет?

Оно уже было указано в форме риторической цитаты

Перевод для слишком серьёзных читателей: разницы нет, так как мы всё равно собираемся предоставлять средства для доступа ко всей толпе исключений.

E>Это означает, что все catch-и в C++ должны были бы выглядеть именно так.

С каких это ??? catch'и должны выглядеть по-всякому. И, разумеется, нужна обычная форма, для случаев когда стада зависимых исключений не интересуют.

E>В С++ в качестве исключения можно выбросить все, что угодно, хоть std::exception, хоть int, хоть char*. Может покажете, как к int или char* привязать InnerException?

Мы же синтаксис в любом случае корёжим — всё возможно

Здравствуйте, drol

Ну что тут сказать. Вы пытаетесь доказать, что C++ мог бы быть другим. Дык с этим никто и не спорит.

Вы пытаетесь доказать, что ваш подход с разрешением выпуска исключений из деструкторов с поимкой их всех и предоставлением к ним доступа из catch лучше и логичнее. Не получается. В вашем подходе не видно ни простоты, ни логичности.

Думаю, что тема исчерпана.

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

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

D>>Что то я сомневаюсь что managed языки не используют подсчет ссылок для определения свободен ли обьект или нет для освобождения через GC. Есть другие мнения?

N>.NET не использует подсчет ссылок. Он строит граф достижимых объектов, остальные автоматически умирают при дефрагментации.

Это понятно. Только не понятно по какому принципу он его строит, где хранятся зависимости, они не требуют синхронизации?

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

D>Это понятно. Только не понятно по какому принципу он его строит, где хранятся зависимости,

Ссылки внутри объектов известны из метаданных. Списки стековых корневых объектов тоже никаких снихронизаций не требуют, бо каждый в пределах своего потока. Статические корневые объекты также не представляют проблем. Что там ещё ? Очередь финализируемых ? Вроде тоже никаких особых граблей.

D>они не требуют синхронизации?

В данном случае только одна могучая синхронизация — остановка исполнения на время работы собственно GC

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

D>В данном случае только одна могучая синхронизация — остановка исполнения на время работы собственно GC

Это не обязательно, есть разные алгоритмы GC, в том числе и те, которые не требуют остановку приложения на всё время работы GC (остановка требуется, но только на часть работ, основная работа выполняется конкурентно с приложением).

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

N>>.NET не использует подсчет ссылок. Он строит граф достижимых объектов, остальные автоматически умирают при дефрагментации.
D>Это понятно. Только не понятно по какому принципу он его строит, где хранятся зависимости, они не требуют синхронизации?
Зависимости нигде не хранятся, соответственно синхронизация не нужна. Строится по "простому" принципу — обходятся все достижимые объекты, начиная с корневых.

Естественно, используется куча сложных оптимизаций, типа системы поколений.

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

E>А что же будет, если выход из блока кода происходит по исключению? Какое исключение будет выпущено наружу -- которое из блока кода или из Dispose?

В С# такая проблема не стоит, т.к. все ислючения — это типы корнем от одного ссылочного типа Exception. Соответственно, подменить в текущем слоте стека один объект исключения на другой можно запросто. Более того, объекты исключений могут вкладываться друг в друга (последнее ссылается на предыдущее), образуя однонаправленный список, т.е. имея последний объект исключения, можно получить всю цепочку и докопаться до первопричины, будь такое желание.

Другое дело С++, где тип исключения произволен, к тому же может распространяться как по значению, так и по ссылке/указателю, и не придуман еще адекватный способ "подмены" ошибок или сохранения всей этой драмматической цепочки исключений (ИМХО, такого способа не существует принципиально в отсутствии GC).