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

VD>>AT & T тебе не о чем не говорит? Куда же мощьне то?

E>IBM, Microsoft, Sun, Oracle, ... список можно продолжать.

И зачем этот список? Я про то, что Страустпуп из AT & T. Компания более чем авторитетная в области IT. Не мало стандартов выпустила.

E>Насколько я помню, AT&T долгое время вообще запрещалось заниматься IT-бизнесом. Потому-то Unix и расползлась бесплатно по университетам.

Про SCO и Солярку я надеюсь ты слышал...

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

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

VD>>>AT & T тебе не о чем не говорит? Куда же мощьне то?

E>>IBM, Microsoft, Sun, Oracle, ... список можно продолжать.

VD>И зачем этот список?

Затем, что эти компании по своей "пробивной" силе помощнее AT&T будут.

VD> Я про то, что Страустпуп из AT & T. Компания более чем авторитетная в области IT. Не мало стандартов выпустила.

И что. Она не могла продавать в свое время Unix, потому, что ей это было запрещено. Вполне возможно, что такая же ситуация сложилась и с C++. А потом поезд уже ушел. И сравни это с Sun-овской Java или Microsoft-овским .Net.

E>>Насколько я помню, AT&T долгое время вообще запрещалось заниматься IT-бизнесом. Потому-то Unix и расползлась бесплатно по университетам.

VD>Про SCO и Солярку я надеюсь ты слышал...

И что? Хочешь сказать, что они не из AT&T-шного Unix-а растут?

eao197,

> VD> Я про то, что Страустпуп из AT & T. Компания более чем авторитетная в области IT. Не мало стандартов выпустила.

AT&T не продвигала C++ подобно тому, как это делают Sun и Microsoft с Java и C#, так что ее мощь — или, скорее, мощи, т.к. ее перекупили недавно, и больше такого бренда не существует — здесь рояля не играет...

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

AVK>Осталось ответить на вопрос о том, почему такая ситуация сложилась. Почему, к примеру, для Java народ пытается придерживаться каких то стандартов при создании библиотек, пусть и неформальных, а в С++ каждый тянет телегу в свою сторону?

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

Затем еще более серьезная фирма повторила этот подвиг, вбухала еще больше денег, смастерила еще более мощную разработку и отдала нам опять... даром (!!!)

А коммерчесские С++-либы традиционно стоили весьма дорого.

-------
К тому же в Java и дотнет даны как системные интерфейсы + реализации, так и name conventions. Каждый из фреймворков — это не просто функциональность, это еще и единый стиль и подход к решению типовых задач (общий некий дух).

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

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

E>А уж про GUI можно вообще не вспоминать

С ГУИ вообще было сплошное кино. Когда-то Борланд пытался двигать свою OWL. Не скажу, что либы — супер, но на тот момент лучше не было. Она была действительно ООП-ориентирована, в отличие от смешанного стиля MFC (и вообще корявости).

Так вот, в те далекие времена Microsoft раздала всем поставщикам С++ компиляторам под Windows свой MFC, но со странным лицензионным соглашением — MFC не может идти в одной коробке с другими GUI либами под Windows. Получается, что Борланду надо было продавать и поддерживать 2 набора (С++ компилятор + системные и ГУИ либы). Видать, это было странно, да и пользователь не понял... В общем С++ — направление у Борланда загнулось. И OWL заодно.

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

Просто неоднократно наблюдал ситуацию, когда негативные тесты пишут в меньшем объеме, чем хотелось бы (ибо их всегда должно быть в разы больше функциональных). Т.е. юнит-теста на факт reject-а при наличии в поле reserved значения, отличного от 0-ля, могло и не быть.

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

V>>Зато есть необходимость дописывать визитора каждый раз при добавлении версии. Собс-но, этим мне паттерн и не нравится.

VD>От оно решение твоих пролем.

А мы знаем, мы ждем просто... И не только твою эту разработку.

Пока вот отлаживаем персистент-фреймворк (на основе RFD) + поддержку 3-tier разработок. Microsoft подводит сильно, к Сентябрю у нас релиз, и прошлой осенью мы расчитывали делать его на 2.0... Видно не судьба, так что возимся пока с 1.1.

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

V>Так вот, в те далекие времена Microsoft раздала всем поставщикам С++ компиляторам под Windows свой MFC, но со странным лицензионным соглашением — MFC не может идти в одной коробке с другими GUI либами под Windows. Получается, что Борланду надо было продавать и поддерживать 2 набора (С++ компилятор + системные и ГУИ либы). Видать, это было странно, да и пользователь не понял... В общем С++ — направление у Борланда загнулось. И OWL заодно.

Borland C++ загнулся не потому. Скорее всего у Борланды просто не хватило силёнок на два продукта — Дельфи и плюсы. Чем-то надо было жертвовать. Результат нам известен

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

G>Т.е. сам PDU проверяет реализуемые им ограничения именно на "совместимость" с соответсвующими ограничениями протокола. А протоколу остается проверить лишь налие в PDU реализаций всех ограничений, которые он накладывает на данный тип PDU. Так что с инкапсуляцией сдесь все пучком.

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

G>Собственно, если так уж хочеться всё "засунуть" в PDU... задавая контекст проверки неявно... ,то почему бы не сделать и саму проверку неявной — носящей чисто "декларативный" характер? Т.е. сама проверка как бы подразумевается... и в зависимости от номера версии возвращается лишь true или false. Вот при таком решении действительно, нет смысла заморачиваться с Visitor'ами и ограничениями... но и городить на каждую версию свой метод, имхо, то же смысла не много.

А вот этого мы знать не можем, пока не познакомились с самим протоколом.

