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

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

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

ioj>>Вы ( не вы лично, а все сторонники исключений в этом треде) вообще читаете что в гугловском документе написано?

ioj>>When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f() calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly.

J>Все правильно написано. Они говорят о коде, который не был рассчитан на то, что могут появиться исключения, а ты вдруг их вводишь в одной единственной функции — тогда да, тебе надо просмотреть все места, откуда она вызывается, и далее по цепочке. Они только забыли добавить, что программа, видимо, изначально написана на Си, а не на С++.

нет, это не так, здесь говорится о любом коде, даже если он рассчитан на исключения they must make at least the basic exception safety guarantee

J>Это противоречит моему опыту. Basic exception safety достигается элементарно.
и это _не_ элементарно, это ровным счётом настолько же элементарно как и везде натыкать проверку возвращаемых значений, т.к. при возможности выброса исключения из любого метода, код вроде этого ( а фактически это любой метод, т.к. в почти во всех не константных методах есть участок где нарушен инвариант класса ):

void object::foo()
{
  this.fielda = create_a();
  this.fieldb = create_b();
  this.fieldc = create_c();
}

не обладая секцией finally или catch(...) где бы проверяется инвариант, сразу априори разносчик багов. Брошено исключение — получай объект в состоянии Х. Как тебе здесь поможет raii? Здесь помогут только костыли вроде бустового scope_exit.

J>Это все не нужно. "control flow of programs", написанных на исключениях (т.е. обеспечивающих по крайней мере базовую безопасность), анализировать как раз проще всего — они выполняются до конца или пока не вылетит исключение, причем не важно откуда (кроме nothrow-функций, естественно — они никогда ничего не должны бросать).

процедуры использующие goto анализировать проще всего, они выполняются до конца или пока не перейдут к какой-то метке. я надеюсь аналогия понятна. эксепшны конечно гораздо технологичней, но ломают control flow они не меньше чем goto, как при этом проще анализировать — я теряюсь в догадках.

J>Причем и в том, и в другом случае нам не нужно совершать дополнительных телодвижений по очистке и прочему, так как RAIIза всем проследит автоматически.

J>..поскипано...
J>Т.е. тотальный RAII.
нет кода с тотальным RAII (тем более он не везде применим, см. выше), нет и не будет, так же как нет кода с тотальной проверкой ошибок, и я более чем уверен что тотальная гарантия безопасности исключений ( базовая ) это гораздо, на порядки сложнее и многословнее тотальной же проверки ошибок.

J>И очень хорошо, что нету. Оставим finally недоязыкам типа Java, у которых нет RAII.
boost::scope_exit не от хорошей жизни писан

ioj>>поэтому ту же basic exception safety обеспечивать весьма геморройно, даже если тотально всё заворачивать в raii обвёртки
J>Не имею никакого геморроя с RAII-обертками, что я делаю не так?

ioj>>и даже если бы finally таки было, всё равно you're forced to obfuscate code to isolate the commit:
ioj>>Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it.

J>А тут мы плавно подменили basic exception safety на strong exception safety и сделали вид, что говорим об одном и том же — молодца!
ты увидел слово commit и сразу решил что это strong exception safety, нет, это не так, "commit" phase есть и у базовой гарантии, т.к. здесь говорится о логике сохранения постоянного состояния, т.е. об инварианте объекта, смотри ещё раз мой код выше.

J>"avoid requiring readers to understand the entire call graph" — нафиг никому не нужен the entire call graph. Потому что функция либо играет до конца, либо вылетает по ислючению. Всё.

см. про goto, это усложняет понимание кода

В общем я заканчиваю этот диалог, т.к. очевидно jazzer дартаньян, и всё у него не так как во всех виденных мной реальных проектах ( можете дать пруф на любой опенсорс проект-не библиотеку, где весь код обеспечивает базовую гарантию, я съем свою шляпу )


J>Где ты тут видишь obfuscate?
тут нет, в реальном мире да.

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


