Добрый день,

Допустим мы пишем функцию-член, в которой происходит трансформация вектора из строк.


Эта функция не гарантирует строгой безопасности, так-как если вдруг оператор + класса string для 4-ого объекта в векторе сгенерирует исключение, то первые три будут модифицированы, и класс изменит свое состояние. Исправить это легко

но этот вариант намного медленнее.
Если отбросить те моменты, где строгая безопасность исключений явно необходима, то в остальных случаях код подобного рода смахивает на паранойю. Скажем оператор + может сгенерировать bad_alloc, в принципе в этом случае вообще можно наплевать на то, что случиться с программой, все равно продолжать работать в таком состоянии будет невозможно, тут главное помереть с достоинством.
В общем вопрос в том, стоит ли стараться давать строгую гарантию безопасности исключений за счет производительности, в тех случаях, когда этого явно не требуется. И в каких вообще случаях стоит это делать?

Спасибо.

Добавлено через 1 минуту и 57 секунд
Забыл сказать, я за вариант "Только когда это явно требуется".

 
а если таk, то ненамного :

  

Это сообщение отредактировал(а) mes - 9.9.2010, 09:09

Да, но все равно медленнее (одного дополнительного выделения памяти достаточно), имелась ввиду сама мысль  

специально дожидался этого времени ? 

поддерживаю. в данном случае ( std::bind2nd(std::plus<std::string>(), "A") ) это действительно похоже на параною, а вот если там будет, например, вызов функции из dll-ки плагина, то это - вполне оправдано.

borisbn

Речь не только про исключение bad_alloc. Есть категория исключений, с которыми в большинстве случаев вообще не знаешь что делать. bad_alloc - хороший пример из этой категории. Вопрос на самом деле немного более запутанный. Углубимся в детали  

допустим мы разрабатываем класс X, который будет проделывать некоторую работу. Класс будет использован нами и возможно в дальнейшем еще кем-то другим, из своей же компании. Поскольку безопасность исключений нельзя оставлять на потом (это может затронуть интерфейс класса) об этом надо подумать заранее. Функция transform нас вполне устраивает и базовой гарантии нам более чем достаточно в нашем конкретном случае, но кто знает в каком контексте будет использован класс Х другими программистами? А если то, что сегодня кажется паранойей завтра кому-то другому может понадобиться? Смысл в том, думать ли о будущем, жертвовать производительностью программы, если на данный момент это не нужно?

Немного изменим пример, сделаем класс X шаблонным. Теперь в него можно передавать любой тип, и то, что кажется паранойей (исключение из оператора +) для класса string может запросто стать обычным явлением в каком нибудь классе A, хотя на сегодняшний день использование класса X с таким типом не предполагается. Но если посмотреть для примера библиотеку STL она для большинства классов дает строгую гарантию безопасности исключений, для большинства, но не для всех и скорее всего из соображений производительности.

Это сообщение отредактировал(а) azesmcar - 9.9.2010, 10:49

azesmcar, обычно, это решается путем указания в документации всех известных подводных камней. Т.е. в твоем случае, ты можешь указать, что в случае возникновения исключения класс окажется в неизвестном состоянии. Поэтому использующий его хороший программист будет это уже иметь в виду.

Свой вариант - нужно обеспечить, что бы при возникновении исключения не происходило утечек ресурсов и класс (откуда оно вышло) остался в consistent состоянии (т.е. не развалился при его дальнейшем использовании). Отслеживать, что бы класс остался в ПРАВИЛЬНОМ состоянии не требуется, т.к. совершенно непонятно, что под этим ПРАВИЛЬНОМ состоянием понимать.
Т.е. если возьмем исходный пример -
то он получается безопасным, т.к. хотя data и будет модифицирован, но с ним (модифицированным) можно будет работать и дальше.
Если этот метод отработает до конца (без исключений), data в любом случае будет модифицирован. И нет никакого смысла при возникновении исключения где то посередине работы все откатывать в первоначальное состояние.
Исключение в принципе сигнализирует об ошибке где то в процессе выполнения, и изменение части массива data можно считать частью этой возникшей ошибки

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

xvr


Это базовая гарантия, это само собой как минимум.

http://en.wikipedia.org/wiki/Exception_guarantees

тема про "strong guarantee".


в документации естественно это должно указываться  , но вопрос в том, как делать, т.е. ответ - не делать.

Я обычно стараюсь избегать таких ограждений. Только если отдаю на модификацию какие-то важные данные, которые могут понадобиться даже после того, как программа начала умирать. В целом это очень редко, так что ответ между "по требованию" и "никогда!", но ближе к "никогда".

В таком случае будет вариант 2, плавно перетекающий в вариант 3, т.к. лично я не очень вижу массы мест (точнее вообще их не вижу    ), где ТРЕБУЕТСЯ strong guarantee, а не достаточно просто basic guarantee

Функция может работать не с памятью а с каким нибудь системным ресурсом, тогда было бы желательно вернуть ему первозданный вид  

Интересно, а кто это ЗА 1-ый вариант и без комментариев?

Ну это можно рассматривать как специфичную разновидность утечки ресурсов (ресурс - это не только память). Так что это скорее ближе к basic guarantee

в принципе да, но скажем оставленный lock-нутым мьютекс не назовешь утечкой ресурсов.

azesmcar, ты же не маленький, ты сам все понимаешь, что мы подразумеваем под "basic", а что под "strong". Естественно, мьютексы и железки надо возвращать в исходное состояние. Более того, тут скорее всего никакого оверхеда по производительности не возникает (только немного по коду). А вот то, о чем ты говорил в первом посте (strong), это уже совсем другое - это значительный оверхед. Более того, местами совершенно ненужный. Поэтому, пользователь твоего класса узнав, что ему предоставляется только basic, уже сам должен решать как поступать дальше - добавлять код для получения strong или нет. Твоя задача, не ставить преграды на его пути (т.е. сделать все необходимое, чтобы он мог воспользоваться стандартной схемой: создать копию, изменить ее, сделать swap с оригиналом)...