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

G>Собственно, на мой взгяд корень непонимая в том, что такой подход — "сначала определили Format, FormatVer1_2 или QuickFormat будет вызываться, а уже затем" Вам навязан невозможностью иметь в C++ указатель на метод объекта произвольного класса. То что Вы имеете — это указатель на метод объекта определенного класса. Хм... Попробую подругому...

+1

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

Действительно говоря о делегате логически речь идет о ссылке на рантаймную сущьность — метод экземпляра. Это не более узкое решени или не более широкое, а прост другое. Далее остается только понять, что данную ссылку можно получить в рантайме в любой момент. Причем как в лучших традициях С++ с помощью статического кода, так и динамически через рефлекшон или от другого компонента.

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

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

VD>>Ясно. Прямого ответа на вопрос я не получу. Ну, да понятно почему...

E>Почему? Просвети меня, а то я в полном непонимании нахожусь.

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

E>Влад, ты можешь сколь угодно много и долго сомневаться и иронизировать по поводу моей компетенции, но Abstract Syntax Notation One -- это очень серьезная штука, которая развивается уже почти двадцать лет. И стандарт Asn1 прошел уже несколько ревизий. Так что случайные или не нужные вещи там еще поискать нужно. И extension points -- это одно из ключевых понятий в Asn1.

Возможно. Не буду спорить. Но мы говорим кажется о функциональных типах. Не объяснишь какое отношение имеет Asn1 к этой области?

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

E>1. Можно ли избежать сериализации полей, которые имеют значения по умолчанию?

Можно.

E>2. Допустим, структура A (я пользуюсь C++ синтаксисом) сначала имела вид:
E>

E>struct    A
E>    {
E>        int    m_a;
E>        std::string m_s;
E>    };
E>

E>ее сериализовали в двоичный файл. Затем структуру расширили:
E>

E>struct    A
E>    {
E>        int    m_a;
E>        std::string m_s;
E>        double m_d;
E>    };
E>

E>и попытались десериализовать этот двоичный файл, что получится?

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

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

E>Влад, ты когда нибудь видел спецификации телекомуникационных протоколов? Например, SMPP или какого-нибудь GSM протокола?

Нет. Но видел другие.

E> Как ты думаешь, куда там можно вставить обмен кодом?

В протокол и не нужно. Все что связано с подкачкой типов с сервера можно вывести в отдельный фрэймворк.

E>>>Вот именно. Но я говорю о случаях, когда сериализация/десериализация на разных сторонах делается по разным версиям описания схемы данных.

VD>>Звучит не разумно.

E>Тем не менее, такое со временем случается. Даже, afaik, носит название "проблемы второй версии протокола". Особенно актуально это для двоичных протоколов (и здесь рулят Asn1 с его extension points), хотя и со структурированными текстовыми (XML в частности) такие вещи случаются.

Сериализацию старой версией, а десериализацию новой я понять могу. Но наоборот — нет.

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

C>Например, в boost::serialization в функцию load передается номер версии
C>класса (целое число, по умолчанию 0), в функции save это число сохраняется.

C>Соответственно, если загружается более древняя версия данных, то это
C>можно обработать отдельно (установить новые поля в дефолтное значение и
C>т.п.). У нас есть свое дополнение к boost.s11n, которое позволяет
C>задавать поведение в виде специальных политик.

Это ручная сериализация. Это где угодно можно сделать.

VladD2,

> E> Это достаточно грубая и неумелая попытка уйти от конкретного вопроса.
>
> Тебе объяснили, что "рабоать" с методами в отрыве от объекта бессмысленн.

Ну-ну... Вызов одного и того же метода у всех элементов коллекции — бессмысленно?

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

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

E>>Это достаточно грубая и неумелая попытка уйти от конкретного вопроса.

VD>Тебе объяснили, что "рабоать" с методами в отрыве от объекта бессмысленн. И объяснили, что все что можно сделать с помощью указатели на методы классов С++ можно сделать с помощью делегатов. Делегат это вообще очень гибкая вещь.

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

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

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