ioj>

ioj>void object::foo()
ioj>{
ioj>  this.fielda = create_a();
ioj>  this.fieldb = create_b();
ioj>  this.fieldc = create_c();
ioj>}
ioj>

Справедливости ради, надо сказать, что конкртено это можно написать и не так уж и криво...

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

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

X>как я понял, таки нет ни одного аргумента(для прикладного софта [1]) почему не нужно использовать исключения.
X>может быть, кто-то соизволит зарезюмировать сабж, и запечатлеть его в веках? (в блоге, или создать тему на форуме в режиме read-only)

X>[1]
X>для микроконтройлеров — размер бинаря увеличивается.
X>для компилятор с SJLJ — создается незначительный ран-тайм оверхед, который скорее является оправданием.

Главным и пожалуй единственным аргументом для меня является бритва Оккама. Т.к. на практике переход на исключения в 95% случаев увеличивает сложность и объём кода. В оставшиеся же 5% у нас исключения вполне используются, так что отказ совсем не "религиозный" и абсолютный. Однако глядя на это соотношения, я вполне могу понять компании, которые запрещают исключения в принципе...

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

_>Главным и пожалуй единственным аргументом для меня является бритва Оккама. Т.к. на практике переход на исключения в 95% случаев увеличивает сложность и объём кода.
на протяжении всего треда, я вижу лишь обратное. (в реальности-то, оно давно обосновано и доказано)
не понимаю, откуда у вас такие выводы, после 14ти страниц писанины...

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

X>на протяжении всего треда, я вижу лишь обратное. (в реальности-то, оно давно обосновано и доказано)
Смотри, ты пишешь же на С++ и с исключениями, и весь твой код обеспечивает как минимум базовую гарантию безопасности?

Если ты так или иначе работаешь в команде, то предлагаю тебе эксперимент.
Объявляешь приз в 100 баксов за каждый выявленный в твоём коде случай нарушения базовой гарантии и башляешь до тех пор, пока не расстанешься с иллюзиями

Или ты уже и так с ними расстался настолько, что не рискнёшь предложить коллегам по 100 баксов за каждый уникальный случай нарушения гарантий?..

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

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

X>>на протяжении всего треда, я вижу лишь обратное. (в реальности-то, оно давно обосновано и доказано)
E>Смотри, ты пишешь же на С++ и с исключениями, и весь твой код обеспечивает как минимум базовую гарантию безопасности?

E>Если ты так или иначе работаешь в команде, то предлагаю тебе эксперимент.
E>Объявляешь приз в 100 баксов за каждый выявленный в твоём коде случай нарушения базовой гарантии и башляешь до тех пор, пока не расстанешься с иллюзиями

E>Или ты уже и так с ними расстался настолько, что не рискнёшь предложить коллегам по 100 баксов за каждый уникальный случай нарушения гарантий?..

а тебе надо организовать приз за каждый пропущенный код ошибки.

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

X>на протяжении всего треда, я вижу лишь обратное. (в реальности-то, оно давно обосновано и доказано)
X>не понимаю, откуда у вас такие выводы, после 14ти страниц писанины...

Эээ, покажите хоть одно одно доказательство в этой теме. Тут собственно на эту тему вообще был ровно один кусок кода (то, что обсуждал Егор — это немного другая тема уже) — пример кривой реализации обработки ошибок через коды. И всё. Ни одного другого примера не было. Ни примера правильной реализации через коды, ни примера реализации через исключения, что бы сравнить их красоту и объём... И где вы тут увидели хоть какие-то реальные аргументы? Одно бросание теоретическими лозунгами.

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

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

X>>на протяжении всего треда, я вижу лишь обратное. (в реальности-то, оно давно обосновано и доказано)
X>>не понимаю, откуда у вас такие выводы, после 14ти страниц писанины...

