SObjectizer 5.3.0

Цитата eao197 @ 02.07.14, 13:30

Ну так message_t и есть тот самый умный указатель. Он и бросается, и перебрасывается при необходимости.

И привносит оверхед счётчика.

Цитата eao197 @ 02.07.14, 13:30

Заходим на очередной круг

А как иначе?

Цитата MyNameIsIgor @ 02.07.14, 13:02

Ну, давайте запретим любое переопределение методов

Вы сейчас применяете дамский аргумент. Прошу вас заниматься софистикой в другом месте.

Цитата MyNameIsIgor @ 02.07.14, 13:02

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

Прочитайте пожалуйста хотя бы определение.

Формализованность и верифицируемость - это необходимые условия для DbC.

Поэтому, я настойчиво рекомендую вам в дальнейшем не пользоваться понятиями, смысл которых вы не знаете. Даже если в ваш лексикон что-то перепало с барского стола DbC. Все эти слова сотрясают воздух, но не собеседника.

Цитата MyNameIsIgor @ 02.07.14, 13:28

Т.е. программирование ещё на них не перешло, но я уже использую

Ну кто же знает. Некоторые люди себе на жизнь Erlang-ом и Haskell-ем зарабатывали когда об этих языках широкая общественность еще и не знала.
Может и вы на какой-нибудь Adga2 или еще чем-нибудь уже во всю коммерческие проекты делаете.

Просто забавно получается. Ни libcppa, ни boost.fibers, ни зависимые типы вы реально не используете, но говорите, что на них можно. Это несколько настораживает

Добавлено 02.07.14, 13:36

Цитата MyNameIsIgor @ 02.07.14, 13:31

И привносит оверхед счётчика.

Конечно. Поскольку в C++ GC нет, то приходится работать со счетчиками ссылок. В том же libcppa это так же используется. Просто там пользователь об этом счетчике не сном, ни духом. SO про счетчик пользователь так же не сильно думает, но у нас он выставлен наружу через message_t.

Цитата eao197 @ 02.07.14, 13:30

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

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

У-тю-тю-тю, ещё один якобы умный

Цитата bsivko @ 02.07.14, 13:32

Прочитайте пожалуйста хотя бы определение.

Формализованность и верифицируемость - это необходимые условия для DbC.

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

Цитата bsivko @ 02.07.14, 13:32

Поэтому, я настойчиво рекомендую

Если когда-нибудь ваше мнение станет мне интересно, я дам вам знать. До тех пор попусту не возбуждайтесь.

Цитата eao197 @ 02.07.14, 13:34

Просто забавно получается. Ни libcppa, ни boost.fibers, ни зависимые типы вы реально не используете, но говорите, что на них можно. Это несколько настораживает

Штирлиц насторожился © Если вас что-то не устраивает в разговоре, это исключительно ваши проблемы, я вас не держу.

Цитата eao197 @ 02.07.14, 13:34

Конечно

Конечно это минус в том случае, если копирование/перемещение сообщения дешевле счётчика.

Цитата D_KEY @ 02.07.14, 13:38

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

Дело довольно давнее, с моим склерозом всего уже и не вспомнить.
Точно помню, что в 2002, когда создавался SO-4, я специально закладывал возможность, чтобы любую структуру можно было отослать в виде сообщения. Но, т.к. рядом с ней нужно было иметь еще и некоторую метаинформацию, в частности, счетчик ссылок, то рядом с созданным пользователем объектом-сообщением еще и создавался мелкий объект-дескриптор. Это серьезные накладные расходы, т.к. любой дополнительный new/delete в многопоточном приложении -- это ощутимо, даже если связать с объектом-дескриптором отдельный эффективных аллокатор. Кроме того, выяснилось, что за все время использования SO-4 (а это уже 12 лет) ни разу не была использована возможность отослать в виде сообщения какую-то чужую структуру. Всегда это были специально подготовленные в качестве сообщения структуры данных.

Поэтому, занимаясь SO-5, хотелось объединить и объект-сообщение, и нужную для него метаинформацию в одном блоке памяти. Общий базовый тип здесь выглядел наиболее простым и логичным вариантом. Кроме того, общий базовый класс позволил задействовать dynamic_cast для обеспечения большей безопасности операций. Ну и были идеи по добавлению в общего предка виртуальных методов для разных целей -- от валидации объекта сообщения (в SO-4 была такая фича, перед обработкой сообщения запускался его валидатор), до реакции на какие-то события (вроде переполнения очереди или игнорирования сообщения из-за того, что агент не смог его обработать). Но пока это все осталось в фантазиях. Хотя сама возможность сделать что-то подобное греет

Не могу сказать, как на это дело повлияло то, что SO-5 разрабатывался в 2010, официально C++11 не был принят, и далеко не все компиляторы имели поддержку таких вещей, как rvalue references и move-semantic. Наверное так же повлияло, т.к. мы делали инструмент, который нужно было запускать в дело максимально быстро, а не ждать, когда появятся компиляторы с достаточным уровнем поддержки C++11.

Я еще не смотрел вашу библиотеку, но разве при наличии даже требования к наследованию, сложно расширить интерфейс для обработки произвольных типов, которые бы уже внутри заворачивались в объект с нужными требованиями?

Цитата D_KEY @ 02.07.14, 14:03

Я еще не смотрел вашу библиотеку, но разве при наличии даже требования к наследованию, сложно расширить интерфейс для обработки произвольных типов, которые бы уже внутри заворачивались в объект с нужными требованиями?

