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

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

J>>Это противоречит моему опыту. Basic exception safety достигается элементарно.
E>Это говорит о том, что либо твоё "элементарно" -- это малодостижимый уровнь для типичного программиста, либо о том, что мы с тобой как-то по-разному, понимаем что такое "basic exception safety", либо ты не имеешь дела никогда со сложными структурами данных, либо ты лукавишь...


E>Если так, то в качестве примера, нарисуй нам горантирующий basic exception safety метод std::vector, который переаллоцирует буфер, и при этом поддерживает move-семантику соержимого...
E>Пусть у move-конструктора элемента тоже будет "basic exception safety", а у деструктора гарантия невылета...

А в чем, собственно, проблема? Если move конструктор не кидается (а с чего бы ему, по логике, кидаться?) то все элементарно. Если кидается, то тоже элементарно, но про move семантику придется забыть. Здесь, например.

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

E>Я верно же понимаю, что под "basic exception safety" понимают гарантию того, что при вылете исключения, могут быть сторонние эффекты, но не могут нарушаться инварианты и не случится утечек?..
Да.

E>Если так, то в качестве примера, нарисуй нам гарантирующий basic exception safety метод std::vector, который переаллоцирует буфер, и при этом поддерживает move-семантику соержимого...
E>Пусть у move-конструктора элемента тоже будет "basic exception safety", а у деструктора гарантия невылета...

Т.е. предполагается, что move-конструктор может бросить исключение? И нафига он такой нужен, если он фактически убивает оба объекта?

Но даже если мы имеем дело с патологией таким больным на всю голову move-конструктором, безопасность достигается элементарно: очисткой контейнера в случае исключения. Либо очисткой только непереместившейся части.
В обоих случаях не будет утечек и все инварианты будут выполнены.

E>Для начала придумай, например, как тестированием гарантировать, что ты покрыл все варианты потоков исполнения кода?..
А зачем это надо гарантировать?

J>>И не надо. Код надо писать, имея в виду, что почти любая функция может бросить исключение. Т.е. тотальный RAII.

E>Это вообще никак не гарантирует "basic exception safety"...
J>>Не имею никакого геморроя с RAII-обертками, что я делаю не так?
E>Ты всё делаешь так.
E>Покажи нам мастер-класс, пожалуйста. На примере переаллокации буфера вектора, например
Для очистки-то вектора? Ты точно сам не сможешь?

J>>Опять же, утверждение про obfuscate противоречит моему опыту.
E>Теперь давай напишем структуру, поля которой -- A.
E>Для неё как будем сильную безопасность обеспечивать?..
Так же
E>А теперь небольшую базу данных (метров на триста, например), в памяти...
Мы вроде про obfuscate говорили, не? А не про расход памяти и т.п?
Но если ты хочешь оптимизировать, то придется забыть о концептуальной чистоте кода — оптимизированные решения почти всегда выглядят на порядок сложнее, чем наивный неоптимизированный код. Duff's device будет хорошим примером.

You will always get what you always got
  If you always do  what you always did

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

[]

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

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

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

L>Если кидается, то тоже элементарно, но про move семантику придется забыть.
Я просил таки с move-семантикой, коллега...

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

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

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

более менее плотно с исключениями я познакомился в начале 2000ных -- это было время жутких багов с поддержкой исключений в gcc/egcs %)
наш софт мы тестировали на снапшотах этих компиляторов: с одной стороны хотелось нормальной поддержки шаблонов, а с другой стороны время от времени они там вносили новые баги и легко могло получиться, что в новом снапшоте в критическом месте исключение просто не ловится catch блоком %)

через некоторое время egcs и gcc опять слились воедино, и поддержка исключений более менее стабилизировалась. но реализация была на SJLJ (дающая оверхед просто на входе в try блок), что в определенных случаях было критично и приходилось запариваться...

в gcc3 появилась обработка исключений основанная на таблицах... но в ранних версиях ессно безбожно глючная (поэтому мы собирали свой софт самосборной gcc3 с включенными sjlj при конфигурении -- они хоть как-то работали и были известны подводные камни). gcc3 мы оч любили за то, что в этом релизе девелоперы плотно поработали над кодогенерацией для AMD и наш софт на Athlon'ах XP работал на 20-30% быстрее чем на пнях тех лет.

только примерно с версии 3.4 (после многих тщательных тестов) мы стали бесстрашно использовать исключения по полной программе. примерно тогда же бенчмарки показали что запариваться с кодами возврата уже бессмысленно -- исключения куда удобнее и не несут уже жуткого оврхеда ни на подготовку (try) ни на обработку (catch)... особенно принимая во внимание вопрос читабельности и сопровождения кодовой базы в несколько миллионов строк. больше я тестов на скорость исключений не делал и поныне использую только исключения...

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