_>Эээ, покажите хоть одно одно доказательство в этой теме. Тут собственно на эту тему вообще был ровно один кусок кода (то, что обсуждал Егор — это немного другая тема уже) — пример кривой реализации обработки ошибок через коды. И всё. Ни одного другого примера не было. Ни примера правильной реализации через коды, ни примера реализации через исключения, что бы сравнить их красоту и объём... И где вы тут увидели хоть какие-то реальные аргументы? Одно бросание теоретическими лозунгами.

Вообще-то вся темя — это обсуждение новомодного фреймвор.. нет, framewreck-а. Где из-за отказа от исключений внедрили передовые технологии "двухфазной инициализации" и революционный подход "объект после вызова конструктора может оказаться в черт-те каком состоянии". Правда, как оказалось, конструктор копирования инновациями не удостоили, поэтому ждем следующей версии.

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

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

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

E>>>Да хоть бы и пять. Вот прикинь, нажимаю я в ворде "проверить орфографию", в документе у меня русский и пара английских ID, ворд значит не смог загрузить английский спеллер и такой вообще орфографию не проверяет, или, вовсе отгружается по terminate.
L>>Сдуру можно и horseraddish сломать, чо. Только к теме отношения не имеет.

E>А разве ты что-то другое предлагал?..

Значит, я угадал. И почему я не удивлен?

Тебе еще читать следовало бы научиться, но, кажется, уже поздновато.

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


ioj>и это _не_ элементарно, это ровным счётом настолько же элементарно как и везде натыкать проверку возвращаемых значений, т.к. при возможности выброса исключения из любого метода, код вроде этого ( а фактически это любой метод, т.к. в почти во всех не константных методах есть участок где нарушен инвариант класса ):

ioj>

ioj>void object::foo()
ioj>{
ioj>  this.fielda = create_a();
ioj>  this.fieldb = create_b();
ioj>  this.fieldc = create_c();
ioj>}
ioj>

Что это за метод такой, который не принимает параметров и ничего не возвращает? Это private, который вызывается только из конструктора? Тогда никаких проблем, пусть себе кидает.
Если нет, то это — говнокод без вариантов, по сути версия метода Construct обсуждаемого фреймворка. Period.

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

L>>Откуда я знаю, какая у тебя на этот раз трава?
E>Разве этоя предлагал её в противогазе косить?..

Ну ты же так и ниасилил обосновать, зачем тебе нужен подобный фестиваль. Все, что мы услышали — это то, что ты "знаешь, как". Ну, знай дальше.

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


L>>Если объект уже существует — он по определению валиден. Не говоря уже о том, что проверять валидность объектов при перемещении — это несколько, какое бы подобрать слово, retarded.
E>Некоторые проверяют валидность при ВСЕХ операциях. Способствует надёжности кода, между прочим...

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

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

L>>Вообще-то я знаю могу доказать очевидное в три строчки, что в общем случае кидающего move-конструктора в вакууме это сделать невозможно. А вот ты, похоже, этого так и не понял сюда просто потроллить пришел. И я тоже ничуть не удивлен.

E>Забавно. Докажи, потому, что я знаю, как написать...

Ты сначала потрудись обосновать, зачем это надо, знаток ты наш. Утром деньги — вечером стулья.

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

E>Смотри, ты пишешь же на С++ и с исключениями, и весь твой код обеспечивает как минимум базовую гарантию безопасности?

E>Если ты так или иначе работаешь в команде, то предлагаю тебе эксперимент.
E>Объявляешь приз в 100 баксов за каждый выявленный в твоём коде случай нарушения базовой гарантии и башляешь до тех пор, пока не расстанешься с иллюзиями

E>Или ты уже и так с ними расстался настолько, что не рискнёшь предложить коллегам по 100 баксов за каждый уникальный случай нарушения гарантий?..
вы мусолите коня в вакууме. сами придумываете несуществующие проблемы, и сами их решаете. КПД 0%.
успехов.

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

