пока времени не было продолжить размышления 

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

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

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

попробую для начала набросать вариант такого пакета..

Добавлено @ 22:11
ну пусть выглядит так :

тогда нам нужен адаптер позволяющий вызывать invoke с подходящим ехecutor`ом..


Это сообщение отредактировал(а) mes - 5.12.2010, 22:24

примерно может выглядить так :


1. типобезопасное составление таблицы виртуальных методов  (map_of_executors_t) решается шаблоной функцией добавления в таблицу.. 
2. также таблица естественно внутренность класса, и exec<Т> его метод..
3. производство exec_visitor тоже внутрение, при добавлении в таблицу.. для безопасности каста.. 



Это сообщение отредактировал(а) mes - 5.12.2010, 22:31

простите, конечно, но ни один из пунктов не понял на 100%  

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

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

понял.


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

Это сообщение отредактировал(а) boostcoder - 6.12.2010, 00:10

в результате.. вызов происходит так

out << login (name, pass);

составление таблицы:

map[T::method_id] = new exec_visitor<login>(fn);
где fn - bind или lambda <void (string,string)>

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

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

Добавлено через 3 минуты и 25 секунд
в прошлых примерах вас не устраивало передача посредством сообщениям, и хотелось развернутого вида..
так вот в последнем сообщении пакет описывается именно так :
 login (std::string const& name
       ,std::string const& pass ) : _name (name), _pass (pass) {}
  typedef std::function<void(std::string const&, std::string const&)> executor_t;

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

Добавлено через 4 минуты и 59 секунд
дело в том что с этим пакетом можно многое еще делать прежде чем доставить пользователю.. или другими словами можно по разному доставить пользователю.. вот тут и вопросы, что вообще должно уметь дисколи ? вот над этим и думаю 

Добавлено через 10 минут и 14 секунд
если взять  пример с прошлой страницы, то заметно что мы в нашей схеме теряем параметр _client передаваемый серверу..,
но параметр должен входить в состав пакета, либо он не нужен при использовании юзер_контекста- любой из этих случаев протоколозависим и отношения к дисколи не имеет.. но говорит нам о том, что пример для теста мы выбрали не подходящий.. 

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

аналогично выглядит представитель на серверной стороне :

1. как происходит передача сообщения я умолчал.. пока допустим что  
2.  вместо структуры auth может быть например auth_window

если смысл примера понятен, то вопрос , устраивает ли подобный вид кода ? 


Это сообщение отредактировал(а) mes - 6.12.2010, 01:07

вполне.
а Вас устраивает?

пока вроде да.. пойдем думать дальше..

Добавлено @ 01:18
терь нам нужно в пример добавить диспетчер..

Добавлено @ 01:25
допустим такой :


Это сообщение отредактировал(а) mes - 6.12.2010, 01:36

для ассоциации команд реальным методам, нам все равно нужен meta_proxy<> с промежуточными методами и списком команд. в таком случае, у нас получается ситуация которую я уже приводил: http://liveworkspace.org/code/a14dee96202f...0567a3f20507540
что в таком способе неудобно - это то, что meta_proxy<> должен располагать именами реальных методов в то время, как самой реализации и ее методов еще не существует. чтоб такой код компилировался, нужно воротить шаблонную реализацию. это тоже своего рода неудобность. но удобнее и реальнее способа я не нашел.

Добавлено через 1 минуту

Packet - это P ?

тогда клиент будет:


Добавлено @ 01:36

ага P - исправил..

Добавлено @ 01:40
мне в этом примере не нравится слишком длинная строка 


которую в принципе можно  заменить на такую 


Это сообщение отредактировал(а) mes - 6.12.2010, 09:13

кто такой _auth_dispatcher ?

его я переименовал в _auth_map (исправил в коде)

терь, судя по коду, явно видно, что _auth_map должна быть внутри auth, но, в отличии (от ремоте) не должна быть подключена к соединению..

Добавлено @ 09:43



Это сообщение отредактировал(а) mes - 6.12.2010, 10:39