J>Т.е. предполагается, что move-конструктор может бросить исключение? И нафига он такой нужен, если он фактически убивает оба объекта?

Почему нет?

J>В обоих случаях не будет утечек и все инварианты будут выполнены.
Ну вот и приведи код, и мы потом его сравним с кодом, который без гарантий, насколько сложнее оно, проще и т. д...

J>А зачем это надо гарантировать?
Некоторым этого хочется зачем-то...

E>>Покажи нам мастер-класс, пожалуйста. На примере переаллокации буфера вектора, например
J>Для очистки-то вектора? Ты точно сам не сможешь?
Ну тогда покажи то же но про два параллельных массива, например...

E>>Для неё как будем сильную безопасность обеспечивать?..
J>Так же
В смысле "так же"? Ты код давай.

J>Мы вроде про obfuscate говорили, не? А не про расход памяти и т.п?
Ну, если нам на производительность плевать, то на кой нам вообще С++? Шарп и вперёд и с песнями о том, что память больше не ресурс...

J>Но если ты хочешь оптимизировать, то придется забыть о концептуальной чистоте кода — оптимизированные решения почти всегда выглядят на порядок сложнее, чем наивный неоптимизированный код. Duff's device будет хорошим примером.

1) Duff's device на сегодня является писсимизацией.
2) Ничего клнцептуально сложного в нём, тем не менее нет, гарантии безопасности -- зна-а-а-ачительно сложнее концептуально
Последнее, но главное) Мы собственно уже моем считать, что я тебя убедил, что концепуально чистый прямой код на кодах возврата ЭФФЕКТИВНЕЕ такого же на исключениях?
И при этом ещё и использует более простые концепции?
{hr]Я не являюсь противником использования исключений. Но я являюсь противником концепции базовой гарантии безопасности. IMHO, она слишком оторванна от реальности и вообще нелогична.
Но это таки отдельный хитрый разговор.
То есть я думаю, что можно выработать такую гарантию, что она будет ПОМОГАТЬ, а не МЕШАТь писать концептуально чистый эффективный код. Но даже если ты её и выработаешь, то тебе будет трудно навязать её всему сообществу. С другой стороны, тебе негде будет иначе брать сотрудников, которые так умеют делать. То есть тебе прийдётся их вообще-то переучивать, что препятствует найму людей с большим опытом, кроме всего прочего.
Та же проблема, что с велосипедами, но только на уровне приёмов программирования, что ещё труднее формально навязать и проверить.
Так что я вполне понимаю конторы, которые говорят, что типа просто не надо вообще исключений и точка.

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

L>Мое HO — данный конкретный пример как раз показывает, что такое исключительная ситуация. Плагин добавляет контролы. Если добавление какого-то контрола обламывается, то это именно исключительная ситуация без разговоров и самая правильная стратегия в данном случае — прекратить инициализацию вообще и не пытаться умничать.


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

Пример. ОТкрываешь ты НА ТЕЛЕФОНЕ прилажение для просмотра ТВ -- а у тебя подписка на ряд каналов закончилась. Думаешь не надо запускать?..

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

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

L>>Если кидается, то тоже элементарно, но про move семантику придется забыть.
E>Я просил таки с move-семантикой, коллега...

Неправильный Вы форум выбрали для вопросов о скрещивании ежей с ужами, коллега

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

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

L>>Да есть одна такая. На букву Г как раз.
X>понятно-понятно. не знал, что там тоже отказались от исключений. а говорят, что в Г работают только адекваты =)

вот недавно познакомился с внутренностями leveldb от этих адекватов. библа собирается без флага -fno-exceptions -- т.е. потенциально вылететь может да хотябы std::bad_alloc на многочисленных new, вставках в контейнеры или работе со строками... но адекваты ничего не ловят и даже (если вдруг захочется похакать их Makefile и вставить таки -fno-exceptions) нихера не проверяют что new что-то возвращает им валидное... RAII очевидно тоже забанен адекватами: ни каких smart указателй или lock_guardов! ВСЕ б***ь руками делается!

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

P>Таких сценариев "просто не выполняет какую-то команду там дальше" исчезающе мало.

Например, мы переоткрываем редакор или браузер и хотим восстановить открытые документы, как при закрытии...

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

L>Неправильный Вы форум выбрали для вопросов о скрещивании ежей с ужами, коллега
Я верно понимаю, что ты не знаешь как это селать просто?..
Почему я не удивлён?

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

Z>... потенциально вылететь может да хотябы std::bad_alloc на многочисленных new, вставках в контейнеры или работе со строками... но адекваты ничего не ловят и даже (если вдруг захочется похакать их Makefile и вставить таки -fno-exceptions) нихера не проверяют что new что-то возвращает им валидное... RAII очевидно тоже забанен адекватами: ни каких smart указателй или lock_guardов! ВСЕ б***ь руками делается!

жуть какая
недавно я патчил V8, а конкретно — v8-shell. там я тоже заметил, что результат new не проверяется. но, подумал, что возможно конкретно этот участок кода написали лишь-бы-как. а получается что нет =)
в итоге, повставлял assert`ы.

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

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

L>>Неправильный Вы форум выбрали для вопросов о скрещивании ежей с ужами, коллега
E>Я верно понимаю, что ты не знаешь как это селать просто?..
E>Почему я не удивлён?

А можно посмотреть пример объекта, у которого move-конструктор кидает исключения? Желательно с пояснением зачем там кидание и зачем вообще в таком случае пользоваться move-семантикой. Это не троллинга ради, я действительно с ходу не смог нафантазировать такого примера и теперь меня мучает любобытство.

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

R>А можно посмотреть пример объекта, у которого move-конструктор кидает исключения? Желательно с пояснением зачем там кидание и зачем вообще в таком случае пользоваться move-семантикой. Это не троллинга ради, я действительно с ходу не смог нафантазировать такого примера и теперь меня мучает любобытство.

присоединяюсь к вопросу.
так же, не смог придумать ситуации, когда move-конструктору нужно кидать исключение.

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

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

L>>Мое HO — данный конкретный пример как раз показывает, что такое исключительная ситуация. Плагин добавляет контролы. Если добавление какого-то контрола обламывается, то это именно исключительная ситуация без разговоров и самая правильная стратегия в данном случае — прекратить инициализацию вообще и не пытаться умничать.

E>Самая правильная -- иметь возможность управлять этим на уровне конфигуратора приложения.
E>Ну там критические плагины, например, не грузить нельзя, а просто свистелки с перделками -- какие проблемы?

Это один плагин. Читай внимательнее.

E>Проблема с кучей мессэдж боксов о незагрузки или неоткрытии чего-то -- вообще интерфейскная и к теме обработки исклюнией отношения не имеет...

Имеет. Это звенья одной цепи. Тут недодумали, там не заметили, тут понядеялись.

E>Пример. ОТкрываешь ты НА ТЕЛЕФОНЕ прилажение для просмотра ТВ -- а у тебя подписка на ряд каналов закончилась. Думаешь не надо запускать?..

В вышеприведенном случае скорее — включаешь телевизор, а кнопки "сделать потише" и "выключить" нет.

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

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

E>Я верно понимаю, что ты не знаешь как это селать просто?..

Пожалуйста, сначала разумную причину делать это.

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

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

L>>Неправильный Вы форум выбрали для вопросов о скрещивании ежей с ужами, коллега
E>Я верно понимаю, что ты не знаешь как это селать просто?..

Нет. Я не понимаю, зачем это в принципе нужно пытаться сделать. Могу предложить ради разнообразия еще траву покосить в противогазе — занятие примерно одного рода по осмысленности.

E>Почему я не удивлён?

Откуда я знаю?

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

R>А можно посмотреть пример объекта, у которого move-конструктор кидает исключения? Желательно с пояснением зачем там кидание и зачем вообще в таком случае пользоваться move-семантикой. Это не троллинга ради, я действительно с ходу не смог нафантазировать такого примера и теперь меня мучает любобытство.

Ну, например, можно представить себе объект все действия с которым логгируются...
Или можно представить себе конструктор перемещения, который чем-то вроде assert'а кидающего logic_error, проверяет валидность перемещаемого объекта...

Но в целом это не важно.
Я же просил просто пример функции написать, раз это так просто всё якобы.

Если кому-то кажется, что пример с resize вектора надуманный, то нет проблем, покажите структуру из двух параллельных контейнеров, которая обеспечивает хотя бы базовую гарантию, а лучше строгую

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

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

L>Нет. Я не понимаю, зачем это в принципе нужно пытаться сделать. Могу предложить ради разнообразия еще траву покосить в противогазе — занятие примерно одного рода по осмысленности.

И как трава? Забористая?

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

L>Мое HO — данный конкретный пример как раз показывает, что такое исключительная ситуация. Плагин добавляет контролы. Если добавление какого-то контрола обламывается, то это именно исключительная ситуация без разговоров и самая правильная стратегия в данном случае — прекратить инициализацию вообще и не пытаться умничать. Никогда не встречали программы, которые при каких-либо сценариях выдавали по полторы сотни мессаджбоксов друг за другом, каждый с многозначительным сообщением типа "ошибка инициализации"?

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

L>Здесь исключение — наиболее натуральный вариант. Выход по первому error, в принципе, тоже сработает, но получился лес if-ов.

Я в таких случаях инвертирую логику и получается просто много return, a не лесенка if-ов. Это я естественно про те случаи, где не использую исключения.

L>Кстати, из кода очевидно, что код этот никак не тестировался для негативного случая.

Да код вообще дикий. Но тем не менее никто тут так и не решился показать как бы он написал этот код через исключения. )))