Re[21]: Функциональные типы (параллельная ветка)
От: gbear Россия  
Дата: 29.06.05 09:25
Оценка: +1
День добрый... Пожалуй и я со своими тараканами влезу...

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

E>Ага. Предположим у тебя есть объект типа TextFormatter и объект типа DiskFormatter. У обоих есть метод void format(). Захотел бы ты получить делегат, который вызывает метод format у неизвестно какого объекта? Прямо как русская рулетка -- либо текст отфоматирует, либо диск, на котором этот текст должен лежать.


E>Но даже для таких извращенцев в C++ есть способы получить удовольствие:

Код поскипан...

Вы будете смеятся, но... вот как сие "удовольствие" выглядит на C#


using System;

namespace ConsoleApplication
{

    public delegate void FormatDelegate(); //Сие есть ни что иное, как указатель на метод без привязки к экземпляру. В Вашем понимании, конечно.

    class Drive
    {
        public void Format()
        {
            Console.WriteLine("Format drive");
        }
    }

    class Text
    {
        public void Format()
        {
            Console.WriteLine("Format text");
        }
    }

    class MainClass
    {
        [STAThread]
        static void Main(string[] args)
        {
            Drive c = new Drive();
            Text t = new Text();
            new FormatDelegate(c.Format)(); //Вызвали формат Drive.C
            new FormatDelegate(t.Format)(); // И тут же отворматировали текст
            (new FormatDelegate(c.Format) + new FormatDelegate(t.Format))()// А тут вызвали сразу и то и другое...;
            Console.ReadLine();
        }
    }
}



E>>> Делегат же, насколько я понял из твоих объяснений, это тот же указатель, который намертво связан с конкретным объектом. Поэтому применить делегат к другому объекту этого же типа уже не реально (правильно?).


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


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


См. код выше... Я думаю, что Влад просто уже устал повторять, что делегат это ТИП, и с этой точки зрения он как раз и не связан ни с каким экземпляром другого типа. Но экземпляр делегата конкретного типа, должен быть связан с объектом (исключая связь со статическими методами). Т.к. иначе, что Вы собераетесь через него "дергать, имея лишь "голую" ссылку на метод...

---
С уважением, Сиваков Константин.
Re[19]: Функциональные типы (параллельная ветка)
От: gbear Россия  
Дата: 29.06.05 09:45
Оценка:
Здравствуйте, eao197, Вы писали:

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


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>и попытались десериализовать этот двоичный файл, что получится?

Какушка... Но сдается мне, ISerializable Вас спасет. Не устраивает стандартный механизм... Реализуем данный интерфейс ручками... Так как нам это нужно/хочеться. BinaryFormatter, да и любой другой форматтер, тут, собственно, и не причем.

---
С уважением, Сиваков Константин
Re[22]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 09:50
Оценка: 6 (2)
Здравствуйте, gbear, Вы писали:

G>День добрый... Пожалуй и я со своими тараканами влезу...


Милости просим

G>
G>using System;

G>namespace ConsoleApplication
G>{

G>    public delegate void FormatDelegate(); //Сие есть ни что иное, как указатель на метод без привязки к экземпляру. В Вашем понимании, конечно.
        // В моем понимании это аналог typedef в C++, т.е. тип указателя.
...
G>}
G>



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


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


G>См. код выше... Я думаю, что Влад просто уже устал повторять, что делегат это ТИП, и с этой точки зрения он как раз и не связан ни с каким экземпляром другого типа. Но экземпляр делегата конкретного типа, должен быть связан с объектом (исключая связь со статическими методами). Т.к. иначе, что Вы собераетесь через него "дергать, имея лишь "голую" ссылку на метод...


Ok. Давайте будем для четкости использовать "тип делегата" и "экземпляр делегата" (равно как "тип указателя на метод" и "экземпляр указателя на метод").