G>Только в том, случае если в новой версии изменился список ограничений. Что, собсвенно, не факт... ведь может измениться лишь их реализация — например допустимый размер поля. В этом случае, визитор не меняется.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>eao197,

>> VD> Я про то, что Страустпуп из AT & T. Компания более чем авторитетная в области IT. Не мало стандартов выпустила.

ПК>AT&T не продвигала C++ подобно тому, как это делают Sun и Microsoft с Java и C#, так что ее мощь — или, скорее, мощи, т.к. ее перекупили недавно, и больше такого бренда не существует — здесь рояля не играет...

Угу.
И Unix они до поры, до времени тоже не продвигали, как Microsoft свой Windows или Apple свой AppleOS.
Редиски.

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

E>Ну вот, опять воцарилось полное непонимание

Придётся опять переходить на «пальцы»

Чтобы было более понятно, я заменю понятие неопределенности на банальный null. В этом случае, в любом месте где используется конструкция:

(pdu.*m_checker)();

Вы обязаны произвести проверку m_checker на null. Если он таки равен null, то в точке валидации возникает ситуация когда выполнить проверку через PDU Вы не можете, и вынуждены перекладываете эту проверку на плечи клиента PDU (например, session). Что есть грубое нарушение инкапсуляции — т.к. валидацию должен осуществлять PDU.

В случае же когда используется конструкция:

pdu.check(m_checker);

Проверка m_checker на null осуществляется внутри метода check. Соответственно, Вы имеете возможность обработать ситуацию проверки PDU в null’овом контексте. И это будет нормальное, запротоколированное поведение PDU! Более того, т.к. это поведение может отличаться для разных типов PDU реализовать подобное поведение в рамках клиента — пусть и с нарушением инкапсуляции — у Вас не получится, т.к. клиенту тип PDU не известен.

К первой ситуации приводит именно, то, что в точке валидации контекст лишь подразумевается. В явном виде его там нет. И именно то, что во второй ситуации контекст присутствует явно позволяет нам определить поведение PDU для случая проверки в null’овом контексте.

---
С уважением, Сиваков Константин.

P.S. Чуть не забыл… любой класс, использующий объекты класса PDU — есть клиент класса PDU.

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

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

E>>Ну вот, опять воцарилось полное непонимание

G>Придётся опять переходить на «пальцы»

Ну вот на пальцах все стало гораздо понятнее.

G>Чтобы было более понятно, я заменю понятие неопределенности на банальный null. В этом случае, в любом месте где используется конструкция:

G>

G>(pdu.*m_checker)();
G>

G>Вы обязаны произвести проверку m_checker на null.

Нет, не обязан. Я обязан в нужном месте проинициализировать m_checker.
Кроме того, равенство m_checker-а нулю -- это проблема не pdu_t, а клиента pdu_t. Имхо, ошибиться с инициализаций m_checker (будь то нулевое значение или метод, проверяющий не ту версию) можно точно так же, будет m_checker указателем на метод или указателем на визитор.

G> Если он таки равен null, то в точке валидации возникает ситуация когда выполнить проверку через PDU Вы не можете, и вынуждены перекладываете эту проверку на плечи клиента PDU (например, session). Что есть грубое нарушение инкапсуляции — т.к. валидацию должен осуществлять PDU.

Имхо, это более чем спорное утверждение. Корректность или некорректность валидатора совершенно не имеет отношение к инкапсуляции PDU.

G>В случае же когда используется конструкция:

G>

G>pdu.check(m_checker);
G>

G>Проверка m_checker на null осуществляется внутри метода check. Соответственно, Вы имеете возможность обработать ситуацию проверки PDU в null’овом контексте.

Ну и имею. И что? Есть ли осмысленная семантика проверки валидности PDU в нулевом контексте? Имхо, нет.

Максимум, что может сделать pdu_t::check() в таком случае -- это породить исключение. Но что делать в этом случае клиенту PDU? Он что, ждет подобное исключение? Вряд ли, он ведь пребывает в полной уверенности, что передал в check полностью определенный контекст. Поэтому, в лучшем случае он отловит все исключения (типа catch(const std::exception &)). А в худшем только те исключения, которые касаются некорректности PDU, но не контекста-валидатора. Т.е., в тривиальной реализации:

// Базовый класс исключений, связанных с некорректным PDU.
class    incorrect_pdu_ex_t : public std::logic_error { ... };
    // Здесь идет серия исключений, связанных с различными ошибками в PDU.
    class    unknown_pdu_ex_t : public incorrect_pdu_ex_t { ... };
    class    unknown_field_ex_t : public incorrect_pdu_ex_t { ... };
    class    incorrect_field_ex_t : public incorrect_pdu_ex_t { ... };
        class field_length_ex_t : public incorrect_field_ex_t { ... };
        class field_value_ex_t : public incorrect_field_ex_t { ... };
        class field_relation_ex_t : public incorrect_field_ex_t { ... };
        
class    pdu_t
    {
    public :
        virtual void
        check( pdu_checker_t * checker ) const
            {
                if( !checker )
                    throw std::invalid_argument( "checker == 0!" );
                ...
            }
        ...
    };
    
void
session_t::process_outgoing( const pdu_t & pdu )
    {
        try
            {
                pdu.check( m_checker );
            }
        catch( const incorrect_pdu_t & x )
            { ... }
    }

И все, приплыли. Прямо вот сюда: Что толку в Ада если Ариан 5 все равно упал

Автор: eao197
Дата: 05.06.05

. Потому, что исключения std::invalid_argument никто не ждет.