E>>Это уже, как говорится, второй вопрос.
E>>Т.е., я был прав, говоря, что в C++ мы можем иметь указатель на нестатический метод без объекта, а в C# -- вряд ли.

VD>Ага. Только это ровным счетом ничего не значит. Так как использовать указатель без сслки на объект все равно не удастся, а делегат прекрасно может создаваться динамически что позволяет делать все что угодно.

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

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

См. Re[25]: Функциональные типы (параллельная ветка)

Автор: VladD2
Дата: 29.06.05

-- я полностью подписываюсь под тем, что там написано.

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

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

Т.е. предложенного мной примера с pdu_t не достаточно?

Класный способ отрицать то, что есть.

VD>Поробую объяснить еще раз. Ты вбил себе в голову ошибочную догму, что мол указатель в котором нет (назавем его так) this более универсален нежели указатель который содержит в себе этот самый this. Но на практике люди думают объектами и им просто нет необходимости делать ссылку со сменным объектом.
VD>С другой стороны ты не хочешь принимать аргументы связанные с тем, что привязка указателя к методам конкретного класса резко сужает область применения этой фичи. Другими словами это частное решение. Я был бы не против если бы такое частное решение существовало бы, при условии, что есть более универсальное решение позволяющее ссылаться на любой метод с нужной сигнатурой.

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

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

VD>Где ты взял неудобства? Придумываешь на ходу себе проблемы и ударно с ними борешся. Забуть что это сообщения видовс. Оцени прсто саму идею. Тебе тут уже АВК привел пример с декларативным описанием действия в Янусе. Но ты и его умудрился не понять.

E>> Лично мне, когда я стал использовать макросы из windowsx.h программировать стало проще.

VD>Ну, так попрограммируй на том же ВинФормс и поймешь, что тратил последние несколько лет зря. Там макросы не нужны.

Последние несколько лет если и доводилось програмировать GUI, то на Qt. А про макросы из windowsx.h я только сейчас и вспомнил. Именно из-за того, что даже они были удобнее того декларативного решения.

E>> И более того, избавило от проблем при переходе на 32-х битовый Windows, когда упаковка параметров в некоторых сообщениях изменилась. А приведенный код мне не понравился тем, что из-за декларативности все обработчики оконных событий имели одинаковую сигнатуру, хотя давно было доказано, что это неудобно.

VD>Это тут не причем! Нельзя из пальца высасать описание конкретного сообщения. Вот и одинаковы сгнатуры.

Вот именно! В вашей декларативности вы даже не знаете, обработчик какого сообщения декларируется. В то время как даже в макросах из windowsx.h это было известно. Я бы сказал "Вау!" если бы мне привели код:

[WinMsg(WM_RBUTTONDOWN)]
bool OnRButtonDown( bool fDoubleClick, int x, int y, uint keyFlags )
{
        BackColor = Color.Blue;
        return true;
}

[WinMsg(WM_LBUTTONDOWN)]
bool OnLButtonDown( bool fDoubleClick, int x, int y, uint keyFlags )
{
        BackColor = Color.Red;
        return true;
}

[WinMsg(WM_MOUSEMOVE)]
bool OnMouseMove( int x, int y, uint keyFlags )
{
    ...
}

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


E>>Полный код класса KeyboadShortcatsMap делать, естественно, не буду.

VD>Естествено. Иначе была бы сразу видна вся мощь С++.

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

E>> А вот парсинг конфига:
<...>
VD>Это парсер ХМЛ-я?

А причем здесь XML? Я тебе приводил формат конфига и код, который этот конфиг парсит.

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

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

VD>>>Ясно. Прямого ответа на вопрос я не получу. Ну, да понятно почему...

E>>Почему? Просвети меня, а то я в полном непонимании нахожусь.

VD>Потому что ты не хочешь принять другие решения, а без их принятия ты никогда не увидишь ущербности тех к которым ты привык.

А мне не приводят других решений. Про XML я и так понимаю. А вот про двоичные данные?

E>>Влад, ты можешь сколь угодно много и долго сомневаться и иронизировать по поводу моей компетенции, но Abstract Syntax Notation One -- это очень серьезная штука, которая развивается уже почти двадцать лет. И стандарт Asn1 прошел уже несколько ревизий. Так что случайные или не нужные вещи там еще поискать нужно. И extension points -- это одно из ключевых понятий в Asn1.

