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

E>и при чём тут оптимизация и исключения?
Это меня переглючило, фразу наоборот понял.

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


ХГ>>Первое, что в голову приходит — это сортировка. Ну и вообще шаблоны + встраивание пользовательского предиката в C++ vs. функция + коллбэк в C.

D>в некоторых производительных библиотеках на С сортировку делали макросами

Ну вообще-то существуют задачи и по неприятнее сортировки. С макросами там будет аццкий ад, а с шаблонами — терпимо.

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

A>>>не было бы RAII — был бы finally или on error и те же самые исключения
Ops>>Это что же, весь стек вызовов оборачивать? Ужоснах.

P>ну в Java/C# нет RAII — там ёжики грызут кактус в виде finaly, using, try with resources, или как их там.
P>мне их жалко, честно

Вот кстати все не так однозначно, если вспомнить про исключения из деструкторов. Может finaly то и правильнее.

Здравствуйте, Хон Гильдон, Вы писали:

A>>>>не было бы RAII — был бы finally или on error и те же самые исключения
Ops>>>Это что же, весь стек вызовов оборачивать? Ужоснах.
P>>ну в Java/C# нет RAII — там ёжики грызут кактус в виде finaly, using, try with resources, или как их там.
P>>мне их жалко, честно
ХГ>Вот кстати все не так однозначно, если вспомнить про исключения из деструкторов. Может finaly то и правильнее.

всё однозначно, RAII рулит.
1. без RAII в КАЖДОЙ функции которая как-то создаёт/удаляет ресурсы нужно лепить try/using_with_resources/или_как_их_там
2. С RAII, когда ты используешь какой-либо объект, тебе абсолютно пофиг есть ли в нём какие-либо ресурсы или нет. Без RAII ты должен проверять, есть ли у этого объекта ресурсы или нет, так как если есть, то сам этот объект становится ресурсом (весело будет, когда ресурсы добавятся в объект после того, как его уже используют) — и всё, вся инкапсуляция летит к хреням собачим.

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


P>всё однозначно, RAII рулит.
P>1. без RAII в КАЖДОЙ функции которая как-то создаёт/удаляет ресурсы нужно лепить try/using_with_resources/или_как_их_там
P>2. С RAII, когда ты используешь какой-либо объект, тебе абсолютно пофиг есть ли в нём какие-либо ресурсы или нет. Без RAII ты должен проверять, есть ли у этого объекта ресурсы или нет, так как если есть, то сам этот объект становится ресурсом (весело будет, когда ресурсы добавятся в объект после того, как его уже используют) — и всё, вся инкапсуляция летит к хреням собачим.

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

Здравствуйте, Хон Гильдон, Вы писали:

ХГ>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск. И как результат из деструктора летит исключение, и опять и всё летит к хреням собачим.

не честно, удар ниже пояса

Здравствуйте, Хон Гильдон, Вы писали:

ХГ>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.

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

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


ХГ>>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.

P>а если без шуток, то эта проблема от того, что в этом деструкторе происходит попытка захвата новых ресурсов.

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

P>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.

Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.

P>в описанном же примере деструктор получает объект в "хорошем" состоянии, и сам же его портит.

Мало ли, что там должно быть в идеале. На практике, к вводу-выводу RAII плохо применим. Приходится приделывать метод close и дергать его руками.

Здравствуйте, Хон Гильдон, Вы писали:

ХГ>>>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.
P>>а если без шуток, то эта проблема от того, что в этом деструкторе происходит попытка захвата новых ресурсов.
ХГ>Никакого захвата новых ресурсов, только работа с уже захваченными.

попытка захватить новое место на диске во время flush'а

P>>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.
ХГ>Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.

легко, flush на каждой записи.
либо вообще маразм в виде постоянного close+repoen

P>>в описанном же примере деструктор получает объект в "хорошем" состоянии, и сам же его портит.
ХГ>Мало ли, что там должно быть в идеале. На практике, к вводу-выводу RAII плохо применим. Приходится приделывать метод close и дергать его руками.

да, это один из популярных вариантов.

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


ХГ>>>>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.
P>>>а если без шуток, то эта проблема от того, что в этом деструкторе происходит попытка захвата новых ресурсов.
ХГ>>Никакого захвата новых ресурсов, только работа с уже захваченными.