И здесь сразу же возникает масса вопросов. А почему не ждут std::invalid_argument? А почему pdu_t::check() порождает std::invalid_argument вместо какого-то производного от incorrect_pdu_ex_t исключения?
Заметим при этом, что в случае с указателем на метод ни одного подобного вопроса вообще не возникает.

G> И это будет нормальное, запротоколированное поведение PDU!

А теперь представь, что для PDU нет осмысленной семантики, если checker равен нулю. Это можно выразить даже средствами языка:

class pdu_t
    {
    public :
        virtual void
        check( pdu_checker_t & checker ) const;
    ...
    };

И тогда обращения к check нужно будет писать как:

pdu.check( *m_checker );

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

Так что, Константин, в этом конкретном случае, ты не привел ни одного убедительного примера, имхо.

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

V>Пока вот отлаживаем персистент-фреймворк (на основе RFD) + поддержку 3-tier разработок. Microsoft подводит сильно, к Сентябрю у нас релиз, и прошлой осенью мы расчитывали делать его на 2.0... Видно не судьба, так что возимся пока с 1.1.

К сентябрю релиз уже обязан быть. Так что делайте спокойно на бэте. Протестируете при появлении релиза и все. Один фиг будет надежнее. Там много глюков поправлено. Так что переходить имеет смысл просто ради надежности и скорости.

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

E>Ну вот на пальцах все стало гораздо понятнее.

Славтегосподи...

G>>Вы обязаны произвести проверку m_checker на null.

E>Нет, не обязан. Я обязан в нужном месте проинициализировать m_checker.

Вы можете гарантировать, что в точке валидации m_checker проинициализирован? Только в случае, инициализации через конструктор. Соответсвенно, если инициализация m_checker'а идёт вне рамок конструктора, то обязаны. Иначе клиента ждёт "сюприз" в лице недокументированного поведения.

E>Кроме того, равенство m_checker-а нулю -- это проблема не pdu_t, а клиента pdu_t. Имхо, ошибиться с инициализаций m_checker (будь то нулевое значение или метод, проверяющий не ту версию) можно точно так же, будет m_checker указателем на метод или указателем на визитор.

Проблема pdu_t — реализовать поведение "проверка pdu". Т.к. контекст проверки задается неявно, pdu_t его контроллировать не может. Вот как проблема звучит для pdu_t. В случае же явной передачи контекста в pdu_t, он (pdu_t) может проверить контекст и среагировать на его не корректность... Хоть исключением, хоть ещё как.

G>> Если он таки равен null, то в точке валидации возникает ситуация когда выполнить проверку через PDU Вы не можете, и вынуждены перекладываете эту проверку на плечи клиента PDU (например, session). Что есть грубое нарушение инкапсуляции — т.к. валидацию должен осуществлять PDU.

E>Имхо, это более чем спорное утверждение. Корректность или некорректность валидатора совершенно не имеет отношение к инкапсуляции PDU.

Ещё как имеет. Поскольку у нас PDU реализует поведение "проверка PDU" — его прямая обязанность обрабатывать исключительные ситуации связаные с этим поведением! К коим относится, и ситуация с невалидным контекстом.

G>>Проверка m_checker на null осуществляется внутри метода check. Соответственно, Вы имеете возможность обработать ситуацию проверки PDU в null’овом контексте.

E>Ну и имею. И что? Есть ли осмысленная семантика проверки валидности PDU в нулевом контексте?

Вы меня спрашиваете?! Имхо, Вам лучше знать. Даже если её сейчас нет, Вы можете гарантировать, что завтра... в следующей версии, её не появится? Что Вы будете делать в этом случае? А если эта симантика будет зависима ещё и от типа PDU?

E>Имхо, нет.

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


E>Максимум, что может сделать pdu_t::check() в таком случае -- это породить исключение. Но что делать в этом случае клиенту PDU? Он что, ждет подобное исключение? Вряд ли, он ведь пребывает в полной уверенности, что передал в check полностью определенный контекст. Поэтому, в лучшем случае он отловит все исключения (типа catch(const std::exception &)). А в худшем только те исключения, которые касаются некорректности PDU, но не контекста-валидатора.

Послушайте... Это Вам лучше знать, что в этом случае должен делать PDU. Может Вас учтроит исключение — и тогда оно будет описано в возможных реакциях pdu_t. И, в этом случае, уж точно не может счетаться "сюрпрызом" для клиента PDU. В отличае от NullReferanceException на которое может нарваться клиент session_t.

А может, быть и так что реакцией PDU на некорректный контекст будет просто — "проверка не пройдена"... Простор для фантазии

E>И все, приплыли. Прямо вот сюда: Что толку в Ада если Ариан 5 все равно упал

Автор: eao197
Дата: 05.06.05

. Потому, что исключения std::invalid_argument никто не ждет.

Если возможность этого исключения описана в поведении PDU — то очень даже ждёт. А вот, повторяюсь, NullReferanceException от session_t.process_outgoing врядли кто-то ждет.

E>И здесь сразу же возникает масса вопросов. А почему не ждут std::invalid_argument? А почему pdu_t::check() порождает std::invalid_argument вместо какого-то производного от incorrect_pdu_ex_t исключения?

Хм... Кто Вам мешает в этом случае кидать (если уж так хочется что-нибудь кинуть), что-то типа — incorrect_pdu_validation_context_ex_t?

E>Заметим при этом, что в случае с указателем на метод ни одного подобного вопроса вообще не возникает.

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

G>> И это будет нормальное, запротоколированное поведение PDU!

E>А теперь представь, что для PDU нет осмысленной семантики, если checker равен нулю. Это можно выразить даже средствами языка:
E>

E>class pdu_t
E>    {
E>    public :
E>        virtual void
E>        check( pdu_checker_t & checker ) const;
E>    ...
E>    };
E>