Так вот я прекрасно понимаю, что "тип делегата" никак не связан к конкретным экземпляром объекта (так же, как и тип указателя на метод). Но вот экземпляр делегата (как мне уже объяснил AndrewVK) может быть либо связан со статическим методом, либо с нестатическим методом конкретного объекта (т.е., экземпляр делегата связан с конкретным объектом). Но не может быть экземпляра делегата, связанного с нестатическим методом, но не имеющего объекта. А это означает, что если в твоем примере мы создали экземпляр делегата для t.Format(), то связать этот же делегат с c.Format() мы уже не сможем. Так же мы не сможем сделать делегат для вызова метода Format у любого неизвестного пока объекта типа Text.

А вот в C++ мы можем создать экземпляр указателя на метод Format объектов типа Text, не имея самого объекта этого типа. И затем использовать этот указатель для вызова метода Format у любого объекта типа Text без пересоздания самого экземпляра указателя на метод.

И именно поэтому я считаю, что механизм указателей на методы в C++ является более общим, т.к. он:

1) позволяет как связать указатель с конкретным объектом (посредством дополнительных оберток, как в моем примере или средствами boost-а),

2) создавать экземпляр указателя на конкретный нестатический метод без наличия самого объекта.

В C# п.1 получается автоматом, т.к. для этого есть поддержка со стороны компилятора. В C++, можно сказать, такая поддержка так же есть со стороны boost.

А вот как получить реализацию п.2 в C#?

PS

Просьба не апелировать к тому, что экземпляры указателей на методы без объектов не нужны. Я их использую, значит мне нужны. И, имхо, их использую не только я.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 09:52
Оценка:
Здравствуйте, gbear, Вы писали:

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


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


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>>и попытались десериализовать этот двоичный файл, что получится?

G>Какушка... Но сдается мне, ISerializable Вас спасет. Не устраивает стандартный механизм... Реализуем данный интерфейс ручками...


Т.е. и в С# я буду вынужден делать свой велосипед?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Функциональные типы (параллельная ветка)
От: Cyberax Марс  
Дата: 29.06.05 09:54
Оценка:
gbear wrote:

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

> Какушка... Но сдается мне, ISerializable Вас спасет. Не устраивает
> стандартный механизм... Реализуем данный интерфейс ручками... Так как
> нам это нужно/хочеться. BinaryFormatter, да и любой другой форматтер,
> тут, собственно, и не причем.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[19]: Функциональные типы (параллельная ветка)
От: olegkr  
Дата: 29.06.05 10:09
Оценка:
Здравствуйте, eao197, Вы писали:

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

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

Вообще говоря, типичный пример того случая, когда нужно использовать XmlSerializer.
Re[23]: Функциональные типы (параллельная ветка)
От: olegkr  
Дата: 29.06.05 10:14
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


Ну раз используешь, то можешь привести небольшой пример.
Re[20]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 10:22
Оценка:
Здравствуйте, olegkr, Вы писали:

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


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

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

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


С XML-то все понятно. Интересен был случай именно с двоичным форматом.

Предлагаю не устраивать флейм на тему XML vs binary формат, т.к. есть масса областей, где XML -- самый правильный выбор, так же, впрочем, как и масса областей, где XML проигрывает двоичным форматам по всем параметрам.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 10:24
Оценка:
Здравствуйте, olegkr, Вы писали:

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


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


O>Ну раз используешь, то можешь привести небольшой пример.


Они уже были преведены: Re[22]: Функциональные типы (параллельная ветка)
Автор: eao197
Дата: 28.06.05
, с последующим обсасыванием в Re[26]: Функциональные типы (параллельная ветка)
Автор: eao197
Дата: 28.06.05
.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[23]: Функциональные типы (параллельная ветка)
От: gbear Россия  
Дата: 29.06.05 10:53
Оценка: 68 (3) +1 :)
Здравствуйте, eao197, Вы писали:

G>>См. код выше... Я думаю, что Влад просто уже устал повторять, что делегат это ТИП, и с этой точки зрения он как раз и не связан ни с каким экземпляром другого типа. Но экземпляр делегата конкретного типа, должен быть связан с объектом (исключая связь со статическими методами). Т.к. иначе, что Вы собераетесь через него "дергать, имея лишь "голую" ссылку на метод...


