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

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

E>>Теперь понятно. Но в таком подходе знание структуры PDU требуется сразу трем сущностям:
E>>1. Самому PDU. Ну это понятно, т.к. PDU должен предоставлять физическое хранилище для полей PDU.
E>>2. Клиенту PDU. Что так же понятно. Какой смысл клиенту получать PDU, если он с ним ничего не может сделать.
E>>3. Объекту-протоколу. А еще лучше обозвать его верификатором протокола. Получается, что верификатор протокола должен знать все про PDU и при этом еще должен знать ограничения на размеры и значения полей.

G>Протокол не должен знать ничего о реализации конкретного типа DPU. Он знает или о тот какие ограничения на данный тип PDU он накладывает... Просто у pdu_t вместо кучи Chek_Ver_X_Y было бы всего два метода:


G>

G>bool CheckProtocol(Protocol protocol);

G>Constraint[] GetConstraints();
G>

G>constraint — некий тип формально описывающий ограничение — т.е. позволяющий отличать одно ограничение от другого. Саму реализацию... например, информацию о реальном размере поля этот тип может и не содержать. Для Протокола важно просто сравнить свой список для этого типа PDU с тем списком который ему вернёт PDU. Вот и всё.

Ну вот, еще одна штука появилась -- Constraint.
Кроме того, у протокола-то список Constraint-ов то откуда-то должен взяться. Более того, он должен не один, а для каждого типа PDU. Т.е. протокол все равно будет вынужден знать и про PDU и про списки Constraint-ов для этого PDU. Т.е. знания все равно придется распространять.

G>Соответсвенно у protocol_base_t будет, например, метод:

G>

G>ConstraintData GetConstraintData(Constraint constraint);
G>

G>Этот метод используется PDU чтобы получить данные о конеретном ограничении, чтобы он мог сравнить их со своей реализацией данного ограничения. Ведь именно DPU у нас решает может или нет он функционировать в рамках данного протокола. Для самого Протокола важно лишь убедиться что DPU проверил и нашёл удовлетворительными все ограничения котороые он (Протокол) наклакладывает на него (PDU).

Здесь представь сколько геморроя будет в проверке менее тривиальных органичений (не только размеры и значения). Скажем, если поле f1 присутствует, то обязательно должно присутствовать и поле f2. А если у поля f3 значение равно v1, то у поля f4 не может быть значения v2.

E>>Собственно мне не нравится, что появляется еще одна сущность (верификатор), в которой полные знания о протоколе и PDU должны быть. Т.к. эту сущность нужно создавать и сопровождать. А ведь вполне можно обойтись всего тремя сущностями.

G>См. выше. Протокол о структуре PDU незнает ничего... ему важен лишь конкретный тип PDU. Естественно, если под структурой Вы подразумеваете не список ограничений, а конкретную реализацию PDU.

Под структурой я понимаю public-интерфейс в виде getter-ов/setter-ов.

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

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

Нет, я увидет то, что ты предлагал в примерах с GetConstraintData, GetConstraints и CheckProtocol.

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

VD>>В общем, пора завязывать религиозную пропаганду внутри этой секты.

V>Оформи это плиз отдельным постом — поставлю наивысшую отметку!

Да чё уж там. Ща статью сбацаем.

V>-------
V>Зачем нам его пропагандировать, если мы и сами на него перелазим. (Sinclair-а и Wolfhound-а уже потеряли, ПК на очереди )

Ужас какой?!!! Мы их теряем.

V>Просто мы позволяем себе (пока?) в то же самое время не отказываться и от других полюбившихся, и тоже весьма мощных в своей стезе инструментов.

Свобода выбра? Ужасная вещь.

V> А тут прилетает Влад на взмыленном коне,

Ну, ну... какие кони? На Ту 134М.

V> и шашкой, и шашкой. Заметь, нам ведь по большей части приходится оправдываться.
V>Не стыдно?

Это значит теперь называется оправдываться? И потом не стыдно целым полком артилерии на одну шашку то?

V>В общем, действительно, пора завязывать. Вроде не дураки все, с общим положением вещей давно определились. А предпочтения — дело сугубо личное, ok?

+1

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

E>Здесь представь сколько геморроя будет в проверке менее тривиальных органичений (не только размеры и значения). Скажем, если поле f1 присутствует, то обязательно должно присутствовать и поле f2. А если у поля f3 значение равно v1, то у поля f4 не может быть значения v2.