E>И тогда обращения к check нужно будет писать как:
E>

E>pdu.check( *m_checker );
E>

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

На какие, если не секрет? Ну нет семантики проверки в невалидном контексте... ну кидаем из pdu_t.check incorrect_pdu_validation_context_ex_t. Или говорим что pdu в данном контексте невалиден — что, имхо, более правильно.

E>Так что, Константин, в этом конкретном случае, ты не привел ни одного убедительного примера, имхо.



---
С уважением, Сиваков Константин.

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

G>>>Вы обязаны произвести проверку m_checker на null.

E>>Нет, не обязан. Я обязан в нужном месте проинициализировать m_checker.

G> Вы можете гарантировать, что в точке валидации m_checker проинициализирован? Только в случае, инициализации через конструктор. Соответсвенно, если инициализация m_checker'а идёт вне рамок конструктора, то обязаны. Иначе клиента ждёт "сюприз" в лице недокументированного поведения.

Здесь есть две точки зрения. Первая -- это точка зрения разработчика классов pdu_t. Так вот с этой точки зрения корректность какого-то внешнего указателя для pdu_t вообще не играет роли. Вторая точка зрения -- это точка зрения разработчика клиента pdu_t. И здесь разработчик не должен полагаться на то, что pdu_t будет отлавливать его ошибки -- у pdu_t совершенно другая задача.

G>Проблема pdu_t — реализовать поведение "проверка pdu". Т.к. контекст проверки задается неявно, pdu_t его контроллировать не может. Вот как проблема звучит для pdu_t. В случае же явной передачи контекста в pdu_t, он (pdu_t) может проверить контекст и среагировать на его не корректность... Хоть исключением, хоть ещё как.

Нет, Константин, проверка pdu_t методами check_ver_x_y происходит в точно определенном контексте, поскольку каждый метод check_ver точно знает, в какой версии протокола он реализован.
Что требуется -- так это то, чтобы клиент выбрал нужный метод check_ver_x_y. Но и в случае с visitor-ом клиент так же должен выбрать нужный класс Check_Ver_X_Y. И вероятность ошибки клиента, имхо, что для неправильного выбора метода, что для неправильного выбора визитора -- одинакова.

E>>Имхо, это более чем спорное утверждение. Корректность или некорректность валидатора совершенно не имеет отношение к инкапсуляции PDU.

G>Ещё как имеет. Поскольку у нас PDU реализует поведение "проверка PDU" — его прямая обязанность обрабатывать исключительные ситуации связаные с этим поведением! К коим относится, и ситуация с невалидным контекстом.

В том-то и дело, что в случае с методами check_ver_x_y для PDU невалидных контекстов просто не сушествует -- есть только проблемы с невалиными указателями у клиента. В случае же с объектами-верификаторами у PDU существует проблема с невалидным контекстом, а у клиента все равно остается проблемы с невалидными указателями на объекты-верификаторы.

E>>Есть ли осмысленная семантика проверки валидности PDU в нулевом контексте?

G> Вы меня спрашиваете?! Имхо, Вам лучше знать. Даже если её сейчас нет, Вы можете гарантировать, что завтра... в следующей версии, её не появится? Что Вы будете делать в этом случае? А если эта симантика будет зависима ещё и от типа PDU?

E>>Имхо, нет.

G>Вам виднее. Я лишь просто пытаюсь указать Вам на "шершавости" такой реализации. Имхо, ничем не обосноснованной. Вы же так и не попытались объяснить, что именно Вы пытались выиграть такой реализацией.

Вот в том-то и дело, что я знаю семантику протокола о котором идет речь. И знаю, что нет смысла в проверке PDU в нулевом контексте. И не будет. А выиграть я пытаюсь простоту реализации, использования и сопровождения.

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

Мы ведь говорим про C++. Там нет жесткой спецификации исключений, как в Java. Поэтому то, что будет написано в документации никак не может быть проверено компилятором.

E>>И здесь сразу же возникает масса вопросов. А почему не ждут std::invalid_argument? А почему pdu_t::check() порождает std::invalid_argument вместо какого-то производного от incorrect_pdu_ex_t исключения?

G>Хм... Кто Вам мешает в этом случае кидать (если уж так хочется что-нибудь кинуть), что-то типа — incorrect_pdu_validation_context_ex_t?

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

E>>Заметим при этом, что в случае с указателем на метод ни одного подобного вопроса вообще не возникает.

G>Угу... Возникают другие вопросы, у других клиентов. Причем таких вопросов у этих клиентов при непробитой инкапсуляции возникать не должно!

Какие вопросы?

G>>> И это будет нормальное, запротоколированное поведение PDU!

E>>А теперь представь, что для PDU нет осмысленной семантики, если checker равен нулю. Это можно выразить даже средствами языка:
E>>

E>>class pdu_t
E>>    {
E>>    public :
E>>        virtual void
E>>        check( pdu_checker_t & checker ) const;
E>>    ...
E>>    };
E>>

E>>И тогда обращения к check нужно будет писать как:
E>>

E>>pdu.check( *m_checker );
E>>

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

G>На какие, если не секрет? Ну нет семантики проверки в невалидном контексте... ну кидаем из pdu_t.check incorrect_pdu_validation_context_ex_t. Или говорим что pdu в данном контексте невалиден — что, имхо, более правильно.

Константин, а ты в C++ насколько разбираешся? Или просто невнимательно пример прочел? В С++ подсунуть аргументу-ссылке разыменованный нулевой указатель -- это тоже самое, что вызвать метод по нулевому указателю. pdu_t::check() даже не сможет определить, что ссылка некорректна.

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