E>Ok. Давайте будем для четкости использовать "тип делегата" и "экземпляр делегата" (равно как "тип указателя на метод" и "экземпляр указателя на метод").


Добро...


E>Так вот я прекрасно понимаю, что "тип делегата" никак не связан к конкретным экземпляром объекта (так же, как и тип указателя на метод). Но вот экземпляр делегата (как мне уже объяснил AndrewVK) может быть либо связан со статическим методом, либо с нестатическим методом конкретного объекта (т.е., экземпляр делегата связан с конкретным объектом). Но не может быть экземпляра делегата, связанного с нестатическим методом, но не имеющего объекта. А это означает, что если в твоем примере мы создали экземпляр делегата для t.Format(), то связать этот же делегат с c.Format() мы уже не сможем. Так же мы не сможем сделать делегат для вызова метода Format у любого неизвестного пока объекта типа Text.


Мягко говоря не совсем так... Даже в таком тупом примере, я вам показал делегат, который одновременно связан и с t.Format() и с с.Format.

Еще раз, но другими словами...


            Drive c = new Drive();
            Text t = new Text();
            FormatDelegate dd = new FormatDelegate(c.Format); //Создали делегат, связанный с "c.Format"
            FormatDelegate td = new FormatDelegate(t.Format); //Создали делегат, связанный с "t.Format"
            FormatDelegate tdd = dd + td; //А этот делегат связан с уже и с тем и с другим.
            tdd(); //c.Format + t.Format;
            tdd -= dd; //Теперь ttd связан только с "t.Format";
            tdd();
            tdd -= td;// А теперь tdd не связан уже ни с чем. Т.е. равен null.
            if(tdd == null)
                Console.WriteLine("tdd is null");
            Console.ReadLine();




E>А вот в C++ мы можем создать экземпляр указателя на метод Format объектов типа Text, не имея самого объекта этого типа. И затем использовать этот указатель для вызова метода Format у любого объекта типа Text без пересоздания самого экземпляра указателя на метод.

E>И именно поэтому я считаю, что механизм указателей на методы в C++ является более общим, т.к. он:
E>1) позволяет как связать указатель с конкретным объектом (посредством дополнительных оберток, как в моем примере или средствами boost-а),
E>2) создавать экземпляр указателя на конкретный нестатический метод без наличия самого объекта.

E>В C# п.1 получается автоматом, т.к. для этого есть поддержка со стороны компилятора. В C++, можно сказать, такая поддержка так же есть со стороны boost.

E>А вот как получить реализацию п.2 в C#?

E>PS

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

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

Далее, собственно, по существу...

1. Поскольку делегат (как тип), ко всему прочему не превязан к конкретному типу — в отличие от... то он, таки, имхо, более общ.
2. Для того функционала (пункты 1 и 2) делегаты, собсвенно не нужны... Вот как это выглядит на "голом" рефлекшене:

using System;
using System.Reflection;

namespace ConsoleApplication
{
    class Formater
    {
        private int _id = 0;
        public Formater(int id)
        {
            _id = id;
        }

        public void Print()
        {
            Console.WriteLine(string.Format("Formater: {0}", _id));
        }
    }

    class Binder
    {
        private MethodInfo _method = null;
        public Binder(MethodInfo method)
        {
            _method = method;
        }

        public void Call(object o)
        {
            _method.Invoke(o, null);
        }
    }

    class MainClass
    {
        [STAThread]
        static void Main(string[] args)
        {
            Formater f1 = new Formater(1);
            Formater f2 = new Formater(2);
            Binder b = new Binder(typeof(Formater).GetMethod("Print")); //Типа, экземпляр "голого" указателя на метод Print класса Formater;
            b.Call(f1); //Вызываем print у f1;
            b.Call(f2); //Вызываем print у f2;
            Console.ReadLine();
        }
    }
}


Устроит?

---
С уважением, Сиваков Константин.
Re[21]: Функциональные типы (параллельная ветка)
От: gbear Россия  
Дата: 29.06.05 11:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>gbear wrote:


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

>> Какушка... Но сдается мне, ISerializable Вас спасет. Не устраивает
>> стандартный механизм... Реализуем данный интерфейс ручками... Так как
>> нам это нужно/хочеться. BinaryFormatter, да и любой другой форматтер,
>> тут, собственно, и не причем.

C>Во многих системах сериализации для классов можно указывать политику

C>преобразований из предидущих версий этих классов.

А можно, поинтересоваться, что значит "предидущих версий этих классов"? В терминах, каких-нибудь других "систем сериализации" естественно...

---
С уважением, Сиваков Константин.
Re[21]: Функциональные типы (параллельная ветка)
От: gbear Россия  
Дата: 29.06.05 11:07
Оценка:
Здравствуйте, eao197, Вы писали:

G>>Какушка... Но сдается мне, ISerializable Вас спасет. Не устраивает стандартный механизм... Реализуем данный интерфейс ручками...


E>Т.е. и в С# я буду вынужден делать свой велосипед?


В смысле?! Т.е. это смотря что понимать под велосипедом...

---
С уважением, Сиваков Константин.
Re[24]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 11:14
Оценка: 2 (1)
Здравствуйте, gbear, Вы писали:

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


G>Еще раз, но другими словами...


G>
G>            Drive c = new Drive();
G>            Text t = new Text();
G>            FormatDelegate dd = new FormatDelegate(c.Format); //Создали делегат, связанный с "c.Format"
G>            FormatDelegate td = new FormatDelegate(t.Format); //Создали делегат, связанный с "t.Format"
G>            FormatDelegate tdd = dd + td; //А этот делегат связан с уже и с тем и с другим.
G>            tdd(); //c.Format + t.Format;
G>            tdd -= dd; //Теперь ttd связан только с "t.Format";
G>            tdd();
G>            tdd -= td;// А теперь tdd не связан уже ни с чем. Т.е. равен null.
G>            if(tdd == null)
G>                Console.WriteLine("tdd is null");
G>            Console.ReadLine();
G>


Ok. Но это не то, что нужно. См. ниже.

E>>PS

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

G>Тем не менее, до тех пор пока Вы таки не объясните нам сирым зачем же Вам так нужны "голые" указатели на методы, если для их использования Вам таки придется связывать их (указатели) с конктретными объектами, Я оставляю за собой право аппелировать к этому. Без обид. Мне это действительно не совсем понятно.


Надеюсь, что ты прочитал остальные сообщения топика и видел мой пример. Поэтому скажу, что голый указатель, естественно, рано или поздно, так или иначе связывается с конкретным объектом для проведения вызова. Мне же нужно, чтобы экземпляр указателя на метод появился до того как появится конкретный объект. Вот ты привел выше пример делегата из которого вычли все, что в нем было. Но для того, чтобы использовать этот экземпляр делегата с другим объектом, скажем d, я должен буду сделать:
tdd += new FormatDelegate(d.Format);

т.е. я явно должен буду указать, что от объекта d мне нужен именно метод Format, а не FormatVer1_2 или QuickFormat. А мне бы хотелось, чтобы в одном месте, без объектов, сначала определили Format, FormatVer1_2 или QuickFormat будет вызываться, а уже затем, в другом месте применяли это вызов к конкретному объекту. Но, видимо, в .Net это решается через рефлекшен.

G>Далее, собственно, по существу...


G>1. Поскольку делегат (как тип), ко всему прочему не превязан к конкретному типу — в отличие от... то он, таки, имхо, более общ.


Лично я не понял этого аргумента совершенно. Тип, который не привязан к конкретному типу -- это можно более простыми словами, мне, сирому, объяснить?

G>2. Для того функционала (пункты 1 и 2) делегаты, собсвенно не нужны... Вот как это выглядит на "голом" рефлекшене:

...
G>Устроит?

По функциональности да (хотя статическая типизация здесь заменяется на динамическую), по производительности -- вряд ли.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 11:24
Оценка:
Здравствуйте, gbear, Вы писали:

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