Мы так и не понимаем друг друга Ну не заставляет никто знать протокол об ограничениях в объеме: "если поле f1 присутствует, то обязательно должно присутствовать и поле f2"... Не нужно это. Я же по нескольку раз за пост повторяю... реализацию конкретного ограничения знает только PDU. Если хотите... PDU знает алгоритм проверки ограничения. Протокол может лишь предоставить для этого алгоритма недостающие в PDU данные (к коим относятся, например, допустимые размеры полей). Курим дальше...

G>>См. выше. Протокол о структуре PDU незнает ничего... ему важен лишь конкретный тип PDU. Естественно, если под структурой Вы подразумеваете не список ограничений, а конкретную реализацию PDU.

E>Под структурой я понимаю public-интерфейс в виде getter-ов/setter-ов.

Их гораздо меньше, чем в Вашем решении.

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

Безусловно. Мухи (список ограничений) — отдельно, котлеты (реализация орграничений) — отдельно. Список ограничений для протокола — это спецификация конкретной версии протокола. Реально большой объем работы — при реализации первой версии. Вторая версия базируется на ней.

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

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

E>>Здесь представь сколько геморроя будет в проверке менее тривиальных органичений (не только размеры и значения). Скажем, если поле f1 присутствует, то обязательно должно присутствовать и поле f2. А если у поля f3 значение равно v1, то у поля f4 не может быть значения v2.

G>Мы так и не понимаем друг друга Ну не заставляет никто знать протокол об ограничениях в объеме: "если поле f1 присутствует, то обязательно должно присутствовать и поле f2"... Не нужно это. Я же по нескольку раз за пост повторяю... реализацию конкретного ограничения знает только PDU. Если хотите... PDU знает алгоритм проверки ограничения. Протокол может лишь предоставить для этого алгоритма недостающие в PDU данные (к коим относятся, например, допустимые размеры полей). Курим дальше...

Вот, вот, золотой ключик уже почти у нас в кармане
Так зачем же к выделенному добавлять еще и сущность протокол в котором еще должен быть какой-то список ограничений?

G>>>См. выше. Протокол о структуре PDU незнает ничего... ему важен лишь конкретный тип PDU. Естественно, если под структурой Вы подразумеваете не список ограничений, а конкретную реализацию PDU.

E>>Под структурой я понимаю public-интерфейс в виде getter-ов/setter-ов.

G>Их гораздо меньше, чем в Вашем решении.

Ровно на количество методов: check_ver_N_M.

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

G>Безусловно. Мухи (список ограничений) — отдельно, котлеты (реализация орграничений) — отдельно. Список ограничений для протокола — это спецификация конкретной версии протокола. Реально большой объем работы — при реализации первой версии. Вторая версия базируется на ней.

Вот на счет того, что вторая базируется на первой -- это сильно зависит от протокола и от того, сколько всего нового добавили в новую версию.

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

G>>Мы так и не понимаем друг друга Ну не заставляет никто знать протокол об ограничениях в объеме: "если поле f1 присутствует, то обязательно должно присутствовать и поле f2"... Не нужно это. Я же по нескольку раз за пост повторяю... реализацию конкретного ограничения знает только PDU. Если хотите... PDU знает алгоритм проверки ограничения. Протокол может лишь предоставить для этого алгоритма недостающие в PDU данные (к коим относятся, например, допустимые размеры полей). Курим дальше...

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

Затем, чтобы уйти от необходимости пересобирать дерево pdu_t при возникновении новой версии... соответсвенно, и от неоходимости повторной верификации кода. Двух моментов кардинально противоречащих ОО модели.

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

E>>>Под структурой я понимаю public-интерфейс в виде getter-ов/setter-ов.

G>>Их гораздо меньше, чем в Вашем решении.

E>Ровно на количество методов: check_ver_N_M.

Вы учтите, что я пытаюсь давать решение... адаптированное, так сказать, под C++ восприятие. В .NET реализации списки ограничений можно задавать декларативно, например, через атрибуты. Но это уже, издержки реализации.

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

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

G>>>Мы так и не понимаем друг друга Ну не заставляет никто знать протокол об ограничениях в объеме: "если поле f1 присутствует, то обязательно должно присутствовать и поле f2"... Не нужно это. Я же по нескольку раз за пост повторяю... реализацию конкретного ограничения знает только PDU. Если хотите... PDU знает алгоритм проверки ограничения. Протокол может лишь предоставить для этого алгоритма недостающие в PDU данные (к коим относятся, например, допустимые размеры полей). Курим дальше...

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