V>>Пока вот отлаживаем персистент-фреймворк (на основе RFD) + поддержку 3-tier разработок. Microsoft подводит сильно, к Сентябрю у нас релиз, и прошлой осенью мы расчитывали делать его на 2.0... Видно не судьба, так что возимся пока с 1.1.

VD>К сентябрю релиз уже обязан быть.

Кому обязан? МС вот говорит что после 7 ноября.

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

G>> Вы можете гарантировать, что в точке валидации m_checker проинициализирован? Только в случае, инициализации через конструктор. Соответсвенно, если инициализация m_checker'а идёт вне рамок конструктора, то обязаны. Иначе клиента ждёт "сюприз" в лице недокументированного поведения.

E>Здесь есть две точки зрения. Первая -- это точка зрения разработчика классов pdu_t. Так вот с этой точки зрения корректность какого-то внешнего указателя для pdu_t вообще не играет роли. Вторая точка зрения -- это точка зрения разработчика клиента pdu_t. И здесь разработчик не должен полагаться на то, что pdu_t будет отлавливать его ошибки -- у pdu_t совершенно другая задача.

Архитектора и программиста.

А вообше говоря... либо мы гарантируем инкапсуляцию поведения "проверка" классом PDU, либо нет. В Вашем случае, инкапсуляция "пробивается".

E>Нет, Константин, проверка pdu_t методами check_ver_x_y происходит в точно определенном контексте, поскольку каждый метод check_ver точно знает, в какой версии протокола он реализован.

Более того... В Вашем варианте реализации этого поведения, контекст вообще не вынесен в отдельную сущьность. Контекстом проверки является сам метод check_ver_x_y. Проблема в том, что при такой реализации клиентов PDU обязывают знать!!! все возможные контексты. Хотя для осуществления проверки им достаточно иметь!!! хоть какой-нибудь.

E>Что требуется -- так это то, чтобы клиент выбрал нужный метод check_ver_x_y. Но и в случае с visitor-ом клиент так же должен выбрать нужный класс Check_Ver_X_Y. И вероятность ошибки клиента, имхо, что для неправильного выбора метода, что для неправильного выбора визитора -- одинакова.

И вот тут — при неявном выборе этого метода (контекста) — Вы и не можете гарантировать, что этот "выбор" сделан. Соответсвенно, каждый клиент PDU, используя неявный выбор, должен брать на себя часть реализации поведения, которое — по любому — должен бы реализовывать сам PDU. Более того — в более общем случае — у клиента может и не быть возможности правильно реализовать такое поведение.

Попытаюсь опять на пальцах...

У нас есть некий класс SomeClass... у этого класса есть метод: Compare(object obj). Кто должен осуществлять, проверку — obj is SomeClass? SomeClass или его клиент? Пример абстактный, но настолько же абстрактными могут быть и Ваши доводы за то, чтобы проверку — obj is SomeClass — выполнял клиент. С интересом послушаю. Так же интерестны Ваши рассуждения, по поводу того, насколько будет удобен метод Compare(), контекст для которого задается через SomeClass.ObjectForCompare?

G>>Ещё как имеет. Поскольку у нас PDU реализует поведение "проверка PDU" — его прямая обязанность обрабатывать исключительные ситуации связаные с этим поведением! К коим относится, и ситуация с невалидным контекстом.

E>В том-то и дело, что в случае с методами check_ver_x_y для PDU невалидных контекстов просто не сушествует -- есть только проблемы с невалиными указателями у клиента. В случае же с объектами-верификаторами у PDU существует проблема с невалидным контекстом, а у клиента все равно остается проблемы с невалидными указателями на объекты-верификаторы.

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

E>Вот в том-то и дело, что я знаю семантику протокола о котором идет речь. И знаю, что нет смысла в проверке PDU в нулевом контексте. И не будет. А выиграть я пытаюсь простоту реализации...

Охотно верю... Только ведь качество библиотеки определяется как раз удобством её использования. Мне, как клиенту библиотеки, сугубо фиолетово как Вы добъетесь того, чтобы мне жилось удобно. Библиотеки они для клиентов пишуться. Или у Вас по другому?

E>, использования и сопровождения.

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

Чтож.. опять на пальцы.

Возмем Ваш же класс session_t. Этот класс вынужден изменяться каждый раз когда появляется новый метод проверки. Этого можно было бы избежать... Вам самому-то не смешон вполне возможный диалог:

- Кто session_t трогал?
— Я.
— Нафиг?!
— Да новая версия протокола вышла. Учили PDU проверяться под ней.
— И...?
— Что и?! Вот session_t и пришлось "трогать".
— У нас что, session_t отвечает за проверку PDU?!
— Да нет... Всю проверку PDU инкапсулирует.
—

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


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

E>Мы ведь говорим про C++. Там нет жесткой спецификации исключений, как в Java. Поэтому то, что будет написано в документации никак не может быть проверено компилятором.

И что?! Это же не значит, что Вы как разработчик освобождены от обязанности документировать возможные исключения, пораждаемые тем или иным методом класса. А меня, как клиента Вашей библиотеки, никто не освобождал от обязанности читать маны, перед тем как...

G>>Хм... Кто Вам мешает в этом случае кидать (если уж так хочется что-нибудь кинуть), что-то типа — incorrect_pdu_validation_context_ex_t?

E>А мне не хочется ничего кидать в таких случаях. И в случае с указателями на методы проверки ничего и не приходится кидать. И даже думать об этом.

Вот после таких фраз желания кому-то, что-то объяснять резко убавляется. Воистину: научить ничему нельзя, — можно только научиться.

E>>>Заметим при этом, что в случае с указателем на метод ни одного подобного вопроса вообще не возникает.