G>>>Какушка... Но сдается мне, ISerializable Вас спасет. Не устраивает стандартный механизм... Реализуем данный интерфейс ручками...


E>>Т.е. и в С# я буду вынужден делать свой велосипед?


G>В смысле?! Т.е. это смотря что понимать под велосипедом...


Константин, я понимаю, что ты пока не в теме разговора, но я уже Владу устал объяснять, что бывают случаи, когда:
— была исходная схема данных;
— были клиенты A и В, которые сериализовали данные по этой схеме;
— у клиента A схема данных расширилась и он стали сериализовать свои данные в новой схеме, про которую клиент B не знает;
— когда клиент B получает от клиента A сериализованные данные, он должен беспрепятственно их десериализовать.

С XML-сериализацией все, в принципе понятно. Интереснее с двоичной сериализацией.
Поддерживают ли стандартные средства двоичной сериализации .Net какой-нибудь механизм, который бы позволил клиенту B безболезненно десериализовать данные клиента A?
Если их нет, то создание такого средства и будет велосипедом.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[23]: Функциональные типы (параллельная ветка)
От: gbear Россия  
Дата: 29.06.05 11:38
Оценка:
Здравствуйте, eao197, Вы писали:

E>Константин, я понимаю, что ты пока не в теме разговора, но я уже Владу устал объяснять, что бывают случаи, когда:

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

E>С XML-сериализацией все, в принципе понятно. Интереснее с двоичной сериализацией.

E>Поддерживают ли стандартные средства двоичной сериализации .Net какой-нибудь механизм, который бы позволил клиенту B безболезненно десериализовать данные клиента A?
E>Если их нет, то создание такого средства и будет велосипедом.

Стандарное средство, это вроде как реализация ISerializable... Т.к. на всех "стандартных" средст не напасёшся.

А велосибед, с этой точки зрения:
1. Вы чем думали когда закладывались на такую схему данных?
2. Какая проблема перевести клиента B на расширенную схему... Может быть ему, это "расшиерение" тоже нужно. В смысле, если мы обмениваемся с клиентом B — и вдруг клиент A расширяет передаваемый набор данных, то для меня вполне логично, что это нужно не самому A, а как раз B.
3. Если оно таки не нужно — то все зависит от того КАК расширили схему. Этож можно по разному реализовать. Если так, как Вы предлогали в своем примере — то какушка гарантирована. Причем я так на вскидку и не скажу, спасет ли от этого ручной ISerializable.

---
С уважением, Сиваков Констатин.
Re[24]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 12:00
Оценка: :)
Здравствуйте, gbear, Вы писали:

G>А велосибед, с этой точки зрения:

G>1. Вы чем думали когда закладывались на такую схему данных?
G>2. Какая проблема перевести клиента B на расширенную схему... Может быть ему, это "расшиерение" тоже нужно. В смысле, если мы обмениваемся с клиентом B — и вдруг клиент A расширяет передаваемый набор данных, то для меня вполне логично, что это нужно не самому A, а как раз B.
G>3. Если оно таки не нужно — то все зависит от того КАК расширили схему. Этож можно по разному реализовать. Если так, как Вы предлогали в своем примере — то какушка гарантирована. Причем я так на вскидку и не скажу, спасет ли от этого ручной ISerializable.

Прочитай, плз, Re[14]: Версии интерфейсов
Автор: eao197
Дата: 24.06.05
и Re[18]: Функциональные типы (параллельная ветка)
Автор: eao197
Дата: 29.06.05
. А так же рекомендую, для общего развития, хотя бы бегло просмотреть книгу ASN.1 Complete by Prof John Larmouth -- знакомство с такой технологией, как ASN1 сильно расширяет кругозор.

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




К разработчикам RSDN и Януса: сделайте, пожалуйста, иконку с харакири. Ну очень нужно.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Функциональные типы (параллельная ветка)
От: Cyberax Марс  
Дата: 29.06.05 12:12
Оценка:
gbear wrote:

> C>Во многих системах сериализации для классов можно указывать политику

