у метода (on_cts_user::invoke) сигнатура совпадает с хранимой в импульсе.. 
поэтому в текущей схеме мы повторяемся.. 
предположительно лучше вначале описать методы.. а после на их основе генерировать импульсы...
хотя можно внутри этой же структуры добавить идентификатор метода...

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

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

под методом подразумевается структура у которой есть метод инвоке..

Добавлено через 4 минуты и 46 секунд
наследование нужно было , когда я хотел использовать this структуры-метода, для диспатчеризации (crtp)

вот : http://liveworkspace.org/code/4c1431537f72...9daff2f7d5f7ab9
вроде работает  

Добавлено @ 15:53
предполагается что test_emit отправляет мигранта в соединение,
а dy::dispatch вызывается на другом конце для прибиндинного к нему объекта..

Добавлено @ 15:57
теперь образовалось несколько фронтов работы.. 
1.  привести описание протокола в удобный вид
2. докончить эммитера и диспетчера
3. добавить сериализацию
4. реализовыть соединения..

Добавлено @ 16:00
 и.. все , нет никакого наследования в реализации
 

Добавлено @ 16:05
думаю сейчас картина понятна, тогда хотелось бы критики..

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


Это сообщение отредактировал(а) mes - 16.12.2010, 16:06

описание импульса лишнее.. его можно получить зная (прокси-)метод, и ид..
т.е. отправка сигнала может иметь вид :
 emit(cts::on_user, nick, pass) и в зависиммости от эммитера диспатчеризоавться сразу классу или конвертироваться в мигранта и дальше по руслу.. 

разбираюсь..

вот чтоб лишнее не давило : http://liveworkspace.org/code/dfa7631c7201...5f49f8c1445d0a5

Это сообщение отредактировал(а) mes - 16.12.2010, 16:54

вот еще : http://liveworkspace.org/code/5fbca044de1c...6f8158409f2a4c9
набросок того, что видится в дальнейшем..
опорные пункты в комментах..

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

для начала хотелось бы это все за препроцессорить..

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

откуда on_user и on_quit знают имена методов реализации?

от составителя протокола.. имена составляют абстрактный базовый не виртуальный интерфейс.. 

не понял.

и еще просьба: не могли бы Вы, четко, расписать, что нужно генерить, а что нет? ;)

это

фактически является альтернативной формой записи этого:

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

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

четко не могу.. потому что я сам узнаю о чем то, после того как сделаю шаг..
но нам нужно получить шаблонную структуру, у которой есть статическая функция invoke
эта структура или ее специализация должна хранить ид метода и желательно typedef invoke функции (без this-argumenta)..

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

Это сообщение отредактировал(а) mes - 16.12.2010, 17:49

вот может внесет разъяснения :

понял.

Это сообщение отредактировал(а) boostcoder - 16.12.2010, 18:39

cts можно делать не неймспейспом а структурой,
а "макросом метода", после определения структуры пуш_бак`ить к списку методов (cts_mtds::type)

Добавлено через 1 минуту и 21 секунду
тогда получится почти настоящее описание "абстрактного класса(интерфейса)"

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

имеется в иду "DY_METHOD()" ?


поясните.


зы
наконец-то и для меня работа нашлась  

да.. но только DY_METHOD это набросок..я пока не знаю как красивей его выразить..
главное нам нужны набор структур - условно ди_методы..
и список типов - условно ди_класс..

Добавлено @ 19:00
т.е. по идеи что то то такое



а лучше без DY_MTD и id вначале.. 


Добавлено через 7 минут и 23 секунды
но в таком варианте метод принадлежит только одному интерфейсу..
но возможно, (хотя не  знаю нужно ли) чтоб все методы были перечислены отдельно, а из них собирались классы..
с другой стороны ничто не мешает сделать возможным два варианта, на выбор пользователя..

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

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

  , теперь хоть видно что требуется..

Добавлено через 10 минут и 19 секунд
кстати насчет того что идет вызов по имени..
можно будет добавить еще один враппер , который будет превращать dy_class в класс сигналов ..
т.е. вызов по имени у нас "низкоуровневый способ"

Это сообщение отредактировал(а) mes - 16.12.2010, 19:03