G>>Угу... Возникают другие вопросы, у других клиентов. Причем таких вопросов у этих клиентов при непробитой инкапсуляции возникать не должно!

E>Какие вопросы?

Например, почему process_outgoing кидает NullReferanceException вместо внятного сообщения — "не задана версия протокола"

G>>На какие, если не секрет? Ну нет семантики проверки в невалидном контексте... ну кидаем из pdu_t.check incorrect_pdu_validation_context_ex_t. Или говорим что pdu в данном контексте невалиден — что, имхо, более правильно.

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

Определенно мы друг друга не понимаем. Я Вас что, заставляю по ссылке контекст передавать? Ужас, блин.

---
С уважением, Сиваков Константин

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

G>А вообше говоря... либо мы гарантируем инкапсуляцию поведения "проверка" классом PDU, либо нет. В Вашем случае, инкапсуляция "пробивается".

Можно ли расшифровать термин "пробивается" в контексте нашего диалога?

E>>Нет, Константин, проверка pdu_t методами check_ver_x_y происходит в точно определенном контексте, поскольку каждый метод check_ver точно знает, в какой версии протокола он реализован.

G>Более того... В Вашем варианте реализации этого поведения, контекст вообще не вынесен в отдельную сущьность. Контекстом проверки является сам метод check_ver_x_y. Проблема в том, что при такой реализации клиентов PDU обязывают знать!!! все возможные контексты. Хотя для осуществления проверки им достаточно иметь!!! хоть какой-нибудь.

В корне не согласен. Реализации клиентов PDU, которые сами выбирают контекст (к которым и относится session_t) обязаны знать про все поддерживаемые контексты. Поскольку они будут делать выбор либо из указателей на методы, либо из классов-верификаторов.

Если же какой-то клиент получает контекст откуда-то извне, то ему безразлично, получит ли он контекст в виде указателя на метод или в виде указателя на объект-верификатор. В C++ указатель на метод даже предпочтительнее, т.к. не тебуется забота о времени его жизни (в отличии от указателя на объект-верификатор).

E>>Что требуется -- так это то, чтобы клиент выбрал нужный метод check_ver_x_y. Но и в случае с visitor-ом клиент так же должен выбрать нужный класс Check_Ver_X_Y. И вероятность ошибки клиента, имхо, что для неправильного выбора метода, что для неправильного выбора визитора -- одинакова.

G>И вот тут — при неявном выборе этого метода (контекста) — Вы и не можете гарантировать, что этот "выбор" сделан. Соответсвенно, каждый клиент PDU, используя неявный выбор, должен брать на себя часть реализации поведения, которое — по любому — должен бы реализовывать сам PDU. Более того — в более общем случае — у клиента может и не быть возможности правильно реализовать такое поведение.

Не понимаю о чем ты. Если клиент должен делать выбор контекста, то он где-то должен будет написать:

if( 0x33 == version )
    return &pdu_t::check_ver_3_3;
else if( 0x34 == version )
    return &pdu_t::check_ver_3_4;
...

или же:

if( 0x33 == version )
    return new Check_Ver_3_3();
else if( 0x34 == version )
    return new Check_Ver_3_4();
...

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

G>У нас есть некий класс SomeClass... у этого класса есть метод: Compare(object obj). Кто должен осуществлять, проверку — obj is SomeClass? SomeClass или его клиент? Пример абстактный, но настолько же абстрактными могут быть и Ваши доводы за то, чтобы проверку — obj is SomeClass — выполнял клиент. С интересом послушаю.

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

Кроме того, я не вижу никакой аналогии с обсуждаемой нами проблемой проверки корректности PDU.

G>Или проблемы негров — шерифа не волнуют?

Именно так. Моя задача -- сделать библиотеку, которая работает корректно, если с ней корректно обращаются. И снижает количество способов, которыми ее можно использовать некорректно. Заметь, метод check_ver_x_y нельзя вызвать некорректно -- если есть валидный указатель на метод, то вызов автоматически происходит корректно. А вот получение корректного указателя -- это забота клиента. Так же как заботой клиента будет получение корректного указателя на объект-верификатор. И кстати, не нужно надеятся на то, что некорректный указатель на объект-верификатор будет иметь значение 0 -- в C++ он может иметь совершенно произвольное значение, 0xdeadbeaf, например.

G>Охотно верю... Только ведь качество библиотеки определяется как раз удобством её использования. Мне, как клиенту библиотеки, сугубо фиолетово как Вы добъетесь того, чтобы мне жилось удобно. Библиотеки они для клиентов пишуться. Или у Вас по другому?

Мне проще -- я сам являюсь ее клиентом. И сразу пишу так, чтобы мне было удобно.

G>Чтож.. опять на пальцы.

G>Возмем Ваш же класс session_t. Этот класс вынужден изменяться каждый раз когда появляется новый метод проверки. Этого можно было бы избежать... Вам самому-то не смешон вполне возможный диалог:

G>- Кто session_t трогал?
G>- Я.
G>- Нафиг?!
G>- Да новая версия протокола вышла. Учили PDU проверяться под ней.
G>- И...?
G>- Что и?! Вот session_t и пришлось "трогать".
G>- У нас что, session_t отвечает за проверку PDU?!
G>- Да нет... Всю проверку PDU инкапсулирует.
G>-

Ну и что мне этот диалог должен был показать?

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

G>Вообще, представим себе некую простую библиотеку которая ничем кроме сериализации, десериализации и валидации PDU не занимается. Ей, как клиенту Вашей библиотеки, сугубо фиолетовы нюансы реализаций PDU в каких-либо версиях.