VD>Возможно. Не буду спорить. Но мы говорим кажется о функциональных типах. Не объяснишь какое отношение имеет Asn1 к этой области?

Нет, не я выбирал название топика при его выделении из предыдущей темы.

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

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

Я про ущербность ничего не говорил. Я пытался понять положение вещей.

E>> Как ты думаешь, куда там можно вставить обмен кодом?

VD>В протокол и не нужно. Все что связано с подкачкой типов с сервера можно вывести в отдельный фрэймворк.

И что дальше? Кто-то держит SMPP канал и гоняет там SMPP PDU, а рядом открывается еще один канал для подкачки недостающего кода?

E>>>>Вот именно. Но я говорю о случаях, когда сериализация/десериализация на разных сторонах делается по разным версиям описания схемы данных.

VD>>>Звучит не разумно.

E>>Тем не менее, такое со временем случается. Даже, afaik, носит название "проблемы второй версии протокола". Особенно актуально это для двоичных протоколов (и здесь рулят Asn1 с его extension points), хотя и со структурированными текстовыми (XML в частности) такие вещи случаются.

VD>Сериализацию старой версией, а десериализацию новой я понять могу. Но наоборот — нет.

Вот именно. Тем не менее, такие возможности востребованны.

IT,

> V> Более того, понятие function object несомненно более широкое понятие, чем Delegate. Делегат — лишь частный случай, осуществляющий делегирование вызовов третьей стороне. А оно не всегда нужно, вот в чем дело-то (хотя, очень удобно для GUI).
>
> V> Новоявленные анонимные делегаты как раз пытаются решить проблему избавления от "третей стороны",

> Насколько мне известно, анонимные делегаты — это просто синтаксический сахарок. Никаких новых концепций в язык они не привносят.

А методом какого класса является анонимная функция, связываемая с анонимным делегатом, и с каким объектом этого класса она связана?

Здравствуйте, Павел Кузнецов, Вы писали:
>> Тебе объяснили, что "рабоать" с методами в отрыве от объекта бессмысленн.

ПК>Ну-ну... Вызов одного и того же метода у всех элементов коллекции — бессмысленно?

Это динамичская типизация. Многих тут просто кондражка хватит от такого предложения.

Andrei N.Sobchuck wrote:

> ПК>Ну-ну... Вызов одного и того же метода у всех элементов коллекции —
> бессмысленно?
> Это динамичская типизация. Многих тут просто кондражка хватит от
> такого предложения.

Вы это о чем?

Например, есть коллекция векторов (трехмерные векторы), у каждого нужно
вызвать фукнцию normalize. Как вы это сделаете с делегатами?

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

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

ПК>А методом какого класса является анонимная функция, связываемая с анонимным делегатом, и с каким объектом этого класса она связана?

Методом какого-то левого (сгенерированного компилятором специально для этой цели) класса и каким-то левым объектом.

Cyberax,

> Например, есть коллекция векторов (трехмерные векторы), у каждого нужно
> вызвать фукнцию normalize. Как вы это сделаете с делегатами?

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

Завести в вызывающем классе метод, принимающий ссылку на вектор, и создать делегат, связав this с данным методом.