P>попытка захватить новое место на диске во время flush'а

Это не ресурс в терминах RAII. Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?

P>>>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.
ХГ>>Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.

P>легко, flush на каждой записи.

Это ничего не гарантирует. Например, у нас стрим вокруг ssl. При "освобождении" данного ресурса хорошо бы ему сделать shutdown.

P>либо вообще маразм в виде постоянного close+repoen

Какое это отношение имеет к RAII? В смысле, какой именно ресурс мы захватываем в конструкторе и освобождаем в деструкторе?

Здравствуйте, Хон Гильдон, Вы писали:

ХГ>>>>>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.
P>>>>а если без шуток, то эта проблема от того, что в этом деструкторе происходит попытка захвата новых ресурсов.
ХГ>>>Никакого захвата новых ресурсов, только работа с уже захваченными.
P>>попытка захватить новое место на диске во время flush'а
ХГ>Это не ресурс в терминах RAII.

смотря как смотреть. файл ведь в деструкторе тоже не удаляется.

ХГ>Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?

да пофиг что и как, у "правильного" объекта поломка должна быть возможна только до деструктора.
другие "неправильные" тоже могут со-существовать.

P>>>>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.
ХГ>>>Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.
P>>легко, flush на каждой записи.
ХГ>Это ничего не гарантирует. Например, у нас стрим вокруг ssl. При "освобождении" данного ресурса хорошо бы ему сделать shutdown.

делаешь всё что нужно для поддержания объекта в destructable-non-throwable state.

P>>либо вообще маразм в виде постоянного close+repoen
ХГ>Какое это отношение имеет к RAII? В смысле, какой именно ресурс мы захватываем в конструкторе и освобождаем в деструкторе?

file handle (я же написал — reopen), file name

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

ХГ>>>>>>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.
P>>>>>а если без шуток, то эта проблема от того, что в этом деструкторе происходит попытка захвата новых ресурсов.
ХГ>>>>Никакого захвата новых ресурсов, только работа с уже захваченными.
P>>>попытка захватить новое место на диске во время flush'а
ХГ>>Это не ресурс в терминах RAII.

P>смотря как смотреть. файл ведь в деструкторе тоже не удаляется.

Почему именно удаление? Здесь мы вообще не имеем обратной операции.


ХГ>>Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?

P>да пофиг что и как, у "правильного" объекта поломка должна быть возможна только до деструктора.
P>другие "неправильные" тоже могут со-существовать.

Осталось только научиться писать такие вот "правильные" стримы. Пока никто (ну кроме тебя, конечно) не умеет.

P>>>>>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.
ХГ>>>>Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.
P>>>легко, flush на каждой записи.
ХГ>>Это ничего не гарантирует. Например, у нас стрим вокруг ssl. При "освобождении" данного ресурса хорошо бы ему сделать shutdown.

P>делаешь всё что нужно для поддержания объекта в destructable-non-throwable state.

Как только напишешь "правильный" ssl-stream, который так себя и ведет, я тебе поверю


P>>>либо вообще маразм в виде постоянного close+repoen
ХГ>>Какое это отношение имеет к RAII? В смысле, какой именно ресурс мы захватываем в конструкторе и освобождаем в деструкторе?

P>file handle (я же написал — reopen), file name

Это сейчас ты написал reopen, а в прошлый раз было repoen Но все равно ничего не понял. Что за reopen, что он должен делать, при чем тут file name? Пример можешь привести, как это все должно работать? Что именно будет освобождаться в деструкторе и почему того же поведения нельзя добиться без деструктора?

Здравствуйте, Хон Гильдон, Вы писали:

ХГ>>>Никакого захвата новых ресурсов, только работа с уже захваченными.

P>>попытка захватить новое место на диске во время flush'а

ХГ>Это не ресурс в терминах RAII. Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?

Если честно, то за подобные выходки из деструкторов нужно сначала долго бить сапогами в живот, а потом разжаловать в старшие помощники младших черпальщиков в ассенизаторском обозе при холерных бараках. Безотносительно того, что захватываем.

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

ХГ>>>>Никакого захвата новых ресурсов, только работа с уже захваченными.

P>>>попытка захватить новое место на диске во время flush'а

ХГ>>Это не ресурс в терминах RAII. Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?

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