Я не могу себе представить библиотеку сериализации/десериализации, которой фиолетовы детали реализации PDU в конкретных версиях. Что собственно это библиотека будет сериализовать/десериализовать.

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

E>>Мы ведь говорим про C++. Там нет жесткой спецификации исключений, как в Java. Поэтому то, что будет написано в документации никак не может быть проверено компилятором.

G>И что?! Это же не значит, что Вы как разработчик освобождены от обязанности документировать возможные исключения, пораждаемые тем или иным методом класса. А меня, как клиента Вашей библиотеки, никто не освобождал от обязанности читать маны, перед тем как...

А что ошибки, как в документации и реализации уже не случаются?

G>>>Угу... Возникают другие вопросы, у других клиентов. Причем таких вопросов у этих клиентов при непробитой инкапсуляции возникать не должно!

E>>Какие вопросы?

G>Например, почему process_outgoing кидает NullReferanceException вместо внятного сообщения — "не задана версия протокола"

Потому, что process_outgoing вообще не кидает NullReferenceException. Хотя бы потому, что это C++.

G>>>На какие, если не секрет? Ну нет семантики проверки в невалидном контексте... ну кидаем из pdu_t.check incorrect_pdu_validation_context_ex_t. Или говорим что pdu в данном контексте невалиден — что, имхо, более правильно.

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

G> Определенно мы друг друга не понимаем. Я Вас что, заставляю по ссылке контекст передавать? Ужас, блин.

Передача контекста по ссылке -- это нормальный C++ способ указать, что метод не хочет получать нулевых указателей. На пальцах:
если сигнатура метода:

void check( pdu_checker_t * );

то в программе можно, ошибочно, написать:

check( 0 );

и компилятор это проглотит.
Но если сменить сигнатуру на:

void check( pdu_checker_t & );

то написать:

check( 0 );

уже нельзя, т.к. компилятор не пропустит.

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

G>>А вообше говоря... либо мы гарантируем инкапсуляцию поведения "проверка" классом PDU, либо нет. В Вашем случае, инкапсуляция "пробивается".

E>Можно ли расшифровать термин "пробивается" в контексте нашего диалога?

Да пожалуйста... Клиент PDU вынужден участвовать в реализации поведения, которое — якобы — инкапсулировано в PDU.

E>В корне не согласен. Реализации клиентов PDU, которые сами выбирают контекст (к которым и относится session_t) обязаны знать про все поддерживаемые контексты. Поскольку они будут делать выбор либо из указателей на методы, либо из классов-верификаторов.

Уже интересно. Только с чего Вы взяли, что Ваш session_t относится к типу клиентов "которые сами выбирают контекст"? Если мне не изменяет память, "контекст" выбирает клиент session_t через вызов

void established( version_t & version );

Поэтому-то я его и привел Вам в пример.

E>Если же какой-то клиент получает контекст откуда-то извне, то ему безразлично, получит ли он контекст в виде указателя на метод или в виде указателя на объект-верификатор. В C++ указатель на метод даже предпочтительнее, т.к. не тебуется забота о времени его жизни (в отличии от указателя на объект-верификатор).

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

Автор: gbear
Дата: 07.07.05

, акцентирую Ваше внимание на курсиве:

V>Понятно, что поступило предложение вынести процедуру проверки "в отдельное место". Он бы так и сделал, если бы встретил хотя бы второе место для использования.

Походу, таки, не понятно

Курим дальше...

Все что предлогается — либо сделать проверку неявной — "подразумеваемой" если можно так сказать. Либо явно задавать контекс проверки. Остальное, по большому счету, вода.

С невозможностью неявной проверки худо-бедно разобрались. Но казалось бы, какая проблема сделать у pdu_t метод check который принимает входным параметром указатель метод check_ver_x_y?

E>>>Что требуется -- так это то, чтобы клиент выбрал нужный метод check_ver_x_y. Но и в случае с visitor-ом клиент так же должен выбрать нужный класс Check_Ver_X_Y. И вероятность ошибки клиента, имхо, что для неправильного выбора метода, что для неправильного выбора визитора -- одинакова.

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

E>Не понимаю о чем ты. Если клиент должен делать выбор контекста, то он где-то должен будет написать:

Это относится только к клиентам "которые сами выбирают контекст"... К коим, по моему опыту, может относиться только программа использующая библиотеку... и то не всегда. Библиотечный же код к таким клиентам не относится. Контексты и PDU ему даются извне.

E>так вот я отаюсь при мнении, что допустить ошибку в любом из этих if-деревьев можно с одинаковой вероятностью. Поэтому для клиента, который сам выбирает контекст проверки нет никакой разницы, из чего выбирать. Из указателей на методы, или из указателей на объекты.

Согласен. Но для Вас есть разница — переписать лишь классы xxx_pdu_t, или, вдобавок, переписать ещё и библиотечных клиентов PDU. Ведь есть же? Признайтесь

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

E>Кроме того, я не вижу никакой аналогии с обсуждаемой нами проблемой проверки корректности PDU.

Ой зря... Примерно, тоже самое предлагает session_t для своих клиентов.

<Про "негров" и "шерифов" поскипано>

G>>Охотно верю... Только ведь качество библиотеки определяется как раз удобством её использования. Мне, как клиенту библиотеки, сугубо фиолетово как Вы добъетесь того, чтобы мне жилось удобно. Библиотеки они для клиентов пишуться. Или у Вас по другому?

E>Мне проще -- я сам являюсь ее клиентом. И сразу пишу так, чтобы мне было удобно.

Т.е. клиентов у Вашей библиотеки нет? Или они тоже Ваши?

G>>Чтож.. опять на пальцы.