_>Эээ, покажите хоть одно одно доказательство в этой теме. Тут собственно на эту тему вообще был ровно один кусок кода (то, что обсуждал Егор — это немного другая тема уже) — пример кривой реализации обработки ошибок через коды. И всё. Ни одного другого примера не было. Ни примера правильной реализации через коды, ни примера реализации через исключения, что бы сравнить их красоту и объём... И где вы тут увидели хоть какие-то реальные аргументы? Одно бросание теоретическими лозунгами.

доказательств в теме полно. начиная от несуществующих проблем, и заканчивая тотальным словоблудием о несуществующих проблемах.
повторюсь: КПД 0%

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

X>сами придумываете несуществующие проблемы, и сами их решаете. КПД 0%.

ах да, главное забыл..
решение несуществующих проблем мне мало интересно. но обработка С++ ошибок в Си-стиле, всегда более запутанная и "дырявая". и это факт.

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

L>Ну ты же так и ниасилил обосновать, зачем тебе нужен подобный фестиваль. Все, что мы услышали — это то, что ты "знаешь, как". Ну, знай дальше.

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

Я утверждаю, что код с гарантиями будет сложнее и неэффективнее кода без гарантий. Только и всего.
Но если тебе не интересно это обсуждение, то я не очень понимаю, что ты тут пишешьи зачем? Сожержание той пары книжек, из которых ты узнал про обработку исключений и про строгую и базовую гарантии ты пересказываешь не особо точно, примерно на уровне статьи из вики. Наверное для каких-то целей этого достаточно. Дальнейшее твоё участи в обсуждении какой смысл должно по твоему нести-то?

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

L>Впрочем, если у тебя даже при проверки валидности при всех операциях в контейнере оказываются невалидные объекты, то я умываю руки. Случай клинический.

Во-первых, при чём тут я?
Во-вторых, конкретно тут я отстаиваю простой и вовсе и не мой тезис, что надёжные программы пишут так, что предполагают, что ошибки могут быть везде.
В частности, в таких проектах принято использозвать такую библиотеку assert'ов, которая обеспечивает выполнение проверок и в продакшин сборке. При этом обработка провала assert'а состоит не в вызове terminate, а в чём-то более хитром...

Но в целом ты же умыл руки? И правильно сделал, по существу-то ты так ничего и не сказал, между прочим

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

L>>>Вообще-то я могу доказать очевидное в три строчки, что в общем случае кидающего move-конструктора в вакууме это сделать невозможно.
E>>Забавно. Докажи, потому, что я знаю, как написать...

L>Ты сначала потрудись обосновать, зачем это надо, знаток ты наш. Утром деньги — вечером стулья.

Ты врде как сообщил тут, что в общем случае кидающего move-конструктора невозможно соблюсти базовую гарантию для вектора. При этом грозился доказать в три строчки...

Можешь привести доказательство, или это было так, фигурально выражаясь, так сказать?..

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

[]

_>А я как раз наоборот очень редко встречаю ситуации, когда требуется именно "конец работы в случае ошибки" (а только в таких случаях исключения действительно эффективны и собственно для этого они и создавались).

Это не плохое, не годное понимание концепции "для этого они и создавались".

P>>Прикол в том, что при таких сценариях работы "ошибки формата" перестают быть исключительными ситуациями, а становятся частью основной логики, т.е. об исключениях в терминах С++ речь уже не идет. =)

_>Ага, и я о том же. Только у меня класс ошибок, которые "перестают быть исключительными ситуациями" явно намного шире. )))

Вполне возможно.
Мой поинт в том, что тот уровень обработки ошибок, который обеспечивает "сферический программист в вакууме" за которого так болеет тролльErop, с помощью исключений обеспечивается проще и приятнее.
Ясное дело, когда начинаются holy wars, все внезапно пишут код не иначе как для "ядерных реакторов" (tm), и начинают сыпать терминами про вилидность\верифицируемость\гарантии etc.