Попробуй объяснить это авторам стандартной библиотеки Да заодно и бустоводам.

Здравствуйте, Хон Гильдон, Вы писали:

ХГ>>>>>>>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.
P>>>>>>а если без шуток, то эта проблема от того, что в этом деструкторе происходит попытка захвата новых ресурсов.
ХГ>>>>>Никакого захвата новых ресурсов, только работа с уже захваченными.
P>>>>попытка захватить новое место на диске во время flush'а
ХГ>>>Это не ресурс в терминах RAII.
P>>смотря как смотреть. файл ведь в деструкторе тоже не удаляется.
ХГ>Почему именно удаление? Здесь мы вообще не имеем обратной операции.

это смотря как flush реализован

ХГ>>>Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?
P>>да пофиг что и как, у "правильного" объекта поломка должна быть возможна только до деструктора.
P>>другие "неправильные" тоже могут со-существовать.
ХГ>Осталось только научиться писать такие вот "правильные" стримы. Пока никто (ну кроме тебя, конечно) не умеет.

а что тебе не понятно?

P>>>>>>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.
ХГ>>>>>Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.
P>>>>легко, flush на каждой записи.
ХГ>>>Это ничего не гарантирует. Например, у нас стрим вокруг ssl. При "освобождении" данного ресурса хорошо бы ему сделать shutdown.
P>>делаешь всё что нужно для поддержания объекта в destructable-non-throwable state.
ХГ>Как только напишешь "правильный" ssl-stream, который так себя и ведет, я тебе поверю

чему ты поверишь?
то, что RAII лучше тех огрызков в Java/C#?

P>>>>либо вообще маразм в виде постоянного close+repoen
ХГ>>>Какое это отношение имеет к RAII? В смысле, какой именно ресурс мы захватываем в конструкторе и освобождаем в деструкторе?
P>>file handle (я же написал — reopen), file name
ХГ>Это сейчас ты написал reopen, а в прошлый раз было repoen Но все равно ничего не понял. Что за reopen, что он должен делать, при чем тут file name?

filename нужен для repoen (ещё раз порадуйся)

ХГ>Пример можешь привести, как это все должно работать?

на каждой записи файл закрывается, и возможно переотркывается.

ХГ>Что именно будет освобождаться в деструкторе и почему того же поведения нельзя добиться без деструктора?

если без repoen, то в деструкторе будет освобождаться file name, и возможно OS-level блокировка.

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

ХГ>>>>>>>>А с RAII вдруг выясняется, что какой-нибудь там стрим при закрытии не получилось флашнуть на диск.
P>>>>>>>а если без шуток, то эта проблема от того, что в этом деструкторе происходит попытка захвата новых ресурсов.
ХГ>>>>>>Никакого захвата новых ресурсов, только работа с уже захваченными.
P>>>>>попытка захватить новое место на диске во время flush'а
ХГ>>>>Это не ресурс в терминах RAII.
P>>>смотря как смотреть. файл ведь в деструкторе тоже не удаляется.
ХГ>>Почему именно удаление? Здесь мы вообще не имеем обратной операции.

P>это смотря как flush реализован

Так, как он реализован в std::ofstream — мы же первоначально его обсуждали. Я утверждаю, что этот flush не является захватом ресурсов в терминах RAII, ты утверждаешь обратное.


ХГ>>>>Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?
P>>>да пофиг что и как, у "правильного" объекта поломка должна быть возможна только до деструктора.
P>>>другие "неправильные" тоже могут со-существовать.
ХГ>>Осталось только научиться писать такие вот "правильные" стримы. Пока никто (ну кроме тебя, конечно) не умеет.

P>а что тебе не понятно?

Не понятно как писать такие стримы.


P>>>>>>>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.
ХГ>>>>>>Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.
P>>>>>легко, flush на каждой записи.
ХГ>>>>Это ничего не гарантирует. Например, у нас стрим вокруг ssl. При "освобождении" данного ресурса хорошо бы ему сделать shutdown.
P>>>делаешь всё что нужно для поддержания объекта в destructable-non-throwable state.
ХГ>>Как только напишешь "правильный" ssl-stream, который так себя и ведет, я тебе поверю

P>чему ты поверишь?

Что RAII удобно применять для объектов ввода-вывода, чему же еще.