Не уверен, что понимаю, о чем именно идет речь. Полагаю, об одном из следующих вариантов:
Есть внутренний тип message_t с нужным набором методов. Для конкретного пользовательского типа неявно строится наследник-обертка:

template< class USER_MESSAGE >
struct concrete_msg_t : public message_t {
  USER_MESSAGE m_data;
  ... // Куча виртульных методов.
};

Далее, для получения concrete_msg_t<T> с дополнительными свойствами, например, с реакцией на переполнение очереди, поступаем одним из следующих способов. Способ 1:

// Пользователь в своем типе определяет метод queue_overload_reaction():
class my_message {
  ...
  reaction queue_overload_reaction() const { ... }
};
// Наличие этого метода автоматически определяется при обращении к deliver_message:
mbox->deliver_message( my_message(...) );

Способ 2:

// При обращении к deliver_message передаются дополнительные свойства:
mbox->deliver_message( my_message(...) ).with_queue_overload_reaction(...);

Правильно я вас понял?

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

Цитата MyNameIsIgor @ 02.07.14, 13:42

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

Т.е. цитаты из вики вам недостаточно?

Нужно ли вам объяснять, являются ли assert'ы формальными и/или верифицируемыми?

На Eiffel никогда не верифицировал программ. И, вообще-то, DbC != Eiffel. И даже, утверждение (точнее, предикат) Eiffel => DbC не является истинным (стрелка тут импликация).

И это все выходит за рамки текущей темы. Контрактов нет ни в Qt, ни в SO, и они редко где используются простыми программистами С++.

Цитата MyNameIsIgor @ 02.07.14, 13:42

Если когда-нибудь ваше мнение станет мне интересно, я дам вам знать. До тех пор попусту не возбуждайтесь.

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

Сообщение отредактировано: bsivko - 02.07.14, 14:19

Цитата MyNameIsIgor @ 02.07.14, 13:42

Штирлиц насторожился © Если вас что-то не устраивает в разговоре, это исключительно ваши проблемы, я вас не держу.

Да как же я уйду, где ж еще получится пообсуждать практические проблемы с теоретиком

Не обижайтесь, пожалуйста, это шутка.

Цитата bsivko @ 02.07.14, 14:17

Т.е. цитаты из вики вам недостаточно?

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

Цитата bsivko @ 02.07.14, 14:17

Нужно ли вам объяснять, являются ли assert'ы формальными и/или верифицируемыми?

Да, нужно. Потому что ни assert'ы, ни котракты (в смысле языковых возможностей) не являются формальной верификацией. Они ничего не доказывают, а лишь говорят нам, что в данном случае они не сработали.
Или попробую объяснить по-другому: контракты и утверждения выполняют ту же работу, которую можно выполнить с помощью модульного тестирования. Но как справедливо говорит ваша любимая вика

Цитата

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

Цитата eao197 @ 02.07.14, 14:17

Да как же я уйду

Вы правда хотите, чтобы я сказал?

Цитата MyNameIsIgor @ 02.07.14, 11:48

Мне много что не в лом. Да и вообще, предлагается библиотека или список того, что не в лом?

Ну так кому-то вон не в лом и на Билдере писать в объектной модели Дельфей. Всё относительно, а уж такая право мелочь, как мета-переходник от значения к типу, не достойна в качестве минуса привлекать пристальное внимание, коли большая часть остального в либе устраивает.

Добавлено 02.07.14, 14:53

Цитата eao197 @ 02.07.14, 12:08

Т.е. все это решаемо, но с наследованием от общего предка все получается проще и понятнее.

Кстати вот. А не смотрели в сторону стратегий поведения? Они могут относительно дёшево избавить от общего предка, заменив полиморфизм на статический.

Цитата Qraizer @ 02.07.14, 14:50

Всё относительно, а уж такая право мелочь, как мета-переходник от значения к типу, не достойна в качестве минуса привлекать пристальное внимание, коли большая часть остального в либе устраивает

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

Цитата Qraizer @ 02.07.14, 14:50

Цитата eao197 @ Сегодня, 16:08
Т.е. все это решаемо, но с наследованием от общего предка все получается проще и понятнее.
Кстати вот. А не смотрели в сторону стратегий поведения? Они могут относительно дёшево избавить от общего предка, заменив полиморфизм на статический.

Не уверен, что понимаю о чем идет речь. При диспетчеризации сообщений именно что нужен обычный полиморфизм -- есть очередь объектов типа message_t, все это находится где-то глубоко внутри отдельной dll/so-шки, пользовательский код компилируется отдельно и потом уже линкуется с библиотекой SO-5. Как бы мы в пользовательском коде не игрались с шаблонами, стратегиями и статическим полиморфизмом, все равно это нужно будет как-то свести к поведению типа message_t.

Не, понятно, что гетерогенные контейнеры на статике собирать категорически неудобно. Хоть и можно. Но я и не знаю внутренней кухни SO, я просто отталкиваюсь от вашего же заявления, что единый базовый класс был необязателен.
Конкретно в том, что я имел в виду, подразумевалось, что различные те или иные кастомные характеристики можно было бы возложить на компайл-тайм стратегии вместо ран-тайм полиморфизма. В конце концов я представляю агентов как сущности с характеристиками, заданными при их проектировании, и им совершенно незачем менять их у себя в ран-тайм.