для этого, нужен метагенератор, генерирующий метаинформацию из к примеру, такого макроса:

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

т.е. для этого интерфейса должна быть такая реализация:


есть идеи?

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

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


нет. на каждый тип команды свой метод обработчик на сервере.

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

сообщение про список типов видели ? если приведете функции обработчики к одному имени, то выгадаете (не кодогенеруеммую, а шаблонную) автоматизацию


естественно разный, но с таким же именем ))



Это сообщение отредактировал(а) mes - 9.10.2010, 12:56

  нет.

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

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

что имеется в виду?

Добавлено через 5 минут и 26 секунд

имена у них тоже разные:


Это сообщение отредактировал(а) boostcoder - 9.10.2010, 12:55

у буста что то в этом роде : 


ну а сервер выглядит так

т.е. вы предлагаете решение, в котором для идентификации методов используется список типов аргументов? я правильно Вас понял?


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

фактически именем метода будет выступать имя типа пакета..
а чем неудобно одинаковое имя ?

Добавлено через 51 секунду

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

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

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

Добавлено через 2 минуты и 50 секунд
не обязательно напрямую, возможно через прослойку, только внешне не видную.

Добавлено через 4 минуты и 56 секунд
сейчас еще одна идея пришла... надо обдумать.. 

имел в виду их и разобрать.

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

клиент заканчивается отправкой сериализированного объекта в _сокет_.

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

угу.
но вроде как можно приблизительно так(мысли в слух):
на стороне клиента, сгенериный интерфейс используется совместно с классом client<interface>
на стороне сервера, сгенериный интерфейс используется совместно с классом server<interface>
то что генерится, должно содержать в себе какое-то значение времени компиляции которое client<> и server<> будут читать, то можно реализовать их таким образом, чтоб каждый брал для себя только то, что ему нужно. 

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

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

как-то так...

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

и возвращаемся к старому вопросу:
1. что должен генерировать метагенератор на стороне клиента?
2. что должен генерировать метагенератор на стороне сервера?
3. как связать сгенерированную информацию с реальным, написанным нами, классом?

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

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

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

Добавлено через 4 минуты и 45 секунд
насчет сервера... у нас есть некий компонент, который локально выполняет некую работу..
мы должны определить связку между запросом и компонентом..
т.е. на каждый тип запроса у нас должен быть бинд забирающий инфу откомпонента.. 
по идеи значит надо для диспетчера создать таблицу лямб функций возвращаюших ответ, на запрос..

Добавлено через 5 минут и 18 секунд
ну так и получается, что имя функции нам не нужно.. 

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

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

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

да.
я понимаю, что можно запросам присваивать ID`ы. но это пока не главный вопрос.

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

да.


можно реализовать следующим образом: в client<> добавить deadline_timer, который сам будет слать серверу запросы, и при получении ответов, вызывать некоторый обработчик.

но и это не главное.