P>>>>>либо вообще маразм в виде постоянного close+repoen
ХГ>>>>Какое это отношение имеет к RAII? В смысле, какой именно ресурс мы захватываем в конструкторе и освобождаем в деструкторе?
P>>>file handle (я же написал — reopen), file name
ХГ>>Это сейчас ты написал reopen, а в прошлый раз было repoen Но все равно ничего не понял. Что за reopen, что он должен делать, при чем тут file name?

P>filename нужен для repoen (ещё раз порадуйся)

Допустим, нужен (хотя не помешало бы обсудить и сокеты). А захватываем то что?


ХГ>>Пример можешь привести, как это все должно работать?

P>на каждой записи файл закрывается, и возможно переотркывается.

Пример привести не можешь. Понятно.


ХГ>>Что именно будет освобождаться в деструкторе и почему того же поведения нельзя добиться без деструктора?

P>если без repoen, то в деструкторе будет освобождаться file name, и возможно OS-level блокировка.

Не понял — ты строку что ли предлагаешь в деструкторе освобождать? Т.е., для собственно объектов ввода-вывода RAII, получается, не пригоден?
И вообще, давай для полного веселья у нас будет SSL-поток

Здравствуйте, Хон Гильдон, Вы писали:

P>>это смотря как flush реализован
ХГ>Так, как он реализован в std::ofstream — мы же первоначально его обсуждали. Я утверждаю, что этот flush не является захватом ресурсов в терминах RAII, ты утверждаешь обратное.

а я думал мы сферический flush обсуждаем, так как ты скачешь с ssl на сокеты

ХГ>>>>>Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?
P>>>>да пофиг что и как, у "правильного" объекта поломка должна быть возможна только до деструктора.
P>>>>другие "неправильные" тоже могут со-существовать.
ХГ>>>Осталось только научиться писать такие вот "правильные" стримы. Пока никто (ну кроме тебя, конечно) не умеет.
P>>а что тебе не понятно?
ХГ>Не понятно как писать такие стримы.

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

P>>>>>>>>классы должны сохранять инварианты, и должны находится в нормальном состоянии с момента их конструкции, вплоть до момента разрушения.
ХГ>>>>>>>Осталось написать стрим или его клиента (архив для boost::serialization, например), которые так работают. Я таких пока не видел и не думаю, что это возможно.
P>>>>>>легко, flush на каждой записи.
ХГ>>>>>Это ничего не гарантирует. Например, у нас стрим вокруг ssl. При "освобождении" данного ресурса хорошо бы ему сделать shutdown.
P>>>>делаешь всё что нужно для поддержания объекта в destructable-non-throwable state.
ХГ>>>Как только напишешь "правильный" ssl-stream, который так себя и ведет, я тебе поверю
P>>чему ты поверишь?
ХГ>Что RAII удобно применять для объектов ввода-вывода, чему же еще.

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

P>>>>>>либо вообще маразм в виде постоянного close+repoen
ХГ>>>>>Какое это отношение имеет к RAII? В смысле, какой именно ресурс мы захватываем в конструкторе и освобождаем в деструкторе?
P>>>>file handle (я же написал — reopen), file name
ХГ>>>Это сейчас ты написал reopen, а в прошлый раз было repoen Но все равно ничего не понял. Что за reopen, что он должен делать, при чем тут file name?
P>>filename нужен для repoen (ещё раз порадуйся)
ХГ>Допустим, нужен (хотя не помешало бы обсудить и сокеты). А захватываем то что?

объект filename + возможно lock файла

ХГ>>>Пример можешь привести, как это все должно работать?
P>>на каждой записи файл закрывается, и возможно переотркывается.
ХГ>Пример привести не можешь. Понятно.

не вижу в этом нужды, так как считаю что выделенного достаточно

ХГ>>>Что именно будет освобождаться в деструкторе и почему того же поведения нельзя добиться без деструктора?
P>>если без repoen, то в деструкторе будет освобождаться file name, и возможно OS-level блокировка.
ХГ>Не понял — ты строку что ли предлагаешь в деструкторе освобождать?

lock, строку, handle и любые другие implementation details.

ХГ>Т.е., для собственно объектов ввода-вывода RAII, получается, не пригоден?

зависит от требований

ХГ>И вообще, давай для полного веселья у нас будет SSL-поток

