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

Добавлено через 3 минуты и 7 секунд

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

мой глюк - показалось, что он объект своего типа содержит )

Нет

Нет

Нет

Если позволите, немного резюмирую всё вышесказанное.



мне не нравится, потому что :
а) статическая функция десериализации
б) создаёт не ClassA *, а Base *. А массив указателей на функции - это всегда кажется, что "финт ушами", особенно если в первый раз делать...

Статичность функции ::create я отношу к недостатком, поскольку она не позволяет "каскадно" или по частям десериализовать объект, опираясь на десериализаторы базовых типов. Топикстартеру придётся в static Base * create(CDR * cdr){ ... } разводить помойку, которая при заявленных аппетитах в сотню классов примет формы опасные для здоровья  Большинство участников придерживается другой схемы, виртуальной, а именно виртуальный сериализатор + виртуальный десериализатор или виртуальный сериализатор + конструктор-десериализатор.

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

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

Это сообщение отредактировал(а) marcusmae - 18.2.2008, 22:26

Lazin, скажи пожалуйста, зачем делать в базовом классе невиртуальные методы-обёртки для виртуальных методов? Чем это лучше, почему не следует сразу виртуальные методы  save_() load_() вызывать?

marcusmae, полность с тобой согласен, единственное только хочу сказать, что естественно внутри static create ,будет вызываться функция - член десериализатор с "каскадной" функциональностью либо поток будет передаваться конструктору, и вот тут

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

ИМХО в каждом классе есть метод для превращения класса в кусок потока, и наоборот и есть функция которая по этому куску потока вызывает этот метод для необходимого класса - её функция определить нужный класс. По идее должна быть симметричная  ей функция которая пишет информацию в поток в зависимости от того какой класс записывается, но только потому что класс сам знает свой тип удобнее не делать отдельную функцию, а делать чтобы класс перед тем как "линеаризироваться" записывал информацию о себе сам.
Это две разные задачи и никак не связаны. За вторую задачу может быть ответственен базовый класс, например ISerializable у tol05, первая же задача "каскадно" размазана по методам производных классов. У меня вторая задача тоже размазана по производным классам в статик методах плюс один внешний класс с таблицей которая может быть и внутри базового класса как статический член. Хотя это всё в общем-то довольно удобно, мне кажется что это не очень хорошо. Именно про это и был задан мой вопрос, как лучше (и эффективнее) решить вторую задачу (именно вторую) - нахождение класса из потока, а решение первой задачи довольно тривиальное и тут мало что можно придумать.
Ну вы меня сильно не бейте если чё  

Мне кажется, что всё, что можно придумать на счёт сериализации/десериализации основано на той информации, которую предоставляет поток. Не стоит его содержимое считать фиксированным и очевидным. Все идеи - там.


Ахтычорт, TCP, и правда  Кстати, есть какой-то специфический протокол, построенный для этой задачи над TCP? = Если да, то что он делает?

Чем тебя мое решение не устроило (на 2й странице 3е сверху)?

в моем примере оверхеда на вызов дополнительной ф-ии не будет, компилятор ее просто выкинет. 
А преимуществ масса, почитай про паттерн NVI ^_^

не ну я так не играю!..       

Что значит размазана? Это расширение функциональности в базовом классе и ее поддержка в производных... Зачем же тогда наследование придумано???
Всвязи с тем, что позднего связывания (в том виде, к которому я уже привык) здесь не имеется, я на своем методе обнаружения классов в потоке не настаиваю... Размазанность - это благо. Каждый класс сам обеспечивает свое жизнеобеспечение.

А по поводу статических ф-ций - это ИМХО плохо. Какое преимущество их использования? Из статической ф-ции производного класса нельзя вызвать статическую ф-цию базового класса, как же тогда инициализировать закрытые члены базового класса? В производном классе к ним доступа нет, а в потоке данные о них есть  Передавать указатель на текущий объект производного класса в метод его же базового класса? ... Извините ...

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

И как статические ф-ции обеспечивают потокозащищенность в плюсах? Я не помню просто 

Это сообщение отредактировал(а) tol05 - 19.2.2008, 12:21

georain, 
tol05, 

Я тут ночью думал-думал и вот что надумал. Что вообще хорошего в статических функциях (при том, что они ужасно плохие  )? = А то, что у них адреса фиксированные, и их адын штука на всю генерацию экземпляров класса. А раз так, то пользоваться адресом таких функций просто и удобно (чем georain и воспользовался). Если так уж прям нравится, то предлагаю пойти дальше. Вот эти ваши таблицы функций ... ничего не напоминают? = Дело в том, что таблица функций есть всегда. Ею является образ exe. То есть моя идея состоит в следующем. В начале времён серверу передаётся просто копия экзешника (или библиотеки), который работает на клиенте. Далее, когда понадобится десериализация, предлагается класть в пакет его размер, а за ним - декорированное имя функции, которая "сертифицирована" проводить десериализацию этого пакета :



Сервер получил этот stream, считал размер пакета и имя функции. Имея последнее, сервер лезет в эталонную таблицу и загружает оттуда точку входа функции-десериализатора :



Готово. Копия объекта загружена в LPVOID a. 

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

Архив с полным решением присоединён.

Присоединённый файл ( Кол-во скачиваний: 7 )
 Koder.rar 43,99 Kb

это на каком языке? на плюсах можно, если позволяет видимость...



а если завтра тебе понадобится добавить десяток новых классов, как быть?

ну, понадобится иметь для них десяток функций сериализации - по своей собственной для каждого класса. Ну и декорированные имена через dumpbin посмотреть и забить в константы. Что-то мне подсказывает, что если всё аккуратно сделать, то можно обойтись без имён - одними указателями. По идее, если dll, то у неё фиксированная виртуальная адресация, и адрес функции у клиента и сервера должен быть одинаковый.


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

А вот

- хороший довод. По-моему, никак.


Это сообщение отредактировал(а) marcusmae - 19.2.2008, 14:55

Это называется "нельзя"     

Какое же это наследование, если нужно this в параметры передать??? Я так могу любую ф-цию вызвать и передать указатель на мой класс. Так что, эти классы предками/потомками станут? Я имел в виду использование Base... когда и базовый, и производный класс оперируют с одним и тем же указателем на объект.


мда, по-моему тоже...   

ну да ладно... этот пост можно считать оффтопом.   

xvr

Потому что решение более сложное, а строка

обязывающая для каждого класса писать

остаётся, в чём выгода?


tol05

потому что

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


marcusmae

развеселил, хохот в час ночи. Возможно это даже будет работать, но мне кажется это не очень кроссплатформенно, этож на win-lin-mac-bsd-и.т.д. должно работать, а разный порядок байтов на разных машинах, сомнительное предложение, но прикольно!   

В том, что:
1) Не надо добавлять никаких enum'ов, ID и пр.
2) Количество типов классов может быть любым (не ограничено размером числа, задающего тип)
3) Полная проверка на этапе сериализации, что CREATE_FABRIC не забыли указать (увы, может не сработать при раздельных sender'е и reviever'е)
4) Не нужен никакой switch и никакая другая централизованная обработка - потенциальное место где можно забыть что-то добавить.
5) CREATE_FABRIC - это ЕДИНСТВЕННОЕ что добавляется при сериализации нового класса

П1-4 следствия П5.