Здравствуйте Sergey, Вы писали:
S>В деструктор, естественно, надо запихивать не код, который должен быть выполнен в случае неудачи, а общую для успеха и неудачи часть кода. Применительно к обсуждаемому примеру (примеру того, как не надо писать, кстати) код может выглядеть так:
[...]
И "это" лучше if/else??? Вопросов больше не имею (с)
Здравствуйте Vladik, Вы писали:
S>>В деструктор, естественно, надо запихивать не код, который должен быть выполнен в случае неудачи, а общую для успеха и неудачи часть кода. Применительно к обсуждаемому примеру (примеру того, как не надо писать, кстати) код может выглядеть так:
Там вкралась ошибка: естественно, должно быть не
closer(*this);
а
closer somename(*this);
V>И "это" лучше if/else??? Вопросов больше не имею (с)
"Это" гораздо лучше if/else по одной простой причине — какая бы у тебя сложная функция не была, сколько бы раз ты внутри нее не написал return, ты не сумеешь забыть закрыть файл — об этом позаботиться компилятор. Впрочем, с файлами обычно таких проблем не возникает. А вообще это в C++ стандартная техника освобождения ресурса (захват, правда, обычно делают в конструкторе).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Sergey, Вы писали:
S>Там вкралась ошибка: естественно, должно быть не
Вот-вот. Да, так делать теоретически правильнее, и С++ это позволяет, но... ведь это же изврат для таких тривиальных задач, неужели сам не видишь?
[...] S>"Это" гораздо лучше if/else по одной простой причине — какая бы у тебя сложная функция не была, сколько бы раз ты внутри нее не написал return, ты не сумеешь забыть закрыть файл — об этом позаботиться компилятор.
Если получается настолько сложная функция, что начинают иметь смысл "такие" вещи — то имеет смысл задуматься над декомпозицией.
S>Впрочем, с файлами обычно таких проблем не возникает. А вообще это в C++ стандартная техника освобождения ресурса (захват, правда, обычно делают в конструкторе).
Не надо путать ресурсы, для которых всегда имеет смысл написать враппер, и "общий" код, который должен быть выполнен в случае эксепшина.
V>Я тоже не вчера родился. Мой опыт говорит, что исключения в С++ ничем кроме геморроя с try/catch и вылетом неизвестно откуда неизвестно куда не оборачиваются. За редким исключением.
При всем уважении, твой опыт — это только твой опыт.
Мой опыт говорит, что при нормальном проектировании исключения весьма полезны (заметь я не говорю о том, что их нужно использовать всегда)
SZ>>Нету вредности исключений пробрасываемых из библиотек, есть вредность плохо написанных библиотек, в которых применение исключений приводит к кошмару.
V>По поводу плохих библиотек я уже писал. Возможно когда я увижу правильную библиотеку, я изменю свое мнение.
Я надеюсь, что с тобой это когда-нибудь случиться
SZ>>И на последок, я всегда был против категоричного утверждения, что какие-то конструкции хуже других. Все надо к месту применять. Существует много ситуаций, когда одна или другая конструкция лучше подходит, ну так и используй ее.
V>Именно так я и делаю. Я не против исключений вообще, я против маразмов типа:
V> V>
V>которые неизбежно получаются при широком использовании эксепшинов, особенно в левосторонних библиотеках.
Это маразм, но вызван он не использование исключений вообще, а кривостью проектирования.
Мое мнение, что все-таки ключевое в исключениях это механизм раскрутки стека, то что ставит их на уровень выше кодов возврата при использовании "выделение есть инициализация".
V>Кстати, опять возвращаясь к моему первому письму — исключения в конструкторах в С++ как-бы есть, но работают настолько криво, что все-равно лучше их там не использовать.
Что значит криво? Приведи пример. Исключения в конструкторах честно вызывают деструкторы всех созданных к моменту исключения членов и базовых классов.
Здравствуйте MaximE, Вы писали:
ME>Мое мнение, что все-таки ключевое в исключениях это механизм раскрутки стека, то что ставит их на уровень выше кодов возврата при использовании "выделение есть инициализация".
Это не всегда удобно. Пример приводился.
V>>Кстати, опять возвращаясь к моему первому письму — исключения в конструкторах в С++ как-бы есть, но работают настолько криво, что все-равно лучше их там не использовать.
ME>Что значит криво? Приведи пример. Исключения в конструкторах честно вызывают деструкторы всех созданных к моменту исключения членов и базовых классов.
Я не пользуюсь исключениями в конструкторах Мне достаточно почитать высказывания людей, с этим сталкивавшихся. В частности, было что-то типа: "не видел еще ни одного компилятора, у которого бы не было проблем с исключениями в конструкторе".
Здравствуйте Vladik, Вы писали:
V>Кстати, опять возвращаясь к моему первому письму — исключения в конструкторах в С++ как-бы есть, но работают настолько криво, что все-равно лучше их там не использовать.
Что значит работают криво? Не раскручивается стек? Не вызываются деструкторы при раскрутке стека?
SZ>>так вот, получается, что для обеспечения инварианта каждый метод класса должен содержать проверку индикаторов.
V>Это вполне нормально.
Кому как, для меня это не нормально. Инвариант, это значит, что объект не должен существовать в не валидном состоянии, он даже не должен быть сконструирован, это исключительная ситуация.
SZ>>Инициализацию невозможно поместить в конструктор, так как нету кода возврата. Это простейший случай, для инициализации объекта, но если после исполнения какого-нибудь метода инвариант нарушен, то с таким объектом можно продолжать работать не зная о том, что он более не валиден, и никто об этом не просигналит, если забыли проверить возвращенное значение.
V>Отлавливается сразу при отладке, как показано выше.
Хочу предложить уважаемым участникам форума в этой ветке вывести плюсы и минусы каждого подхода вместо бесполезного спора. В результате получится что-то типа hints для конкретных ситуаций.
Здравствуйте Sergey Zhulin, Вы писали:
SZ>Кому как, для меня это не нормально. Инвариант, это значит, что объект не должен существовать в не валидном состоянии, он даже не должен быть сконструирован, это исключительная ситуация.
Тогда можно для конструирования использовать Create(), а конструкторы засунуть в private.
[...] SZ>Хочу предложить уважаемым участникам форума в этой ветке вывести плюсы и минусы каждого подхода вместо бесполезного спора. В результате получится что-то типа hints для конкретных ситуаций.
Минусы по-пунктно уже были изложены в самом первом моем письме. Пусть плюсы кто-нибудь другой опишет.
Здравствуйте Vladik, Вы писали:
V>Здравствуйте MaximE, Вы писали:
V>Я не пользуюсь исключениями в конструкторах Мне достаточно почитать высказывания людей, с этим сталкивавшихся. В частности, было что-то типа: "не видел еще ни одного компилятора, у которого бы не было проблем с исключениями в конструкторе".
Это не довод, давай конкретные описания проблем. Зачем организовано это обсуждение? Ты хочешь всех убедить в бесполезности исключений или просто поболтать?
И так, кидай описания этих проблем и имена компиляторов, где эти проблемы проявляются. За это, лично я дам очки на всю катушку. Тогда и польза от твоего обсуждения будет.
Здравствуйте Sergey Zhulin, Вы писали:
SZ>Это не довод,
Да, это не довод, но учитывать стоит.
SZ>давай конкретные описания проблем. Зачем организовано это обсуждение? Ты хочешь всех убедить в бесполезности исключений или просто поболтать?
Я просто высказал свое мнение. Конкретная проблема — неотловленный эксепшин в деструкторе приводит к "undefined behaviour".
Здравствуйте Vladik, Вы писали:
V>Здравствуйте Sergey Zhulin, Вы писали:
SZ>>Это не довод,
V>Да, это не довод, но учитывать стоит.
Что учитывать-то?
SZ>>давай конкретные описания проблем. Зачем организовано это обсуждение? Ты хочешь всех убедить в бесполезности исключений или просто поболтать?
V>Я не пользуюсь исключениями в конструкторах Мне достаточно почитать высказывания людей, с этим сталкивавшихся. В частности, было что-то типа: "не видел еще ни одного компилятора, у которого бы не было проблем с исключениями в конструкторе".
V>Я просто высказал свое мнение. Конкретная проблема — неотловленный эксепшин в деструкторе приводит к "undefined behaviour".
Влад, определись. То конструкторы, то деструкторы... Назови компиляторы и их проблемы при бросании исключений из конструкторов. Для меня лично это очень важно, потому что я использую исключения в конструкторах. Так вот, эти проблемы и будут доказательством того, что ты прав. Рассмотрев эти проблемы, возможно, я пересмотрю мое отношение и подход к исключениям.
Здравствуйте Sergey Zhulin, Вы писали:
SZ>>>Это не довод, V>>Да, это не довод, но учитывать стоит. SZ>Что учитывать-то?
Глюки конкретных компиляторов, если ты ими пользуешься.
[...] V>>Я просто высказал свое мнение. Конкретная проблема — неотловленный эксепшин в деструкторе приводит к "undefined behaviour". SZ>Влад, определись. То конструкторы, то деструкторы...
Одна фигня.
SZ>Назови компиляторы и их проблемы при бросании исключений из конструкторов.
Поищи сам, вот в этом самом форуме. Мне влом. Упоминались конкретные компиляторы.
Здравствуйте Sergey Zhulin, Вы писали:
V>>Поищи сам, вот в этом самом форуме. Мне влом. Упоминались конкретные компиляторы. SZ>Ну тогда ты не прав. Почему? Поищи сам в форуме.
Может я и не прав, но проблемы будут у тебя
SZ>Парни. Давай-те следующее, интересное обсуждение начнем
Ну что ж, каждый остался при своем. Чего и следовало ожидать.
Здравствуйте Vladik, Вы писали:
V>Я просто высказал свое мнение. Конкретная проблема — неотловленный эксепшин в деструкторе приводит к "undefined behaviour".
Здравствуйте MaximE, Вы писали:
V>>Я просто высказал свое мнение. Конкретная проблема — неотловленный эксепшин в деструкторе приводит к "undefined behaviour". ME>Исключение в деструкторе — грубая ошибка.
Угу. Неотлавливаемая компилятором. Причем чем меньше источников эксепшинов — тем меньше вероятность ее возникновения.
Здравствуйте Vladik, Вы писали:
V>Здравствуйте MaximE, Вы писали:
V>>>Я просто высказал свое мнение. Конкретная проблема — неотловленный эксепшин в деструкторе приводит к "undefined behaviour". ME>>Исключение в деструкторе — грубая ошибка.
V>Угу. Неотлавливаемая компилятором. Причем чем меньше источников эксепшинов — тем меньше вероятность ее возникновения.
Можно никаких методов и функций не вызывать, объектов не создавать — тогда даже коды возврата не нужны .
Здравствуйте Vladik, Вы писали:
V>Здравствуйте MaximE, Вы писали:
V>>>Я просто высказал свое мнение. Конкретная проблема — неотловленный эксепшин в деструкторе приводит к "undefined behaviour". ME>>Исключение в деструкторе — грубая ошибка.
V>Угу. Неотлавливаемая компилятором. Причем чем меньше источников эксепшинов — тем меньше вероятность ее возникновения.
Логика железная :)
а чем меньше указателей и работы с динамической помятью — тем меньше вероятность, что мы получим access violation.
Это — аргумент в пользу отказа от указателей?