> C>преобразований из предидущих версий этих классов.
> А можно, поинтересоваться, что значит "предидущих версий этих
> классов"? В терминах, каких-нибудь других "систем сериализации"
> естественно...

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

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

Сериализация MFC примерно так же работает. В Java новые поля просто
будут нолями после десериализации старых данных (если не изменился class
id, тогда будет exception).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[25]: Функциональные типы (параллельная ветка)
От: gbear Россия  
Дата: 29.06.05 12:26
Оценка: 20 (1) +2
Здравствуйте, eao197, Вы писали:

E>Надеюсь, что ты прочитал остальные сообщения топика и видел мой пример. Поэтому скажу, что голый указатель, естественно, рано или поздно, так или иначе связывается с конкретным объектом для проведения вызова. Мне же нужно, чтобы экземпляр указателя на метод появился до того как появится конкретный объект. Вот ты привел выше пример делегата из которого вычли все, что в нем было. Но для того, чтобы использовать этот экземпляр делегата с другим объектом, скажем d, я должен буду сделать:

E>
E>tdd += new FormatDelegate(d.Format);
E>

E>т.е. я явно должен буду указать, что от объекта d мне нужен именно метод Format, а не FormatVer1_2 или QuickFormat. А мне бы хотелось, чтобы в одном месте, без объектов, сначала определили Format, FormatVer1_2 или QuickFormat будет вызываться, а уже затем, в другом месте применяли это вызов к конкретному объекту. Но, видимо, в .Net это решается через рефлекшен.

Ну собсвенно, более менее понятно...

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

Вот например. Мы имеет несколько (пусть два) класса у которых есть метод с сигнатурой void (int). В вашем случае Вам придется описать два "указателя" на этот метод (по одному для каждого класса). Так? В случае с делегатами это будет один делегат.
void SomeDelegate(int a)


Например так...

Вот собсвенно и все... Просто это, наверное, накладывает ограничения на дизайн... может и на что-то другое. Просто, имхо, тот же пример с pdu_t прекрасно "ложиться" на шаблон Visitor — и никакие указатели и делегаты тут, собственно, не нужны. Если уж приспичило через делегаты, то тут надо подходить с точки зрения ФП... Т.е. например, в session_t.process_outgoing передавать делегат с конкретной ф-цей проверки конкретного экземпляра наследника pdu_t... Да и сам pdu_t в этом случае, собственно не нужен.

G>>Далее, собственно, по существу...

G>>1. Поскольку делегат (как тип), ко всему прочему не превязан к конкретному типу — в отличие от... то он, таки, имхо, более общ.

E>Лично я не понял этого аргумента совершенно. Тип, который не привязан к конкретному типу -- это можно более простыми словами, мне, сирому, объяснить?


См. выше... Когда Вы делаете typedef определяя тип указателя на метод, Вы указываете метод конкретного класса... В определении делегата ссылки на какие-либо другие классы отсутсвуют.

---
С уважением, Сиваков Константин.
Re[26]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 12:38
Оценка: +1
Здравствуйте, gbear, Вы писали:

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


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

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


Вот именно, что накладывает.

G> Просто, имхо, тот же пример с pdu_t прекрасно "ложиться" на шаблон Visitor — и никакие указатели и делегаты тут, собственно, не нужны. Если уж приспичило через делегаты, то тут надо подходить с точки зрения ФП...


Да, можно через Visitor. А можно и без. В C++ есть свобода выбора, что хорошо.

G> Т.е. например, в session_t.process_outgoing передавать делегат с конкретной ф-цей проверки конкретного экземпляра наследника pdu_t... Да и сам pdu_t в этом случае, собственно не нужен.


process_outgoing может инициировать много разных действий. И все что ему нужно для работы -- это объект pdu_t. Грузить метод process_outgoing дополнительными параметрами в виде делегатов для проверки -- это уже маразмом попахивает. Уж лучше в методе established() создавать и сохранять объект visitor.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Функциональные типы (параллельная ветка)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.06.05 12:48
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


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


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


Кроме того, через boost или самодельные примочки, одну из которых я показывал, это без проблем достигается в C++.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.