G>Затем, чтобы уйти от необходимости пересобирать дерево pdu_t при возникновении новой версии... соответсвенно, и от неоходимости повторной верификации кода. Двух моментов кардинально противоречащих ОО модели.

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

А в твоем подходе -- сделать новый класс, реализующий интерфейс конкретного PDU и запрограммировать те же самые проверки, но уже в виде отдельных Constraint. Которые все равно не могут жить без своего конкретного PDU.

Кроме того, ОО -- это не абсолютная добродетель или абсолютная истина. Это всего лишь один из подходов. Который совершенно спокойно и успешно можно комбинировать с другими подходами. Даже в рамках одного проекта.

G>Плюс, возможность уйти от неявной задачи контекста — которая тоже совсем не подарок.

Ну не вижу я неявной задачи контекста.
Когда у PDU вызывается конкретный метод check_ver -- контекст известен.
Когда кто-то собирается вызвать у PDU конкретный метод check_ver -- он так же точно знает контекст. Даже если этот контекст ему передали в виде указателя на метод.
А то, что где-то номер версии преобразуется в указатель на метод путем if-ов, так его точно так же пришлось бы преобразовывать к Visitor-у или Checker-у.

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

<Очередные "непонятки" с пересбокой пока поскипаны>

G>>Плюс, возможность уйти от неявной задачи контекста — которая тоже совсем не подарок.

E>Ну не вижу я неявной задачи контекста.
E>Когда у PDU вызывается конкретный метод check_ver -- контекст известен.

Да ну !? Из Ващего же примера:

        void process_outgoing( const pdu_t & pdu )
            {
                // Проверяем корректность PDU.
                (pdu.*m_checker)();
                ...
            }

Какой метод будет вызван? Это и назвается неявное определние контекста. Конекст определён где-то... может быть. Самое весёлое, то что Вы не сможете гарантировать определённость конетекста в точке валидации. Одно этого, имхо, более чем.

E>А то, что где-то номер версии преобразуется в указатель на метод путем if-ов, так его точно так же пришлось бы преобразовывать к Visitor-у или Checker-у.

Да нет же!!! Номер версии вообще никак не влияет на контекст. Курим дальше...

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

VladD2 wrote:

> C>А чего же там не стандартизованы: WinForms, ADO.NET? Стандарт на сам
> C>язык мало кому нужен.
> Во как? Стандарт плюсов никому не нужен? Он же не включает ни
> WinForms, ни ADO.NET.

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

> C>ИМХО, SUN со своей Явой поступил честнее — они сразу заявили, что не
> C>хотят ее стандартизовать, чтобы не терять контроля.
> Эко твое мнение от контекста зависит. Сначала лепил горбатого про
> нестандартизированность C#, а как узнал, что облажался так сразу про
> честность заговорил.

Я про стандартизованность С# знаю уже года 4

> C> Ну а MS в качестве
> C>рекламы стандартизовал язык и почти что заставляет программистов
> C>использовать нестандартые либы.
> Ага. Гоняется и заставляет.

Нет, просто вставляет своими грязными визардами.

> C>Причина очень простая: мне не нужен reflection (точнее в одном месте с
> C>помощь compile-time рефлексии было бы чуть получше, но и без нее вполне
> C>нормально).
> Понятно. Ну поглядим что ты запоешь когда через 3 года появится тот
> самый рефлекшон от Струструпа.

Добавлю его в свою систему.

> Он правда скорее всего будет в виде библиотечки оформлен... и при
> компиляции не доступен...

Агащаз. Собираются добавить compile-time рефлексию и реализовать с
помощью нее уже runtime-рефлексию (да, библиотекой). Вполне в духе С++.

> ЗЫ
> Вообще мне слушать фантов плюсов все смешнее и смешнее.

s\плюсов\C#\g

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

G><Очередные "непонятки" с пересбокой пока поскипаны>

G>>>Плюс, возможность уйти от неявной задачи контекста — которая тоже совсем не подарок.

E>>Ну не вижу я неявной задачи контекста.
E>>Когда у PDU вызывается конкретный метод check_ver -- контекст известен.

G> Да ну !? Из Ващего же примера:

G>

G>        void process_outgoing( const pdu_t & pdu )
G>            {
G>                // Проверяем корректность PDU.
G>                (pdu.*m_checker)();
G>                ...
G>            }
G>

А чем бы это отличалось от:

