![]() |
|
Модераторы: Daevaorn |
![]()
|
|
| boostcoder |
|
||||
![]() pattern`щик ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 5458 Регистрация: 1.4.2010 Репутация: 49 Всего: 110 |
с одной стороны, радует компайл-тайм проверка на соответствие сигнатур/типов. с другой стороны, сложность в использовании... Вы сами-то как считаете, дай Вам такую библиотеку, Вы бы ее с удовольствием использовали? не примите как критику. у меня сложилось два варианта: 1. использовать так, как я предложил. 2. писать кодогенератор. Добавлено @ 21:55
это хороший вопрос... что имеется ввиду? Добавлено @ 21:59 наверное это самый оптимальный вариант. ибо можно разработать синтаксис, простой и понятный пользователю, и многое возложить на кодогенератор(проверку соответствия типов/сигнатур, объединение, групировку, условный инвок, и т.д..). Это сообщение отредактировал(а) boostcoder - 25.3.2011, 22:00 |
||||
|
|||||
| mes |
|
||||||||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
То в ту сторону ее я тяну, как раз и соответствует моим пожеланиям..
без типо-безопасности я не вижу смысла в этой затеи.. слишком высок риск пропуска, и как следствие долгие часы отладки.. а вот насчет сложности, я не вижу никакой излишней.. и в частности того, чего нельзя было бы замакросить в дальнейшем для большего удобства.. если речь идет о лишнем описании сигналов (stc) , то фактически оно не является лишним.. так и так нужно было написать две функции, одну отправляющую сигнал, другую принимающую.. Во вторых stc является библиотекой, по отношению к коду приемки.. т.е. соблюдается соотношение один к несколько.. если речь о том , что надо описывать msg_traits.. то это сделано для случая когда нужно взаимодействие по вполне определенному протоколу.. что позволяет взаимодействию на разных языках.. Добавлено @ 22:35 чтоб писать кодогенератор, в любом случае должна быть конструкционная база... Добавлено @ 22:46 передать содержимое std::tuple в std::function.. Добавлено @ 22:49 еще насчет сложности.. если мы будем рассматривать общий случай, когда мы можем использовать дефолтные сообщение и ее свойства, то пользовательский код по определению реализации будет выглядеть так
что можно еще принципиально упростить в этом примере, я не вижу.. Это сообщение отредактировал(а) mes - 25.3.2011, 23:01 |
||||||||
|
|||||||||
| boostcoder |
|
|||
![]() pattern`щик ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 5458 Регистрация: 1.4.2010 Репутация: 49 Всего: 110 |
еще один момент, который в моем случае препятствует использованию вашего способа в моем проекте - это наследование от шаблона. дело в том, что в моем проекте, GUI уже написан. и написан он с использованием Qt. а Qt, как известно, имеет один неприятный нюанс - запрещено наследоваться от шаблонов. т.е. класс, который предоставляет сигналы и слоты, и соответствует концепту QObject - не может наследовать шаблонный класс. это ограничение навязывает их метагенератор(moс). т.е. в вашем случае, не получится напрямую отразить Qt`ешный класс на протокол... |
|||
|
||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
наследование совершенно не обязательно.. можно проксировать, а можно просто замакросить определение оператора() и вспомагателей.. Добавлено через 2 минуты и 8 секунд добавил инвокинг, и условную конвертацию (аналог сериализации) (пока в грязном виде) http://liveworkspace.org/code/85c953df7972...a1a795ea3091739 |
|||
|
||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
вот убрал наследование, а также добавил условное namespace dyco, в который поместил ступень описания протокола...
http://liveworkspace.org/code/95331fe1e1a9...fc253af093dee5c итого имеем три ступени : :: dy - общие элементы обеспечения взаимодействия :: dyco - описание конкретного протокола :: - клиентская приложение Это сообщение отредактировал(а) mes - 26.3.2011, 23:42 |
|||
|
||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
как уже говорилось, есть два основных действия над сообщением
1. передача (предположительно посредством каналов) 2. исполнение (как вызов функции свободной или члена) со вторым пунктом более-мене разобрались, переходим к разбору первого.. вот с наброском канала : http://liveworkspace.org/code/3d24f56e14ba...4b30929fcaf7079 |
|||
|
||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
набросал условный пример взаимодействия двух объектов..
http://liveworkspace.org/code/c4deb105acd2...586886857f0fa11 связывать можно как напрямую - для простейших случаев так и через каналы, при составлении сетей, в том числе и удаленного взаимодействия.. Это сообщение отредактировал(а) mes - 27.3.2011, 14:30 |
|||
|
||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
вернем тему к жизни
http://liveworkspace.org/code/4616ac827fa4...62f02cf81ec1509 так выглядит условный калькулятор :
|
|||
|
||||
| boostcoder |
|
||||
![]() pattern`щик ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 5458 Регистрация: 1.4.2010 Репутация: 49 Всего: 110 |
по крайней мере для меня, задача считается решенной, ибо решение успешно используется уже в нескольких проектах. в Вашем примере все как-то слишком сложно.
пример:
необходимо дополнить этот код так:
тут, дистрибьютор знает о всех объектах регистраторах. время жизни объекта регистратора определяет время валидности регистрации. как правило, регистраторы создаются как объекты-члены регистрируемого класса. |
||||
|
|||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
тут нет гарантии типо-безопасности... без нее задача естественно легче решаема и в текущей ситуации мне неинтересна.. |
|||
|
||||
| boostcoder |
|
|||
![]() pattern`щик ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 5458 Регистрация: 1.4.2010 Репутация: 49 Всего: 110 |
гарантии я получаю путем использования общих интерфейсов на обоих сторонах.
другого, внятного и удобного способа получить эти гарантии - нет. можно делать так как вы предложили. но то кол-во кода которое придется написать руками, еще больше создает вероятность ошибиться. имхо. |
|||
|
||||
| mes |
|
||||||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
для вас интерфейс это концевые обьекты реализующие функциональность, для меня простое согласование имен с их типами, а именно :
что грубо соответсвует :
в "классическом"стиле букв еще больше Это сообщение отредактировал(а) mes - 11.8.2012, 10:37 |
||||||
|
|||||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
цледующий шаг,подключил сигналы :
http://liveworkspace.org/code/b69e0a200b84...ef4474cabcbcb37 теперь надо спрятать демух, чтоб обьект работал с воднымивыходным каналом.. |
|||
|
||||
| boostcoder |
|
|||
![]() pattern`щик ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 5458 Регистрация: 1.4.2010 Репутация: 49 Всего: 110 |
но зато только одна точка задающая соответствия. непонимаю цели. т.е. в чем профит? |
|||
|
||||
| mes |
|
|||
|
любитель ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 144 Всего: 250 |
одна при декларации интерфейса и вторая при определении наследника.. Добавлено @ 15:56 не понял... я предполагаю два demuxa : один сигнальный, другой функциональный.. если не нравится - можно самому переопределить рецептор.. пример обработки сообщения без его конкретизации - логгер - ему demux совсем ненужен.. Добавлено @ 15:57 вопрос, почему оставляю доступ к сигналу ? чтоб не прятать привычный интерфейс.. Добавлено @ 16:01 концепция : есть канал, на вход скидываются сообщения, на выходе получаются и если нужно демультипликсируется.. все что снаружи от этой области в компентенции юзера.. канал можно будет замыкать на другой канал или на сокет, для трансляции сообщений за пределы приложения.. также можно устанавливать фильтры для разветвления потока сообщений... Это сообщение отредактировал(а) mes - 11.8.2012, 16:03 |
|||
|
||||
![]()
|
| Правила форума "С++:Общие вопросы" | |
|
|
Добро пожаловать!
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Earnest Daevaorn |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | C/C++: Общие вопросы | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |