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

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

M>>Прошу воспринимать мой пост как рекомендации . Best practices

N>1. Это невозможно воспринимать как "best practices", пока есть массовые случаи противоречия постулатам (типа "RAII правильно, всё остальное не нужно"). Если Ваш случай проще... что ж, могу просто позавидовать. Мне такая простота недоступна, и "колбаса" нужна.
Я не навязываю, даже внутри нашей команды я бы не стал навязывать свое мнение своим коллегам.


N>2. По процедуре: Вы злоупотребляете, jIMHO, срезанием квотинга. Ни в почте, ни в моём показе (я воспринимаю только линейный показ, дерево в таких форумах для меня громоздко и неудобно) непонятно, к чему относятся замечания. Особенно предыдущее про "звучат заблуждениями".
Я предполагаю что ветка читается последовательно и всегда можно вернуться на ступеньку. Спасибо , попробую исправиться.

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

N>>} finally {
N>>что, по-моему, в разы более ясно для понимания.
M>А по моему это довольно архаичный стиль и уж точно хуже для понимания. Спорить по этому поводу я не готов и нет желания, останемся при своих. Для меня вполне узнаваемым будет код с объектами transaction (command ми т.п.).

Архаичным он наверняка не может быть, за отсутствием finally до языков с обработкой исключений, и в C++ вообще:) А спорить — а что тут спорить, если сам Страуструп сказал "никаких сусликов"? Несмотря на то, что большинство других допускают finally если даже есть немедленная деструкция (как в питоне через счётчик и __del__).

N>>Может, в ряде задач так оно и будет. А вот в построении, например, сетевого взаимодействия со сложной логикой без достаточного количества обработчиков (значительно больше, чем на пальцах) не обойтись, потому что
M>Не вижу причеин по которым сетевые взаимодействия могут иметь свою специфику в плане обработки исключений.

Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере:))) Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.

netch80 wrote:
> try {
> подготовка обстановки;
> работа;
> } finally {
> восстановление обстановки;
> }
Проблема тут в том, что можно забыть добавить нужное
cleanup-действие в "восстановление обстановки". А учитывая, что
exception conditions часто не тестируются и проблемы от утекающих
ресурсов могут быть заметны не сразу — баг может жить очень долго.

В этом отношении RAII намного лучше — мы уже не можем забыть освободить
ресурс (ну если _очень_ не захочем).

Количество необходимых служебных классов, на практике, у меня получается
очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.

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

M>Больше похоже что обычные рабочие ситуации которых из которых и состоит работа вы проецируете на каеи то свои мании. Это естествено что кто то чего то не знает, а другой знает.

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

>> try {
>> подготовка обстановки;
>> работа;
>> } finally {
>> восстановление обстановки;
>> }
C>Проблема тут в том, что можно забыть добавить нужное
C>cleanup-действие в "восстановление обстановки".
C>В этом отношении RAII намного лучше — мы уже не можем забыть освободить
C>ресурс (ну если _очень_ не захочем).

это как раз ещё один случай, где очень удобны лямбды. вот как это выглядит в хаскеле:

bracket (openFile filename) closeFile \$ handle -> do
    x <- readLn handle
    ...

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

withFile filename = bracket (openFile filename) closeFile

withFile "autoexec.bat" \$ handle -> do
    x <- readLn handle
    ...

плюс к этому, логика try/finally жёстко задана в компиляторе, а при использовании функций/классов в них легкко можно добавить свои погремушки. я например недавно таким образом добавил обработку ^Breal

C>Количество необходимых служебных классов, на практике, у меня получается
C>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.

а как выглядит этот код? как я понимаю, те же лямбды, только сахар не такой сладкий?

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

C>netch80 wrote:
>> try {
>> подготовка обстановки;
>> работа;
>> } finally {
>> восстановление обстановки;
>> }
C>Проблема тут в том, что можно забыть добавить нужное
C>cleanup-действие в "восстановление обстановки". А учитывая, что
C>exception conditions часто не тестируются и проблемы от утекающих
C>ресурсов могут быть заметны не сразу — баг может жить очень долго.

Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO), а как по мне — даже значительно проще (вот тут уже IMHO), потому что логика записана явно и линейно, а не через какие-то находящиеся за несколько экранов деструкторы.

Вот если бы было много мест выхода — да, там элементарно забыть нужное восстановление (и это очень распространённая ошибка). Но здесь явно один finally, а не много.

C>В этом отношении RAII намного лучше — мы уже не можем забыть освободить
C>ресурс (ну если _очень_ не захочем).

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

C>Количество необходимых служебных классов, на практике, у меня получается
C>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.

Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости.

N>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO),

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

когда у тебя класс, который занят только следжкой за этим ресурсом — там пропуск освобождения сразу бросается в глаза. в моём примере на хаскеле ещё хуже — это просто не пропустит система типов

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

N>>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO),

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

Ну вот потому я и ограничил эту часть мнения явной меткой "IMHO". Вам удобнее видеть эти действия в классе рядом — не вопрос. Но мне сама вынесенность класса из основного кода мешает. А разделение кодом обработки... если функция сделана по рекомендациям лучших собаководов (не более полутора экранов, или даже не более 25 строк) — оно и незаметно.

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

BZ>а как выглядит этот код? как я понимаю, те же лямбды, только сахар не такой сладкий?

Со сладким сахаром есть в D Programming Language смотри scope exit тут http://www.digitalmars.com/d/exception-safe.html

BZ>>а как выглядит этот код? как я понимаю, те же лямбды, только сахар не такой сладкий?

FR>Со сладким сахаром есть в D Programming Language смотри scope exit тут http://www.digitalmars.com/d/exception-safe.html

ну вот собственно он и говорит ровно о том же:

Both solutions work, but both have drawbacks. The RAII solution often requires the creation of an extra dummy class, which is both a lot of lines of code to write and a lot of clutter obscuring the control flow logic. This is worthwhile to manage resources that must be cleaned up and that appear more than once in a program, but it is clutter when it only needs to be done once. The try-finally solution separates the unwinding code from the setup, and it can often be a visually large separation. Closely related code should be grouped together.

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

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

BZ>хотя думаю, что слаще было бы это сделать на клозурах. в руби, например, такое возможно

А зачем там замыкания, scope exit по сути специализированный блок кода (на руби же через них и будет).

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

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

BZ>>хотя думаю, что слаще было бы это сделать на клозурах. в руби, например, такое возможно

FR>А зачем там замыкания, scope exit по сути специализированный блок кода (на руби же через них и будет).

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

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

BZ>разница исключительно в том, что для решения 10 разных порблем лучше ввести в язык один универсальный механизм, чем 10 специфичных

Главное чтоб он был удобным, иначе пользоваться не будут, или все равно разобьют на 10 специфичных.

ЗЫ Хотя, больше к словам придирка .

BZ>>разница исключительно в том, что для решения 10 разных порблем лучше ввести в язык один универсальный механизм, чем 10 специфичных

DC>Главное чтоб он был удобным, иначе пользоваться не будут, или все равно разобьют на 10 специфичных.

ортогональность сама по себе — очень важна для языка. просто представь себе описание языка скажем на 100 и 1000 страниц. или 1000 и 10000

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

BZ>>>разница исключительно в том, что для решения 10 разных порблем лучше ввести в язык один универсальный механизм, чем 10 специфичных

DC>>Главное чтоб он был удобным, иначе пользоваться не будут, или все равно разобьют на 10 специфичных.

BZ>ортогональность сама по себе — очень важна для языка. просто представь себе описание языка скажем на 100 и 1000 страниц. или 1000 и 10000

Да чего там. Стандарты С++ и Haskell сравнить хотя бы.

ЗЫ Тема уже переросла в "Казалось бы, причем здесь Хаскел?" .

DC>ЗЫ Тема уже переросла в "Казалось бы, причем здесь Хаскел?" .

как и любая другая с моим участием. не дай бог, придёт Влад

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

DC>>ЗЫ Тема уже переросла в "Казалось бы, причем здесь Хаскел?" .

BZ>как и любая другая с моим участием. не дай бог, придёт Влад

Та да, конструктив пропадет, зато истину иска будем .

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

C>>Проблема тут в том, что можно забыть добавить нужное
C>>cleanup-действие в "восстановление обстановки". А учитывая, что
C>>exception conditions часто не тестируются и проблемы от утекающих
C>>ресурсов могут быть заметны не сразу — баг может жить очень долго.
N>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO), а как по мне — даже значительно проще (вот тут уже IMHO), потому что логика записана явно и линейно, а не через какие-то находящиеся за несколько экранов деструкторы.
Правда — тебе надо вернуться вниз и дописать код в finally. Это элементарно можно забыть (видел не раз). Деструкторы вообще пофиг где находятся — нам их видеть не обязательно.

C>>В этом отношении RAII намного лучше — мы уже не можем забыть освободить
C>>ресурс (ну если _очень_ не захочем).
N>Мы можем его не записать в классе, сконструированном специально для данной частной обработки, и (повторюсь) это сделать легче и контролировать сложнее, чем в случае кода, находящегося в той же функции.
Ничуть не сложнее. Запрещаете явные вызовы close/destroy/free — и все магически поправляется очень быстро. Лично пробовал на своей команде.

C>>Количество необходимых служебных классов, на практике, у меня получается
C>>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.
N>Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости.
Мда. http://www.ddj.com/dept/cpp/184403758

FILE *fl=fopen(...);
ON_BLOCK_EXIT(fclose,fl);

//blah-blah

Заметь, что fopen и ON_BLOCK_EXIT находятся рядом. Забыть его написать уже заметно сложнее — код линейный и не надо отвлекаться на переход в finally.

Естественно, если file часто используется — пишем обертку (или берем отсюда: http://www.codeproject.com/vcpp/stl/boostsp_handleref.asp ):

typedef boost::shared_ptr<FILE> file_hndl_t;
inline file_hndl_t wrapFile(FILE *fl)
{
    return file_hndl_t(fl,&fclose);
}

...
file_hndl_t fl=wrapFile(fopen(...));

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

C>>Количество необходимых служебных классов, на практике, у меня получается
C>>очень небольшим. ON_BLOCK_EXIT + boost::bind справляются с 90% случаев.
BZ>а как выглядит этот код? как я понимаю, те же лямбды, только сахар не такой сладкий?
Смотри остальные сообщения. Да, bind — это простейший случай лямбд.

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

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

C>>>Проблема тут в том, что можно забыть добавить нужное
C>>>cleanup-действие в "восстановление обстановки". А учитывая, что
C>>>exception conditions часто не тестируются и проблемы от утекающих
C>>>ресурсов могут быть заметны не сразу — баг может жить очень долго.
N>>Неправда. Если место очистки только одно — записать в finally нужное восстановление не сложнее, чем в сделанном для этого классе (тут безо всяких IMHO), а как по мне — даже значительно проще (вот тут уже IMHO), потому что логика записана явно и линейно, а не через какие-то находящиеся за несколько экранов деструкторы.
C>Правда — тебе надо вернуться вниз и дописать код в finally. Это элементарно можно забыть (видел не раз).

Забыть, что данные действия надо вернуть назад, ещё проще — тогда не надо создавать никаких обёрточных классов.:))

C> Деструкторы вообще пофиг где находятся — нам их видеть не обязательно.

Что, в другом файле, чем конструктор? Вот за это точно канделябром.

N>>Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости.
C>Мда. http://www.ddj.com/dept/cpp/184403758

Ага, ну если такой изврат, то ещё как-то терпимо.