давай, приведи пример использования и требования

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

P>>>это смотря как flush реализован
ХГ>>Так, как он реализован в std::ofstream — мы же первоначально его обсуждали. Я утверждаю, что этот flush не является захватом ресурсов в терминах RAII, ты утверждаешь обратное.
P>а я думал мы сферический flush обсуждаем, так как ты скачешь с ssl на сокеты

более того, если говорить про std::ofstream — то он мне не нравится, так как допускает, что объект может находится в "плохом" состоянии

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


P>>>это смотря как flush реализован
ХГ>>Так, как он реализован в std::ofstream — мы же первоначально его обсуждали. Я утверждаю, что этот flush не является захватом ресурсов в терминах RAII, ты утверждаешь обратное.

P>а я думал мы сферический flush обсуждаем, так как ты скачешь с ssl на сокеты

Ну попробуй приведи пример реализации flush, действительно захватывающей ресурсы

ХГ>>>>>>Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?
P>>>>>да пофиг что и как, у "правильного" объекта поломка должна быть возможна только до деструктора.
P>>>>>другие "неправильные" тоже могут со-существовать.
ХГ>>>>Осталось только научиться писать такие вот "правильные" стримы. Пока никто (ну кроме тебя, конечно) не умеет.
P>>>а что тебе не понятно?
ХГ>>Не понятно как писать такие стримы.

P>а я не говорил что стримы писать нужно именно так

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

P>но тем не менее пример стрима без ошибок в деструкторе, я вроде показал

Не было

ХГ>>Что RAII удобно применять для объектов ввода-вывода, чему же еще.

P>я вообще этого не утверждал.

А с чем тогда споришь? Я привел пример именно ввода-вывода, как ситуации, когда RAII слабо подходит.

P>но тем не менее, в частных случаях (в зависимости от требований) — они могут быть очень удобны
P>если приведёшь реальный паттерн использования который тебя интересует — мы можем рассмотреть его

Ну допустим нам нужно записать некий текст в некое устройство. Текст формируется сложным образом, в памяти единым куском не присутствует (например, большой очень). Что за устройство, наша подсистема не знает — может, диск, может сеть, может 3-d принтер. В случае возникновения ошибки информацию о ней надо показать пользователю. Максимально подробно, чтобы он догадался, что у него сломалось и мог уничтожать ошибочные результаты, после чего запустить задачу заново. Я утверждаю:

1. RAII для обращения с таким неизвестным устройством приносит больше вреда, чем пользы.
   
2. это частая задача, и RAII ошибочно применяется тоже часто.

ХГ>>Пример привести не можешь. Понятно.

P>не вижу в этом нужды, так как считаю что выделенного достаточно

Конечно, а то эдак и неправоту признать придется

ХГ>>>>Что именно будет освобождаться в деструкторе и почему того же поведения нельзя добиться без деструктора?
P>>>если без repoen, то в деструкторе будет освобождаться file name, и возможно OS-level блокировка.
ХГ>>Не понял — ты строку что ли предлагаешь в деструкторе освобождать?

P>lock, строку, handle и любые другие implementation details.

А хрен ли handle не освобождать в close? Зачем до деструктора откладывать?

ХГ>>Т.е., для собственно объектов ввода-вывода RAII, получается, не пригоден?

P>зависит от требований

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

ХГ>>И вообще, давай для полного веселья у нас будет SSL-поток

P>давай, приведи пример использования и требования

См. выше.

Здравствуйте, Хон Гильдон, Вы писали:

ХГ>>>>>>>Да и флаш может быть не на диск а, например, в сокет. Там чего захватываем?
P>>>>>>да пофиг что и как, у "правильного" объекта поломка должна быть возможна только до деструктора.
P>>>>>>другие "неправильные" тоже могут со-существовать.
ХГ>>>>>Осталось только научиться писать такие вот "правильные" стримы. Пока никто (ну кроме тебя, конечно) не умеет.
P>>>>а что тебе не понятно?
ХГ>>>Не понятно как писать такие стримы.
P>>а я не говорил что стримы писать нужно именно так
ХГ>Т.е., писать такие стримы ты не умеешь, но бездоказательно утверждаешь, что это не только возможно, но и удобно?

с таким тоном и настроем можешь идти куда подальше