class    session_t
    {
        // Это указатель на базовый класс Checker-а.
        checker_t *    m_checker;
    ...
        void process_outgoing( const pdu_t & pdu )
            {
                pdu.check( *m_checker );
                // Ну или так: m_checker->check( pdu );
                ...
            }
    ...
    };

G>Какой метод будет вызван? Это и назвается неявное определние контекста. Конекст определён где-то... может быть. Самое весёлое, то что Вы не сможете гарантировать определённость конетекста в точке валидации. Одно этого, имхо, более чем.

Какой checker будет задействован?

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

E>А чем бы это отличалось от:

<код поскипан>

E>Какой checker будет задействован?

Вы издеваетесь?! Вы что, хотите меня убедить в том, что Вы не понимаете разничу между: "указатель на метод не определён" и "входной параметр метода не определён"?

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

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

E>>Какой checker будет задействован?

G> Вы издеваетесь?! Вы что, хотите меня убедить в том, что Вы не понимаете разничу между: "указатель на метод не определён" и "входной параметр метода не определён"?

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

Но в данном конкретном случае я вообще не понимаю термина "указатель на метод не определен". Это-то здесь откуда взялось?

Сейчас я вижу две точки зрения:

1. Код по проверке корректности PDU сосредоточен в самих PDU и вызывается посредством виртуальных методов одинакового формата (типа void check_ver_3_4(), void check_ver_5_0()). Поэтому, для того, чтобы четко определить конктекст, в котором будет производится проверка, нужно определить, какой конкретно метод должен быть вызван. Для этого достаточно проинициализировать указатель на метод:

typedef void (pdu_t::*checker_proc_t)();

checker_proc_t checker = &pdu_t::check_ver_5_0; // Или &pdu_t::check_ver_3_4().

2. Код по проверке корректности PDU сосредоточен где-то рядом с PDU, но для его инициирования нужно задействовать специальный объект верификатор (построенный на основе паттерна Visitor). Тогда контекст, в котором производится проверка, четко определяется объектом-верификатором. Для этого нужно создать объект-верификатор:

checker_visitor_t * checker = new check_ver_5_0_t(); // Или new check_ver_3_4_t();

Так вот после того, как переменная checker проинициализирована (не важно, чем именно она является: указателем на метод или указателем на объект) она и есть контекст. И поэтому запись:

// Т.е. вызов либо check_ver_5_0, либо check_ver_3_4.
(pdu.*checker)();

для меня эквивалентна:

pdu.check( *checker );

т.к. контекст (то бишь версия и связанные с ней ограничения) уже определен при инициализации checker.

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

ПК>>Под делегатами нет более базового понятия, непосредственно, без "хэков", доступного в языке C#; но это не значит, что в их реализации нет некоторой более базовой сущности, аналогичной указателям на члены в C++, пусть эта сущность в C# и недоступна.

AVK>А кой черт мне рассматривать особенности конкретной реализации, если речь идет о концепциях языка?

Речь идет о концепциях, которые могли бы быть в языке. Очевидно, что ограничившись только тем, что уже есть, подобный разговор вести вообще смысла не имеет. В данном случае. вне зависимости от реализации, даже в ее описании, неизбежно будет присутствовать нечто, идентифицирующее метод, и позволяющее его вызвать. В C# это нечто на уровень языка решили не выводить, в C++ -- вывели.

ПК>>Просто в C++ указатели на функции-члены сделали доступными в языке, а в C# — нет.

AVK>Ты о MethodInfo? Он в языке доступен.

Нет, не о нем, а о том, через что осуществляется вызов методов, т.е. то, что используется в InternalInvoke, по-моему, IntPtr _methodPtr.

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

G>> Вы издеваетесь?! Вы что, хотите меня убедить в том, что Вы не понимаете разничу между: "указатель на метод не определён" и "входной параметр метода не определён"?

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

Вот и ладушки.

E>Но в данном конкретном случае я вообще не понимаю термина "указатель на метод не определен". Это-то здесь откуда взялось?

E>Сейчас я вижу две точки зрения:

E>1. Код по проверке корректности PDU сосредоточен в самих PDU и вызывается посредством виртуальных методов одинакового формата (типа void check_ver_3_4(), void check_ver_5_0()). Поэтому, для того, чтобы четко определить конктекст, в котором будет производится проверка, нужно определить, какой конкретно метод должен быть вызван. Для этого достаточно проинициализировать указатель на метод:
E>

