SObjectizer 5.3.0
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [13.59.9.236] |
|
|
[!] Как относитесь к модерированию на этом форуме? Выскажите свое мнение здесь
Модераторы: Qraizer
| Страницы: (14) « Первая ... 2 3 [4] 5 6 ... 13 14 все ( Перейти к последнему сообщению ) |
SObjectizer 5.3.0
|
Сообщ.
#46
,
|
  |
Та вот как в последнем примере нормально. В принципе мне и примеры в первом посту вполне приемлемы с определённой точки зрения, но то я, я в буст-лямбдах на буст-функциях одно время зависал конкретно, а то korvin, ему сам Плюсовый синтаксис как таковой не очень родной. Вот и спросил.
Ну а почему нет? Мне как заядлому метапрограммеру писать подобное абсолютно не в лом. И это легко и сахарно решает вдруг (?) возникшую из-за особенностей архитектуры либы маленькую проблемку. Ваш диалог был бы более конструктивным, если б шёл не вокруг сферических философий, а вокруг конкретики. Пусть и синтетической. Пока вы бросаетесь из одной тему в другую в пределах одного поста и т. же о. строите ответы, от диспута будет мало проку. |
|
Сообщ.
#47
,
|
|
|
|
Цитата Qraizer @ Ваш диалог был бы более конструктивным, если б шёл не вокруг сферических философий, а вокруг конкретики. Пусть и синтетической. Пока вы бросаетесь из одной тему в другую в пределах одного поста и т. же о. строите ответы, от диспута будет мало проку. Ну я здесь в режиме ведомого, о чем спрашивают, о том и рассказываю. Пока наибольший интерес вызывали сопоставление с образцом и важность наследования от общей базы для сообщений. Об этом и пытался рассказать. Хотя, как по мне, так это далеко не первостепенные и важные для практики аспекты. Если будут вопросы о чем-то еще, постараюсь максимально полно ответить. |
|
Сообщ.
#48
,
|
|
|
|
Цитата eao197 @ Так об этом сразу было сказано: в плане сопоставления с образцом при разборе данных сообщения SObjectizer не идет ни в какое сравнение с libcppa.  Какое сопоставление с образцом? Я поставил минус за необходимость наследования.Я уже сказал - хочу не париться с передачей enum. Только не надо рассказывать, что мне это лишнее. Цитата eao197 @ Поскольку вот мы сначала работали без наследования. Из-за этого приходилось создавать дополнительные объекты со счетчиками ссылок. Не было возможностей просто так переадресовать тот же самый экземпляр сообщения в новый send или серию новых send-ов. И т.д. по мелочам. Отказались от всего этого, жизнь стала лучше Чем нельзя внутри реализации заворачивать сообщения в   template<class T> struct msg : message_t { T value; }; ? Цитата, на которую я изначально отвечал Цитата eao197 @ Мне не суть важно, насколько libcppa и SObjectizer конкурируют друг с другом. Намного важнее то, оставляют ли они C++ разработчиков в рамках C++ или же люди все-таки уходят в Erlang, Scala или еще куда-нибудь. Берут какую-нибудь Akka, а потом узкие места пытаются переписать на C или начинают бороться с GC. Тогда как можно было получить более качественный результат в C++. В моём понимании, вы утверждаете, что libcppa "уводит" людей от C++, и в этом качестве идёт противопоставление с SO, который, по вашим представлениям, более C++-каноничен. Ещё вы утверждаете, что такой "уход" даёт менее качественный результат. Если я понял правильно, то повторяю вопрос: по каким критериям вы оценили свой результат (SO) как более качественный? Цитата eao197 @ Попробую вот так объяснить. С начала 2000-х идет большой отток разработчиков из C++ в другие ниши (в основном в Java, частично в C#). В свое время это было оправдано, т.к. C++ развивался очень медленно. Да и память с гигагерцами никто не считал. Однако, время прошло, писать на C++ сейчас намного проще и безопаснее, а за счет некоторых возможностей языка (rvalue references, например) код получается еще быстрее и надежнее. Плюс на расход памяти и на мощность компьютеров вновь обращают внимание. Если лет 8-мь назад можно было встретить радостные упоминания, что RoR приложение отмасштабировано на 1000 серверов, то сейчас уже чаще заходит речь о другом: зачем платить за 1000 серверов с RoR приложением там, где можно обойтись 200 с Lift-приложением. Т.е. для возвращения достаточного интереса к использованию C++ вместо Java/C# сейчас больше условий, чем 10 лет назад. И, если этому поспособствуют библиотеки вроде libcppa, jss или SObjectizer, то это хорошо. Даже если 99% процентов C++ников будут пользоваться libcppa, а на долю jss и SO придется по 0.5%. На форуме есть целый раздел Holy wars, там обсуждают подобные вещи. С написанным я не согласен, да. Цитата eao197 @ Это не принципиальное ограничение обусловленное какими-то архитектурными особенностями. Если кому-то потребуется, то можно будет сделать и такой вариант Я бы настоятельно рекомендовал его сделать. Цитата bsivko @ MyNameIsIgor, какие вы используете (если используете) реализации модели акторов в боевых системах, в частности, на С++? Никаких. Цитата bsivko @ Пользователю прямого профита нет, но разработчик может при необходимости добавить что-то обобщающее. Как это сделано в QObject. В Qt пользователь может переопределять поведение в наследнике. В SO есть варианты использования, при которых пользователю необходимо переопределить поведение типов сообщений? Добавлено Цитата Qraizer @ Ну а почему нет? Мне как заядлому метапрограммеру писать подобное абсолютно не в лом Мне много что не в лом. Да и вообще, предлагается библиотека или список того, что не в лом? Цитата eao197 @ Ну я здесь в режиме ведомого Так ведите  Хотя бы в стиле "а ещё мы умеем вот так". |
|
Сообщ.
#49
,
|
|
|
|
Цитата MyNameIsIgor @ Цитата eao197 @ Так об этом сразу было сказано: в плане сопоставления с образцом при разборе данных сообщения SObjectizer не идет ни в какое сравнение с libcppa. Какое сопоставление с образцом? Я поставил минус за необходимость наследования.Значит в процессе разговора я не понял, за что именно минус. Цитата MyNameIsIgor @ Я уже сказал - хочу не париться с передачей enum. Только не надо рассказывать, что мне это лишнее. Ну, с учетом того, что в бою вы акторов в C++ не используете, не буду. Цитата MyNameIsIgor @ Цитата eao197 @ Поскольку вот мы сначала работали без наследования. Из-за этого приходилось создавать дополнительные объекты со счетчиками ссылок. Не было возможностей просто так переадресовать тот же самый экземпляр сообщения в новый send или серию новых send-ов. И т.д. по мелочам. Отказались от всего этого, жизнь стала лучше Чем нельзя внутри реализации заворачивать сообщения в template<class T> struct msg : message_t { T value; }; ? А пользователь что будет отсылать? Экземпляр объекта T? Как он попадет внутрь msg? Через copy, а еще лучше, move-конструктор? Тогда, если T -- это не элементарный тип, пользователю нужно будет писать этот конструктор для своего Т. Далее, когда агент получает экземпляр T и хочет именно его передать в серию новых send-ов, как это сделать? В libcppa для этого, как я понял, можно специальным методом получить ссылку на текущее обрабатываемое агентом сообщение. Но это создаст сложности, если мы захотим разрешить агенту работать одновременно на нескольких контекстах, на каждом из которых будет обрабатываться свое собственное сообщение. Т.е. все это решаемо, но с наследованием от общего предка все получается проще и понятнее. Далее, всегда есть вероятность, что с сообщением нужно будет ассоциировать какое-то новое поведение. Например, признак того, может ли это сообщение безопасно игнорироваться при переполнении очереди получателя. В случае с общим базовым типом может быть добавлен виртуальный метод, который будет переопределен в наследнике. Ну и т.д. Цитата MyNameIsIgor @ Цитата eao197 @ Мне не суть важно, насколько libcppa и SObjectizer конкурируют друг с другом. Намного важнее то, оставляют ли они C++ разработчиков в рамках C++ или же люди все-таки уходят в Erlang, Scala или еще куда-нибудь. Берут какую-нибудь Akka, а потом узкие места пытаются переписать на C или начинают бороться с GC. Тогда как можно было получить более качественный результат в C++. В моём понимании, вы утверждаете, что libcppa "уводит" людей от C++, и в это качестве идёт противопоставление с SO, который, по вашим представления, более C++-каноничен. Ещё вы утверждаете, что такой "уход" даёт менее качественный результат. Если я понял правильно, то повторяю вопрос: по каким критериям вы оценили свой результат (SO) как более качественный? Нет, вы не правильно понимаете. Я надеюсь, что библиотеки вроде libcppa, jss и SObjectizer будут задерживать разработчиков в C++. Кроме того, я думаю, что написание требовательных к производительности приложений на Java/Scala/C# в некоторых областях ставит перед разработчиками проблемы, которые легче решаются в C++. В частности, контроль за расходом памяти и отсутствием издержек GC, а так же более простой контроль за ресурсами посредством идеомы RAII (особенно это актуально для Java). В таких случаях использование C++ делает результат качественнее из-за уменьшения требований к памяти, более высокой скорости работы, более надежному поведению и лучшему контролю за ресурсами. Впрочем, поскольку вы считаете, что это тема для Holy War, то здесь ее развивать смысла нет. Цитата MyNameIsIgor @ Цитата eao197 @ Это не принципиальное ограничение обусловленное какими-то архитектурными особенностями. Если кому-то потребуется, то можно будет сделать и такой вариант Я бы настоятельно рекомендовал его сделать. Ок, спасибо, постараемся учесть в будущих версиях. Цитата MyNameIsIgor @ Цитата bsivko @ MyNameIsIgor, какие вы используете (если используете) реализации модели акторов в боевых системах, в частности, на С++? Никаких. Правильно я понимаю, что boost.fibers вы в продакшене так же не используете? Добавлено Цитата MyNameIsIgor @ Так ведите Э... Как бы в паре "ведущий"-"ведомый" партию ведет ведущий, а не ведомый. |
|
Сообщ.
#50
,
|
|
 |
Цитата MyNameIsIgor @ В Qt пользователь может переопределять поведение в наследнике. Если вы формулируете именно таким образом, то это противоречит LSP. Цитата MyNameIsIgor @ В SO есть варианты использования, при которых пользователю необходимо переопределить поведение типов сообщений? Если имеется ввиду все то множество методов в QObject, то оно вместе со всеми деревьями и прочими потрохами в настоящее время в SO отсутствует. В этом плане SO происходит только доставка. Если хочется прикрутить к сообщению какие-то свои методы, виртуальные и не совсем (изменяющие поведение в наследнике), то пожалуйста. |
|
Сообщ.
#51
,
|
 |
Обычно да, но длинные составные имена при таком количестве параметров... Да и :: со snake case плохо сочетается, ИМХО, т.к. выглядит "жирнее" и тем самым намекает на более сильную связь символов =/ |
|
Сообщ.
#52
,
|
|
|
|
Цитата eao197 @ В libcppa для этого, как я понял, можно специальным методом получить ссылку на текущее обрабатываемое агентом сообщение. Но это создаст сложности, если мы захотим разрешить агенту работать одновременно на нескольких контекстах, на каждом из которых будет обрабатываться свое собственное сообщение. А это создаст либо сложности сложности, либо оверхед и в вашем случае: Цитата eao197 @ Далее, всегда есть вероятность, что с сообщением нужно будет ассоциировать какое-то новое поведение. Например, признак того, может ли это сообщение безопасно игнорироваться при переполнении очереди получателя. В случае с общим базовым типом может быть добавлен виртуальный метод, который будет переопределен в наследнике. Ну и т.д. Сомнительный вариант... Цитата eao197 @ Правильно я понимаю, что boost.fibers вы в продакшене так же не используете? Нет, не использую. Цитата eao197 @ Как бы в паре "ведущий"-"ведомый" партию ведет ведущий, а не ведомый. У нас не танцы. А вы можете не только отвечать на вопросы. Цитата bsivko @ Если вы формулируете именно таким образом, то это противоречит LSP. С чего бы? Переопределять поведение можно и без нарушения конртакта QObject. |
|
Сообщ.
#53
,
|
|
|
|
Цитата MyNameIsIgor @ Цитата eao197 @ В libcppa для этого, как я понял, можно специальным методом получить ссылку на текущее обрабатываемое агентом сообщение. Но это создаст сложности, если мы захотим разрешить агенту работать одновременно на нескольких контекстах, на каждом из которых будет обрабатываться свое собственное сообщение. А это создаст либо сложности сложности, либо оверхед и в вашем случае: Речь не о том, представьте себе, что у вас идет поток сообщений, которые нужно отфильтровать по содержимому: чтобы отбросить, на что-то ответить сразу, что-то по каким-то жестко зафиксированным правилам отослать соответствующим получателям. Поток большой, если обрабатывать его на одном контексте (на одном ядре), то можно заткнуться. Лучше бы распараллелить эту обработку. Если обработка stateless, то делается это элементарно: одна очередь сообщений агента разбивается на несколько подочередей, каждая привязана к своему контексту, один и тот же обработчик агента вызывается на разных нитях (на разных ядрах) для разных экземпляров сообщений. Синхронизация здесь нужна только на уровне системы диспетчеризации сообщений. В агенте она не нужна. Так что, похоже, мы о разных ситуациях говорим. Цитата MyNameIsIgor @ Цитата eao197 @ Далее, всегда есть вероятность, что с сообщением нужно будет ассоциировать какое-то новое поведение. Например, признак того, может ли это сообщение безопасно игнорироваться при переполнении очереди получателя. В случае с общим базовым типом может быть добавлен виртуальный метод, который будет переопределен в наследнике. Ну и т.д. Сомнительный вариант... Тем не менее. Задача контроля перегрузки агентов нетривиальна и, скорее всего, требует совокупности разных подходов. Один из них вот такой. Для определенных классов сообщений (например, поток данных с часто опрашиваемых датчиков) вполне себе применимый: если из-за переполненной очереди мы не можем обработать текущий замер, то его можно проигнорировать, т.к. через секунду-другую все равно будет идти обновленное значение. Цитата MyNameIsIgor @ Цитата eao197 @ Как бы в паре "ведущий"-"ведомый" партию ведет ведущий, а не ведомый. У нас не танцы. А вы можете не только отвечать на вопросы. Так мы же в разных ситуациях. Я о SO знаю много. Для меня сложно даже представить, что в SO можно не знать. Поэтому режим, когда меня спрашивают, а я отвечаю, выглядит вполне логичным. |
|
Сообщ.
#54
,
|
|
|
|
Цитата MyNameIsIgor @ С чего бы? Переопределять поведение можно и без нарушения конртакта QObject. Можно. А можно и нарушением. Но узнаете об этом только тогда, когда произойдет что-то страшное. Наверное я что-то пропустил, но Qt разработан со сторогим соблюдением DbC? Где можно взглянуть на точные, верифицируемые, и формализованные условия класса QObject? |
|
Сообщ.
#55
,
|
|
|
|
Цитата eao197 @ Речь не о том Хз. Вот ваши слова Цитата eao197 @ Далее, когда агент получает экземпляр T и хочет именно его передать в серию новых send-ов, как это сделать? Жалеть передать именно его, а не его копию, можно лишь если мы хотим доступ к одному объекту из разных мест. Это требует синхронизации - на уровне библиотеки или обработчика. Если доступ из разных мест не нужен, то необходимости передавать именно этот же объект нету. Цитата eao197 @ Для определенных классов сообщений (например, поток данных с часто опрашиваемых датчиков) вполне себе применимый: если из-за переполненной очереди мы не можем обработать текущий замер, то его можно проигнорировать, т.к. через секунду-другую все равно будет идти обновленное значение. Мне не понятно, почему это определяет сообщение, а не тот, кто его обрабатывает - ему лучше знать, что важнее. Добавлено Цитата bsivko @ Можно. А можно и нарушением. Но узнаете об этом только тогда, когда произойдет что-то страшное. Ну, давайте запретим любое переопределение методов  Чтобы идея eao197 о виртуальном методе приоритета сообщения накрылась медным тазом.Только какое это всё имеет отношение к необходимости наследовать сообщения от общего предка, мне не понятно. Цитата bsivko @ Наверное я что-то пропустил Бывает... Цитата bsivko @ но Qt разработан со сторогим соблюдением DbC Проектирование по контракту - не наука, а набор медитативных практик. Полученных из опыта. Потому "строгих" критериев не будет. Цитата bsivko @ Где можно взглянуть на точные, верифицируемые, и формализованные условия класса QObject? Пока программирование не перейдёт хотя бы на зависимые типы, обо всем этом вы можете забыть и просто прочитать документацию. Помогает  |
|
Сообщ.
#56
,
|
|
|
|
Цитата MyNameIsIgor @ Цитата eao197 @ Далее, когда агент получает экземпляр T и хочет именно его передать в серию новых send-ов, как это сделать? Жалеть передать именно его, а не его копию, можно лишь если мы хотим доступ к одному объекту из разных мест. Это требует синхронизации - на уровне библиотеки или обработчика. Если доступ из разных мест не нужен, то необходимости передавать именно этот же объект нету. И в libcppa, и в SObjectizer один и тот же экземпляр сообщения передается всем получателям одновременно. Это просто значительным образом снижает издержки (особенно, когда речь идет не о int-ах или atom-ах). И задача корректного обращения с этим экземпляром решается с участием пользователя. В libcppa это производится за счет тактики copy-on-write (однако пользователь должен явно обозначать тип доступа к данным), в SObjectizer изменение значения экземпляра сообщения -- это undefined behavior: если пользователь захотел, пусть делает это на свой страх и риск. Поэтому все обработчики в SObjectizer получают сообщение-инцидент по константной ссылке. Передать именно тот самый объект-сообщение бывает необходимо, если сообщение "тяжелое", например, содержит текст, который нужно зашифровать и подписать электронной подписью. Если такое сообщение проходит через несколько стадий обработки (а каждая стадия -- это свой агент), то копирование даже десятка Кб при пересылке сообщения -- уже накладно. Цитата MyNameIsIgor @ Цитата eao197 @ Для определенных классов сообщений (например, поток данных с часто опрашиваемых датчиков) вполне себе применимый: если из-за переполненной очереди мы не можем обработать текущий замер, то его можно проигнорировать, т.к. через секунду-другую все равно будет идти обновленное значение. Мне не понятно, почему это определяет сообщение, а не тот, кто его обрабатывает - ему лучше знать, что важнее. А почему бы и нет? Сообщение с документом для шифрования и подписи -- это важная информация, оно может запретить себя игнорировать: нет ресурсов на обработку, тогда хотя бы сгенерируй отрицательный результат. А вот уведомление о том, что агент-шифровальщик жив-здоров, обработал за последнюю секунду 150 запросов и в очереди у него еще три свободных места -- априори не важная информация которую можно и потерять по дороге. Я же говорю, проблема нетривиальная, требует совокупности подходов. Где-то нужно отдать приоритет мнению агента. Где-то можно положиться на характер данных в сообщении. |
|
Сообщ.
#57
,
|
|
|
|
Цитата eao197 @ Передать именно тот самый объект-сообщение бывает необходимо, если сообщение "тяжелое" Не катит - можно бросить [умный] указатель. Да и сам текст мы будем хранить в куче, потому перемещение в данном случае рулит. Цитата eao197 @ Я же говорю, проблема нетривиальная, требует совокупности подходов. Где-то нужно отдать приоритет мнению агента. Где-то можно положиться на характер данных в сообщении. Даже если и так, требование наследование не является необходимым. |
|
Сообщ.
#58
,
|
|
|
|
Цитата MyNameIsIgor @ Пока программирование не перейдёт хотя бы на зависимые типы, обо всем этом вы можете забыть и просто прочитать документацию. Помогает Полагаю, что bsivko говорит о том, что вариативность поведения, заложенная в общей базе, изначально ограничена в жестких рамках дабы соблюдался LSP. Т.е. метод draw рисует, а метод queue_overload_reaction возвращает код для стандартной реакции на переполнение очереди. Это не изменение поведения, это как раз ожидаемое поведение наследника -- сделать то, что от него просят, но каким-то частным способом. А зависимые типы в продакшене вы уже используете? |
|
Сообщ.
#59
,
|
|
|
|
Цитата eao197 @ Это не изменение поведения, это как раз ожидаемое поведение наследника -- сделать то, что от него просят, но каким-то частным способом  Ну, давайте, покажите общепринятое определения понятия "изменение поведения"...Цитата eao197 @ А зависимые типы в продакшене вы уже используете? Т.е. программирование ещё на них не перешло, но я уже использую  |
|
Сообщ.
#60
,
|
|
|
|
Цитата MyNameIsIgor @ Цитата eao197 @ Передать именно тот самый объект-сообщение бывает необходимо, если сообщение "тяжелое" Не катит - можно бросить [умный] указатель. Да и сам текст мы будем хранить в куче, потому перемещение в данном случае рулит. Ну так message_t и есть тот самый умный указатель. Он и бросается, и перебрасывается при необходимости. Цитата MyNameIsIgor @ Цитата eao197 @ Я же говорю, проблема нетривиальная, требует совокупности подходов. Где-то нужно отдать приоритет мнению агента. Где-то можно положиться на характер данных в сообщении. Даже если и так, требование наследование не является необходимым. Заходим на очередной круг. Мы уже работали с сообщениями, где не нужно было наследоваться. По итогам решили ввести общий базовый тип, т.к. это и нам удобнее, и пользователя не напрягает. Необходимым это не было. Но жизнь облегчило. |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,0685 ] [ 18 queries used ] [ Generated: 5.05.24, 10:48 GMT ]