(C# 2.0) Проинициализировать делегат анонимным методом, вызывающим нужную функцию вектора.

Воспользоваться reflection.

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

Второй способ является иллюстрацией желательности вызывать функции у объектов, к которым нет привязки в точке создания делегата. Отличие указателей на члены от анонимных делегатов в том, что указатели на члены являются более базовым механизмом, позволяющим реализовать описанное, но основным назначением указателя на член является идентификация члена класса. Делегаты идентифицировать метод/данные класса не позволяют, поддерживая только один из аспектов указателей на члены.

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

Posted via RSDN NNTP Server 2.0 beta

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

>> Тебе объяснили, что "рабоать" с методами в отрыве от объекта бессмысленн.

ПК>Ну-ну... Вызов одного и того же метода у всех элементов коллекции — бессмысленно?

Ну это как раз сделать совсем несложно. Как бы ты это делал на плюсах?

IT,

>>> Тебе объяснили, что "рабоать" с методами в отрыве от объекта бессмысленн.

> ПК> Ну-ну... Вызов одного и того же метода у всех элементов коллекции — бессмысленно?

> Ну это как раз сделать совсем несложно. Как бы ты это делал на плюсах?

Я знаю, что это сделать несложно (по крайней мере, если есть анонимные делегаты). Вопрос не в сложности, а в осмысленности. Имхо, бессмысленным такое действо называть как-то странно.

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

>> Ну это как раз сделать совсем несложно. Как бы ты это делал на плюсах?

ПК>Я знаю, что это сделать несложно (по крайней мере, если есть анонимные делегаты). Вопрос не в сложности, а в осмысленности. Имхо, бессмысленным такое действо называть как-то странно.

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

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

G>>Занчится так... Что у нас есть:
G>>1. Клиент.
G>>2. Маршрутизатор.
G>>3. Обработчик.

E>Ага, только во множественном числе.
Не вопрос...

G>>

G>>клиент отсылает запросы на сервер и каждый запрос должен уникальным образом однозначно идентифицироваться

G>>Кем, идентифицироваться? Если клиентом — то для этого ему совсем не обязательно, посылать некий id серверу. Или не согласны? Даже в случае асинхронного взаимодействия — совсем, необязательно.

E>Если каждый запрос идет через свой канал (как http-запросы), то не нужен, в принципе. Хотя лучще все же идентификаторы со стороны клиента на сторону сервера передавать, если обработка запроса может занять длительное время.
E>А если все идет через один канал, да еще в асинхронном режиме, то идентификатор еще как нужен.

В смысле, один end-point? Но, даже в этом случае соглашусь только в случае, если порядок доставки сообщений неопределён.

G>> В случаее, если знать тип id маршрутизатору не пологается... а пологается знать только базовый тип, то и работать он с ним смогЕт только как с базовым... Причем виртуальность в этом случае строго противопоказана... на стороне маршрутизатора нет кода типа id. Правильно?

E>А кто сказал, что нет. Есть Как и информация о том, что этот тип производен от базового типа.

Э-э-э... А в чем тогда, собственно, проблема-то? Спрашиваю, потому как здесь

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

:

Ключевым моментом в паттерне Asynchronous Completion Token является то, что объект ACT, в общем случае, является непрозрачным для сервера (т.е. сервер совершенно не знает, что именно находится в ACT).

Если же учитывать Ваше же:

А кто сказал, что нет. Есть Как и информация о том, что этот тип производен от базового типа.

То всё решается просто:

1. Есть некий ACTBase. От этого класса каждое звено цепочки пораждает свой — такой какой ей хочеться — ACT.
2. Сам ACTBase нечто похожее на:

    [Serializable]
    public class ACTBase
    {
        private ACTBase _previousACT = null;
        
        public void Pin(ACTBase previousACT)
        {
            _previousACT = previousACT;
        }
        
        public ACTBase PreviousACT
        {
            get
            {
                return _previousACT;
            }
        }
    }

Т.е., например, маршрутизатор, получив запрос от клиента, генерирует свой ACT к которому "прикалывает" ACT, полученый в запросе. ACT маршрутизатора уходит далее по цепочке. При возврате, каждое звено возвращает ACTBase.Previous от своего ACT.

G>> Т.е. клиент, в этом случае должен сериализовать свой id как базовый тип. Просто потому, что какой смысл посылать на сервер данные с которыми сервер работать все раавно не сможет?!

E>Чтобы получить их в том же самом виде обратно.

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

E>Нет, как раз клиент десериализует свой идентификатор в ответном сообщении именно как свой тип.

Ну если маршрутизатор может сериализовать его как ACT клиента — тогда да... Еще раз... Если все про всех всё знают, в чем прикол?!
Далее поскипано, потому как по всему выходит, что фишку не просек... Пока не разберемся "кто, что про кого знает" далее рассуждать бессмысленно, имхо.

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