E>typedef void (pdu_t::*checker_proc_t)();

E>checker_proc_t checker = &pdu_t::check_ver_5_0; // Или &pdu_t::check_ver_3_4().
E>

Ключевым моментом при таком подходе является то, что инициализация указателя на метод происходит "где-то там, может быть" относительно точки верификации. Если инициализация указателя происходит в точке верификации, то все "приимущества" такого подхода теряются. Так вот, единственный выход убрать "может быть" — проводить инициализацию указателя в конструкторе. Это, согласитесь, далеко не всегда приемлемо. А раз так, то в точке верифиации необходима дополнительная проверка определенности указателя. Без такой проверки получается система с неопределенным поведением, т.к. гарантировать отработку кода инициализации указателя перед попаданием в точку верификации мы не сможем.

Другими словами, при таком подходе в точке верификации гарантируется наличие объекта; наличие контекста, в силу возможности неопределенности указателя, не гарантируется (исключая, инициализацию указателя через конструктор).

E>2. Код по проверке корректности PDU сосредоточен где-то рядом с PDU, но для его инициирования нужно задействовать специальный объект верификатор (построенный на основе паттерна Visitor). Тогда контекст, в котором производится проверка, четко определяется объектом-верификатором. Для этого нужно создать объект-верификатор:
E>

E>checker_visitor_t * checker = new check_ver_5_0_t(); // Или new check_ver_3_4_t();
E>

Ключивым моментом при таком подходе является то, что в точке верификации гарантируется и наличие объекта, и наличие контекста.

E>Так вот после того, как переменная checker проинициализирована (не важно, чем именно она является: указателем на метод или указателем на объект) она и есть контекст.

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

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

Здравствуйте, gbear

Ну вот, точка наших разногласий, наконец, окончательно выкристализовалась.

E>>

E>>typedef void (pdu_t::*checker_proc_t)();

E>>checker_proc_t checker = &pdu_t::check_ver_5_0; // Или &pdu_t::check_ver_3_4().
E>>

G>Ключевым моментом при таком подходе является то, что инициализация указателя на метод происходит "где-то там, может быть" относительно точки верификации. Если инициализация указателя происходит в точке верификации, то все "приимущества" такого подхода теряются. Так вот, единственный выход убрать "может быть" — проводить инициализацию указателя в конструкторе. Это, согласитесь, далеко не всегда приемлемо. А раз так, то в точке верифиации необходима дополнительная проверка определенности указателя. Без такой проверки получается система с неопределенным поведением, т.к. гарантировать отработку кода инициализации указателя перед попаданием в точку верификации мы не сможем.

Имхо, все тоже самое можно отнести и к определению указателя на объект -- см.ниже.

G>Другими словами, при таком подходе в точке верификации гарантируется наличие объекта; наличие контекста, в силу возможности неопределенности указателя, не гарантируется (исключая, инициализацию указателя через конструктор).

В точности тоже самое я могу сказать и о случае с объектом-верификатором: в точке верификации гарантируется наличие PDU-объекта. Наличие же объекта верификатора будет определяться тем, проинициализировали ли мы его раньше (в том же конструкторе) или нет.

E>>2. Код по проверке корректности PDU сосредоточен где-то рядом с PDU, но для его инициирования нужно задействовать специальный объект верификатор (построенный на основе паттерна Visitor). Тогда контекст, в котором производится проверка, четко определяется объектом-верификатором. Для этого нужно создать объект-верификатор:
E>>

E>>checker_visitor_t * checker = new check_ver_5_0_t(); // Или new check_ver_3_4_t();
E>>

G>Ключивым моментом при таком подходе является то, что в точке верификации гарантируется и наличие объекта, и наличие контекста.

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

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

E>>Так вот после того, как переменная checker проинициализирована (не важно, чем именно она является: указателем на метод или указателем на объект) она и есть контекст.

G>Вы ошибаетесь. В Вашем решении конктекст — это не указатель на метод. В Вашем решении контекст — это метод check_ver_x_y.

Я бы сказал, что check_ver_x_y -- это контекст проверки конкретной версии безотносительно наличия/отсутствия коммуникационной сессии. А вот указатель на конкретный метод -- это контекст проверки конкретной версии в рамках конкретной коммуникационной сессии. В случае же с Visitor-ом, конкретный класс visitor-верификатор будет контекстом проверки конкретной версии безотносительно наличия/отсутствия коммуникационной сессии. А вот объект visitor-верификатор -- это это контекст проверки конкретной версии в рамках конкретной коммуникационной сессии.

Но это уже просто вкусовые различия, имхо.

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

G>>Ключевым моментом при таком подходе является то, что инициализация указателя на метод происходит "где-то там, может быть" относительно точки верификации. Если инициализация указателя происходит в точке верификации, то все "приимущества" такого подхода теряются. Так вот, единственный выход убрать "может быть" — проводить инициализацию указателя в конструкторе. Это, согласитесь, далеко не всегда приемлемо. А раз так, то в точке верифиации необходима дополнительная проверка определенности указателя. Без такой проверки получается система с неопределенным поведением, т.к. гарантировать отработку кода инициализации указателя перед попаданием в точку верификации мы не сможем.

E>Имхо, все тоже самое можно отнести и к определению указателя на объект -- см.ниже.

Различия этих подходов очень просто проиллюстрировать.

1. Клиент вынужден явно передавать контекст в метод проверки.
2. Проверку определенности контекста можно (и нужно) организовать внутри метода проверки.
3. Вам не нужно требовать от клиентов определенной очерёдности вызовов.

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

Здравствуйте, gbear

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

G>Различия этих подходов очень просто проиллюстрировать.

G>1. Клиент вынужден явно передавать контекст в метод проверки.

О каких клиентах и каких методах идет речь?

Если вернуться к моему примеру к session_t и pdu_t, то клиентом является объект session_t, который спокойно определяет у себя указатель на нужный метод проверки. Точно так же, как если бы он созал у себя visitor-верификатор. Дл pdu_t вообще ничего не нужно -- его метод check_ver_x_y() самодостаточен.

G>2. Проверку определенности контекста можно (и нужно) организовать внутри метода проверки.


Если честно, вообще не понял о чем здесь речь.

G>3. Вам не нужно требовать от клиентов определенной очерёдности вызовов.

В моем подходе:
1. Определяется указатель на метод проверки.
2. По указателю вызывается метод для конкретного объекта pdu.

В твоем подходе:
1. Создается объект-верификатор.
2. У конкретного объекта pdu вызывается метод проверки с передачей ему объекта-верификатора.

Все тоже самое.

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

C>VladD2 wrote:

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

Это твое мнение. И по мне так высосанное из пальца. Претензии к С++ в основ крутятся вокруг дизайна языка.

C>Я про стандартизованность С# знаю уже года 4

Темболее странны подобные заявления. Хотя это тоже странное, так как С# 3 года от роду.

>> C> Ну а MS в качестве
>> C>рекламы стандартизовал язык и почти что заставляет программистов
>> C>использовать нестандартые либы.
>> Ага. Гоняется и заставляет.

C>Нет, просто вставляет своими грязными визардами.

Что, простите?

C>Добавлю его в свою систему.

А как же слова про ненужность? Или это эдакий МС-ный подход когда не нужно то чего не имешь, а как оно появляется, то сразу начинаешь все расскзаывать, что без этого жить нельзя?

>> Он правда скорее всего будет в виде библиотечки оформлен... и при
>> компиляции не доступен...

C>Агащаз. Собираются добавить compile-time рефлексию и реализовать с
C>помощью нее уже runtime-рефлексию (да, библиотекой). Вполне в духе С++.

Я незнаю о чем ты говоришь. Я поглядел презинтаху Страуструпа. Можешь и сам пошукать гугль на слово XTI. Там совершенно ясно, что речь идет о аналоге рефлекшона. К компайл-тайму это отношение не имеет. Это именно что рефлекшон для рантайма.

VladD2 wrote:

> C>Агащаз. Собираются добавить compile-time рефлексию и реализовать с
> C>помощью нее уже runtime-рефлексию (да, библиотекой). Вполне в духе С++.
> Я незнаю о чем ты говоришь. Я поглядел презинтаху Страуструпа. Можешь
> и сам пошукать гугль на слово XTI. Там совершенно ясно, что речь идет
> о аналоге рефлекшона. К компайл-тайму это отношение не имеет. Это
> именно что рефлекшон для рантайма.

Это была предидущая версия, сейчас они собираются делать compile-time.
Была дискуссия на openstd, кажется.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

E>Тем, что вокруг C++ не было мощного финансового центра, который бы продвигал C++. Для Java таким центром является Sun.

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

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

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

E>>Тем, что вокруг C++ не было мощного финансового центра, который бы продвигал C++. Для Java таким центром является Sun.

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

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

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