G>>Возмем Ваш же класс session_t. Этот класс вынужден изменяться каждый раз когда появляется новый метод проверки. Этого можно было бы избежать... Вам самому-то не смешон вполне возможный диалог:

G>>- Кто session_t трогал?
G>>- Я.
G>>- Нафиг?!
G>>- Да новая версия протокола вышла. Учили PDU проверяться под ней.
G>>- И...?
G>>- Что и?! Вот session_t и пришлось "трогать".
G>>- У нас что, session_t отвечает за проверку PDU?!
G>>- Да нет... Всю проверку PDU инкапсулирует.
G>>-

E>Ну и что мне этот диалог должен был показать?

Абсурдность заявления, что "Всю проверку PDU инкапсулирует". Если бы это было действительно так, то класс session_t не менялся бы.

E>Представь, что session_t контролирует корректность PDU с помощью объекта-верификатора. Выходит новая версия протокола, выходит новый объект-верификатор. session_t должен научится его использовать. Поэтому весь приведенный диалог повторится в точности, т.к session_t будут создавать объект-верификатор.

Ой нет... Ещё раз. С чего это Вы отнесли session_t к клиентам "которые сами выбирают контекст"?

G>>Вообще, представим себе некую простую библиотеку которая ничем кроме сериализации, десериализации и валидации PDU не занимается. Ей, как клиенту Вашей библиотеки, сугубо фиолетовы нюансы реализаций PDU в каких-либо версиях.

E>Я не могу себе представить библиотеку сериализации/десериализации, которой фиолетовы детали реализации PDU в конкретных версиях. Что собственно это библиотека будет сериализовать/десериализовать.

pdu_t. Разве интерфейсы по [де]сериализации у Вас объявляются где-то ниже?! Тогда совершенно не понятно что делает с pdu_t process_outgoing?

E>>>Какие вопросы?

G>>Например, почему process_outgoing кидает NullReferanceException вместо внятного сообщения — "не задана версия протокола"

E>Потому, что process_outgoing вообще не кидает NullReferenceException. Хотя бы потому, что это C++.

Хм... Это следует понимать так, что если я вызову proccess_outgoing до того как был вызван established, то никакого исключения сгенерировано не будет? Т.е. клиент получит вообще undefined-behaviour, так чтоли?!

---
С уважением, Сиваков Константин.

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

E>>Можно ли расшифровать термин "пробивается" в контексте нашего диалога?

G>Да пожалуйста... Клиент PDU вынужден участвовать в реализации поведения, которое — якобы — инкапсулировано в PDU.

Не согласен. PDU инкапсулирует проверку конкретной версии. А выбор версии -- это дело клиента.

E>>В корне не согласен. Реализации клиентов PDU, которые сами выбирают контекст (к которым и относится session_t) обязаны знать про все поддерживаемые контексты. Поскольку они будут делать выбор либо из указателей на методы, либо из классов-верификаторов.

G>Уже интересно. Только с чего Вы взяли, что Ваш session_t относится к типу клиентов "которые сами выбирают контекст"? Если мне не изменяет память, "контекст" выбирает клиент session_t через вызов

С того, что это так и есть.

G>

G>void established( version_t & version );
G>

Особенность прокола в том, что после установления TCP/IP подключения происходит обмен bind-ами. В ответном bind_resp сервер сообщает номер версии. И клиент должен использовать в дальнейшем данный номер. Вот и предполагается, что метод established будет вызываться после того, как TCP/IP сессия будет установлена и пройдет несколько обменов.

G>С невозможностью неявной проверки худо-бедно разобрались. Но казалось бы, какая проблема сделать у pdu_t метод check который принимает входным параметром указатель метод check_ver_x_y?

А зачем?

E>>>>Что требуется -- так это то, чтобы клиент выбрал нужный метод check_ver_x_y. Но и в случае с visitor-ом клиент так же должен выбрать нужный класс Check_Ver_X_Y. И вероятность ошибки клиента, имхо, что для неправильного выбора метода, что для неправильного выбора визитора -- одинакова.

G>С тем исключением, что правельность визитора можно проверить в методе PDU.

Особенно, если его указатель будет не 0, а 0xdeadbeaf

G>Согласен. Но для Вас есть разница — переписать лишь классы xxx_pdu_t, или, вдобавок, переписать ещё и библиотечных клиентов PDU. Ведь есть же? Признайтесь

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

G>Т.е. клиентов у Вашей библиотеки нет? Или они тоже Ваши?

Библиотека -- это всего лишь часть реализации нашего внутреннего продукта, с которым клиенты общаеются по стандартному SMPP протколу.

G>Абсурдность заявления, что "Всю проверку PDU инкапсулирует". Если бы это было действительно так, то класс session_t не менялся бы.

Класс session_t должен был бы поменяться даже в случае использования объектов-верификаторов. Просто для того, чтобы иметь возможность создавать нового объекта-верификатора. Именно это сейчас и происходит.

E>>Я не могу себе представить библиотеку сериализации/десериализации, которой фиолетовы детали реализации PDU в конкретных версиях. Что собственно это библиотека будет сериализовать/десериализовать.

G>pdu_t. Разве интерфейсы по [де]сериализации у Вас объявляются где-то ниже?! Тогда совершенно не понятно что делает с pdu_t process_outgoing?

У меня нет интерфейсов для [де]сериализации pdu -- этим сам pdu и занимается. И эта функциональность в process_outgoing и используется.

G>Хм... Это следует понимать так, что если я вызову proccess_outgoing до того как был вызван established, то никакого исключения сгенерировано не будет? Т.е. клиент получит вообще undefined-behaviour, так чтоли?!

А кто тебе сказал что не будет? Я что, приводил полный код process_outgoing?