С++ framework library (Компонентная модель, прокси-объекты, подсчёт ссылок и т.п.)

[Zeus]

Чувствую, что велосипед выдумываю - наверное не мне первому это понадобилось: есть в природе что-то подобное?

[RasenHerz]

хм. не сталкивался с подобным. а можно по-подробней? что не совсем пойму зачем вам это.

[Zeus]

Разрабатывается система, функциональность которой будет наращиваться группой программистов, которые будут писать компоненты и внедрять их (в идеале) - прямо в работающую систему. Ну и "вытаскивать" их тоже будут из работающей системы.
Компоненты взаимодействуют между собой и чтобы не было "корок" и прочих segfault'ов нужно применять "слабое связывание" (как-то так оно называется), а это - посредники (proxy, mediator'ы).
Всё это видится мне как некоторый набор классов (proxy, implementation, interface, factory), от которых нужно наследоваться программистам, пишущим компоненты.

Добавление:
Подумывал я взять за основу какую-нибудь CORBA.
Но весь этот маршалинг/анмаршалинг, здоровая архитектура (даже небольшого ORB) - из пушки по воробьям для применения внутри одного процесса.

[v04bvs]

XPCOM

Это если хочется зрелое решение. Но оно на сильном старом С++-е и затачивалось под интероперабельность между языками.

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

[sergio]

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

Возможно +1. Но честно говоря, вопрос в стиле "подскажите что-нибудь про квантовую механику".
Обрисуйте задачи приложения, требования к нему, идею.
Корба - древняя игрушка, одна из первых что ли, критики на нее наверное сыщется довольно. Лично мне не попадалось на глаза, чтобы эта аббревиатура маячила в какой-то полезной области применения. Вроде в Гноме она там где-то... применялась. Или числилась.
У мелкомягких этих стандартов - распределенных и не - было пруд пруди. Ну плюс ЯваБинз - этой вещи тоже за десять лет возраст перевалил, но сдается мне шуму было куда больше чем толку. В давнишней книжке по JB был обзор этих конструкторов, про потуги M$ съязвили в стиле: "ОЛЕ 1 - вы кликаете в ворде по табличке, запускается иксель, и всех нахрен зависает; ОЛЕ 2 - достигнут большой прогресс: вы кликаете в ворде по табличке, у вас прямо в ворде табличка перерисовывается как в икселе, панели инструментов заменяются на икселевские, и вот уже после этого все нахрен зависает." :lol: Это типа намек в сторону стабильности и безотказности таких мегасистем. ))

А по вопросу - я так понимаю, что речь идет скорее не "С++ framework library" и т.д., а о системе неких плаг-инов, которые можно подгружать и выгружать и заменять соотв-но во время работы? Как модули ядра линукса, только в десять раз страшнее? ))

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

[Denjs]

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

ссылками сам QT занимается.. есть функция "число подключенных к сигналу объектов"...

и явная поддержка плагинов там есть , помимо простых библиотек...
но в библиотеку лучше упаковать "конструктор" который создает объект неизветсного нам класса (но "известнго предка") - и подключать его в систему как новый модуль к музыкальному центру.
и все можно динамически подключать/отключать/загружать/выгружать ляпота... ^_^

"я просто пруся от этого"(а)

[Zeus]

XPCOM

Спасибо, посмотрю.

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

Так я архитектуру и разрабатываю.
И, учитывая, что она будет иметь компонентную модель, компоненты будут взаимодействовать друг с другом и писать их будут разные разработчики - вот и пришёл к требованиям, изложенным в заголовке темы.
И подумалось, что не мне первому такое нужно - так может уже есть заготовки, от которых можно отталкиваться.
Неужто такое с нуля, каждый сам для себя пишет?

[Zeus]

А по вопросу - я так понимаю, что речь идет скорее не "С++ framework library" и т.д., а о системе неких плаг-инов, которые можно подгружать и выгружать и заменять соотв-но во время работы? Как модули ядра линукса, только в десять раз страшнее? ))

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

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

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

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

QT сам по себе монстр ещё тот.

ссылками сам QT занимается.. есть функция "число подключенных к сигналу объектов"...

Т.е. в QT программист имеет дело не с указателями на какой-либо объект, а с его прокси?
И объект можно удалить в процессе работы системы и ничего не упадёт?

[Portnov]

То, что вам нужно, если реализовать в достаточно общем виде (а вы хотите именно в общем виде, раз не указываете специфику проекта) - весьма сложная штука. А потому вариантов менее сложных (соответственно, менее громоздких) чем CORBA или XPCOM вы вряд ли найдете (скажем, есть еще RPC и даже XML-RPC - но уж не легче оно). Для более конкретных задач могут существовать более специализированные и потому более простые решения (укажете специфику вашей задачи - авось, знающие люди что-нибудь посоветуют).

[_Yuriy_]

Т.е. в QT программист имеет дело не с указателями на какой-либо объект, а с его прокси?
И объект можно удалить в процессе работы системы и ничего не упадёт?

Имеем некую абстрактную систему, которая открывает какие-то файлы, читает и выполняет некие действия интерактивно задаваемые пользователем. Вы изъяли из неё в ходе работы модуль чтения файлов. Упадёт система или сообщит "Извините ничего не могу читать, модуль изъят" - пользователю безразлично. Для него в любом случае система становится неработоспособной.
И второе, если новый модуль, встроенный в систему даст ошибку сколько наносекунд Вам понадобится на её устранение. А система уже остановилась.

[Zeus]

_Yuriy_
Честно говоря не очень понял о чём речь, а вопрос был простой: программёр одного из компонентов имея ссылку ("указатель") на объект взял и удалил его.
При этом ссылки на него имеют и другие компоненты, которые пытаются с ним работать.

Что в данном случае произойдёт с кодом, основанным на Qt? Segmentation fault? Или исключение вроде ObjectNotExists?

[_Yuriy_]

Честно говоря не очень понял о чём речь, а вопрос был простой: программёр одного из компонентов имея ссылку ("указатель") на объект взял и удалил его.

Вернемся к приведенному мной примеру. Ваш программист изъял из системы объект отвечающий за чтение файла.

При этом ссылки на него имеют и другие компоненты, которые пытаются с ним работать.
Что в данном случае произойдёт с кодом, основанным на Qt? Segmentation fault? Или исключение вроде ObjectNotExists?

В данном случае программа останется неработоспособной при любом исходе. Она остановится.

Вставьте в ВОРД объект из АВТОКАДА как ОЛЕ-объект. Вы можете редактировать его, управлять и т.д. А теперь деинсталируйте АВТОКАД со всеми патрохами. Ну не упал ВОРД, но внести изменения в сей ОЛЕ-объект Вы тоже не можете. И отредактировать документ не в состоянии. Система стала неработоспособной.

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

[Denjs]

_Yuriy_
Честно говоря не очень понял о чём речь, а вопрос был простой: программёр одного из компонентов имея ссылку ("указатель") на объект взял и удалил его.
При этом ссылки на него имеют и другие компоненты, которые пытаются с ним работать.

Что в данном случае произойдёт с кодом, основанным на Qt? Segmentation fault? Или исключение вроде ObjectNotExists?

смотря как связаны объекты. если использовать классический "callback-function" - то будет классический "Segmentation fault" :
Т.е. если вызывается "прямая ссылка" и функция объекта - например так: "myobj_handle->myfunction()" - то конечно при удалении myobj будет самый обычный "Segmentation fault".

Но QT предлагает совершенно иной механизм общения между объектами - сигнал и слот. При этом - если удален объект который принимает сигнал - "просто ничего не произойдет". Сигнал просто расворится "в нигде", и Segmentation fault-а не будет. А мы, находясь в живом состоянии, получим например возможность корректно обработать ошибку. Чего мы сделать не сможем в первом случае.

Серьезное отличие этих друх подходов также в том, что при "callback-function" объект-источник "должен знать" кого он вызывает - у него должна быть ссылка на объект.
А при "signal-slot" механизме объект-источник по большому счету "не знает" кому будет доставлен испущенный им сигнал - у него нет ссылки. При этом сигнал может быть доставлен любому числу объектов.

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

При этом, по большому счету мы можем "динамически" выключить светомузыкальную установку, и при этом вистема "не взорвется" и "не сгорит" .
Аналогично и с нормально-смпроектированной QT-программой. При уничтожении какого-либо объекта, или "отключении его" - систеема не вываливается в "segmentation fault" - просто "все подключенные к объекту сигналы" отключаются. И мы можем динамически выгрузить один объект, загрузить другой вместо старого и подключить к нему сигналы других объектов аналогично как оно было со старым. При этом всем мы работаем не на уровне "компоненты" или модуля, а с объектом определенного класса.

[v04bvs]

Но QT предлагает совершенно иной механизм общения между объектами - сигнал и слот. При этом - если удален объект который принимает сигнал - "просто ничего не произойдет". Сигнал просто расворится "в нигде", и Segmentation fault-а не будет. А мы, находясь в живом состоянии, получим например возможность корректно обработать ошибку. Чего мы сделать не сможем в первом случае.

Сразу скажу, что я предвижу. Если проект больше среднего, ротация программистов средняя или выше, а документация средняя или ниже, то через n лет никто не поймёт, как работает эта куча объектов, кто с кем переписывается и что куда посылается. Т.е. при желании всё инвестигируется, но вот этот подпишется на сигнал, тот подпишется туда, тот не будет знать про какую-то часть, неправильно поймёт доку, и напишет некорректно, причём сегодня оно работает а завтра падает вообще другой модуль (переписали DAO, упал 31 отчёт в полночь 29 февраля).

В принципе этого можно избежать, если все сигналы-слоты декларативно описывать во внешних файлах, тогда структуру системы можно будет разбирать относительно легко. Но в итоге это всё выльется в недоООП. Теоретически может вылиться в ерланг но вряд ли.

Но опять же, имхо, это всё не нужные усложнения. Нужен модуль, архитектим интерфейс, имплементим и готово. И не надо ничего никуда изымать, что за мода странная, стрелять из ружья в организм и смотреть какой орган умер. Садизм прямо какой-то.

просто "все подключенные к объекту сигналы" отключаются.

И теряются, к примеру, бизнес-данные. Деливер получил, послал ответ, что мол получил нормально, там приняли окей. Деливер послал дальше, а вот фиг, никто бедного деливера не слушает, у нас модуль ДАО обновляется. Такая модель очень редко подходит. Если данные посылаются, значит это кому-нибудь надо и игнорировать этот факт нельзя.

PS и не понимаю, чего вы все этого Segmentation Fault-а как чумы боитесь. Я его обожаю, SF это один из самых лучших исходов, для анализа ошибки всё есть, перезапустили программу сразу и дальше работаем ну а девелоперы пусть выясняют.

[Zeus]

PS и не понимаю, чего вы все этого Segmentation Fault-а как чумы боитесь. Я его обожаю, SF это один из самых лучших исходов, для анализа ошибки всё есть, перезапустили программу сразу и дальше работаем ну а девелоперы пусть выясняют.

Угу.

Ваш аппарат искусственного сердца совершил некорректную операцию и будет перезапущен через 3 минуты.
Послать отчёт об ошибке разработчикам? (Никакие секретные сведения такие как пароли отсылаться не будут!)

Или вот более жизненная ситуация: представляете себе роспуск вагонов на сортировочной горке?
Локомотив надвигает состав, отцепы уходят каждый на свой путь, стрелки туда-сюда снуют.
И вдруг - segfault.
Стрелки не переводятся, светофор замер на зелёном, отцепы расцепляются по предыдущей информации, замедлители тоже работают неадекватно.
Хорошо если ничего не повредят, но полдня сексуальных упражнений на разребание "завалов" - обеспечено.

Или, например, запуск ракеты...

P.S. Я уж не говорю о потере данных при segfault'е

[Denjs]

Если проект больше среднего, ротация программистов средняя или выше, а документация средняя или ниже, то через n лет никто не поймёт, как работает эта куча объектов, кто с кем переписывается и что куда посылается.

ага. а в случае если используется "callback-functions" то уже "то через n/3 лет никто не поймёт". а через n/2 лет приложение просто перестанет запускаться. т.к. будет впадать в постоянный "SF". все при лописанных вами условиях.

Т.е. при желании всё инвестигируется, но вот этот подпишется на сигнал, тот подпишется туда, тот не будет знать про какую-то часть, неправильно поймёт доку, и напишет некорректно, причём сегодня оно работает а завтра падает вообще другой модуль (переписали DAO, упал 31 отчёт в полночь 29 февраля).

для того что бы вы понимали "кто-куда подписывается" : объекты не "подписываются" - их "подключают". и делает это третья сторона - либо это основная программа в main() - создает объекты и "собирает из кучи объектов" рабочую конфигурацию, либо это выделенный объект-диспетчер, который единственный кто знает о всех объектах; он-же в принципе единственный, у кого есть/могут_быть ссылки на все объекты системы.

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

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

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

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

И теряются, к примеру, бизнес-данные. Деливер получил, послал ответ, что мол получил нормально, там приняли окей. Деливер послал дальше, а вот фиг, никто бедного деливера не слушает, у нас модуль ДАО обновляется. Такая модель очень редко подходит. Если данные посылаются, значит это кому-нибудь надо и игнорировать этот факт нельзя.

Ну так подключите сигнал куда-нибудь при сборке/запуске системы... а если вы знаете что объект может исчезнуть - например его могут выгрузить и от нас это не зависит - или проверяйте наличие на приемном конце объекта с заданным именем,(в отличии от "ссылок" в случае с "signal-slot" механизмом вы можете получить имена объектов подключенных к сигналу. А со ссылкой - как вы узнаете - существует на том конце объект или его уже давно нет?)
или обеспечивайте "гарантированную доставку" в особо важных случаях - кто вам мешает ввести "обратный сигнал" - подтверждение получения данных? или введите специальный сигнал - "всем ждать пока обновится модуль DAO"...
но поверьте мне - это как правило не требуется. только при общении с объектами, которые играют роль модулеё-плагинов, в отношении которых мы знаем что он может быть выгружен в любой момент.

а логика в стиле "значит это кому-нибудь надо и игнорировать этот факт нельзя" - это типа - "если мы вызываем мертвую сылку - значит это кому-нибудь нужно и игнорировать этот факт нельзя"... ( нельзя игнорировтаь? отлично -получитераcпишитесь "segmentation fault".)

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

QT предлагает одну из наилучших сред/концепций (имхо) для реализации одной из "лучших практик разработки ПО" - "компонентно-ориентированное проектирование".
Кроме того (возвращаясь к вопросу о документировании) - конйигурация объектов QT как правило статична и просто отлично визуализируется - диаграмма объектов и связей между ними - это как "карта королевства" - как "электрическая принципиальная схема" - и практически один-в-один отражается в программе. Вы очень легко, просто и четко отражаете структуру и взаимодействие вашей системы не пытаясь "придумать лишнеее" или рассказывать на словах.

[v04bvs]

Угу.

Ваш аппарат искусственного сердца совершил некорректную операцию и будет перезапущен через 3 минуты.
Послать отчёт об ошибке разработчикам? (Никакие секретные сведения такие как пароли отсылаться не будут!)

Или, например, запуск ракеты...

К системам, от которых напрямую зависит жизнь людей, предъявляются безумно жёсткие правила разработки, полагаю к вам это не относится. Скажу только, что на каждую строку кода приходится порой по странице документации, каждая строка просматривается разными ревьюерами до десятка раз, всё тестируется, причём абсолютно другой командой. Это другой мир, мы его рассматривать не будем. К сожалению и в нём случаются ошибки. В среднем одна на миллион строк, насколько я помню.

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

Программа-контроллёр в ту же миллисекунду перезапускает вашу программу, ещё десяток миллисекунд проходит для инициализации и восстановления после сбоя и

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

Хорошо если ничего не повредят, но полдня сексуальных упражнений на разребание "завалов" - обеспечено.

Сексуальные упражнения гарантированы тому, из за кого critical баг пролез в продакшн, это да

P.S. Я уж не говорю о потере данных при segfault'е

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

Не поймите меня превратно, я не призываю плюнуть на ошибки. Я не считаю ситуацию с segfault-ом в production-е допустимой. Это чья то очень серьёзная ошибка, в первую очередь тестировщиков, во вторую очередь тех, кто делал ревью кода.

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

А сегфолты у вас будут всегда, пока вы пишите не на безопасных языках. Всегда кто-нибудь когда-нибудь забудет проверить в функции входящий аргумент на null. И важно уметь не пропускать такие ошибки в продакшн. А не защищаться от абстрактного сегфолта при изъятии системы.

[v04bvs]

ага. а в случае если используется "callback-functions" то уже "то через n/3 лет никто не поймёт". а через n/2 лет приложение просто перестанет запускаться. т.к. будет впадать в постоянный "SF". все при лописанных вами условиях.

На личном опыте наблюдал всё с точностью до наоборот. Правда ту систему писали в основном на С, С++ там использовался не очень активно, но это не важно. Сейчас я пишу в основном на Java, NPE (аналог SF) не получаю. Что я делаю не так?

для того что бы вы понимали "кто-куда подписывается" : объекты не "подписываются" - их "подключают". и делает это третья сторона - либо это основная программа в main() - создает объекты и "собирает из кучи объектов" рабочую конфигурацию, либо это выделенный объект-диспетчер, который единственный кто знает о всех объектах; он-же в принципе единственный, у кого есть/могут_быть ссылки на все объекты системы.

Спасибо за ликбез, я копался внутрях Qt достаточно долго. Никто абстрактный подписывать не будет, подписывать будет тот, кто пишет модуль, не важно где. И да, вы понимаете, какой хаос будет среди хотя бы тысячи объектов, каждый из которых соединяется с парой-тройкой (довольно слабая связность) других?

Вообще вы утвеждаете странные вещи. Есть общепринятые практики проектирования, есть паттерны, GoF-а и другие. Система signal-slot это один из паттернов. Вы предлагаете им заменить всё остальное? Выражу сомнение в том, что это получится. Хотя если есть на практике программа на С++, целиком построенная на этой архитектуре и объёмом больше двухсот kloc-ов, возьму свои сомнения назад. Кстати я буквально неделю назад использовал концепцию пайпов, сильно похожую на слот-сигнал (там объекты принимали сообщения и посылали другие). На один из модулей это легко очень классно.

Ну так подключите сигнал куда-нибудь при сборке/запуске системы... а если вы знаете что объект может исчезнуть - например его могут выгрузить и от нас это не зависит - или проверяйте наличие на приемном конце объекта с заданным именем,(в отличии от "ссылок" в случае с "signal-slot" механизмом вы можете получить имена объектов подключенных к сигналу. А со ссылкой - как вы узнаете - существует на том конце объект или его уже давно нет?)

В С++ никто ничего выгружать не может. Можно сделать delete объекту. Для этих вещей давно выдумали умные указатели, которые и удалят всё сами, и занулятся если надо и т.д.

или обеспечивайте "гарантированную доставку" в особо важных случаях - кто вам мешает ввести "обратный сигнал" - подтверждение получения данных? или введите специальный сигнал - "всем ждать пока обновится модуль DAO"...

И получится очень тяжело программируемая асинхронная модель.

а логика в стиле "значит это кому-нибудь надо и игнорировать этот факт нельзя" - это типа - "если мы вызываем мертвую сылку - значит это кому-нибудь нужно и игнорировать этот факт нельзя"... ( нельзя игнорировтаь? отлично -получитераcпишитесь "segmentation fault".)

Получили, расписались, добавили в юнит-тесты, пофиксили, учли на будущее.

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

Говорю же, вы акторов имитировать пытаетесь. Делать это не на ерланге или скале — гиблое дело.

QT - это одна из наилучших сред для реализации одной из "лучших практик разработки ПО" - "компонентно-ориентированное проектирование".
Кроме того - это просто отлично визуализируется - диаграмма объектов и связей между ними - это как "карта королевства" - как "электрическая принципиальная схема" - и практически один-в-один отражается в программе. Вы можете очень четко отразить структуру и взаимодействие вашей системы не пытаясь придумать лишнеее или рассказать на словах.

лучшее, практики, компонентно-.., аналогии пропускаем мимо ушей
Про структуру — а UML для кого придумали?

[_Yuriy_]

PS и не понимаю, чего вы все этого Segmentation Fault-а как чумы боитесь. Я его обожаю, SF это один из самых лучших исходов, для анализа ошибки всё есть, перезапустили программу сразу и дальше работаем ну а девелоперы пусть выясняют.

Абсолютно точно. Причем можно и не перегружать саму программу, а поймать сигнал и построить обработчик исключительной ситуации.
Да речь шла о взлетающей ракете. Я представляю когда в момент её взлёта будет выгружен модуль контролирующий давление газов в камере сгорания.

[Denjs]

На личном опыте наблюдал всё с точностью до наоборот. Правда ту систему писали в основном на С, С++ там использовался не очень активно, но это не важно. Сейчас я пишу в основном на Java, NPE (аналог SF) не получаю. Что я делаю не так?

думаю, вы явно не выполняете одно из условий описанной вами ситуации :
"проект больше среднего, ротация программистов средняя или выше, а документация средняя или ниже".
Возможно, у вас ещё условия спокойные, ситуация меняется не быстро, и/или сложность проекта (при том что он большой) не высока.
и к тому-же как я понимаю в Java ссылки "несколько иные" чем в C++ ?
Чудес-ведь не бывает )

Вообще, это провокационный вопрос ) примерно так-же как "мы работаем чисто по ТЗ. Пишем ТЗ, потом кодируем, потом тестируем, потом внедряем. у нас все получается, зачем вообще нужна ваша итерационная технология и что мы делаем не так?"...

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

эээ... т.е. вы говорите, что подключать к себе сигналы будет сам объект или программист пишуший класс?
но извините, "накой" ему тогда сигналы/слоты если ему известны ссылки на объекты (а как подключиться если не иметь ссылок?) ?
не говоря уже просто о том что объекту должны быть известны типы окружающих его классов?
объект который взаимодейтсвует с внешним миром через сигналы не должен знать с кем он общается. ну.. скажем для начала что "это противоречит концепции сигнал/слотов". По большому счету, заранее совершенно не известно даже с каким классом мы будем взаимодействовать. и подключать объект в систему будет/может объект/програма о которых програмист пишущий класс может и не знать.

или мы говорим о совершенно разных вещах.

И да, вы понимаете, какой хаос будет среди хотя бы тысячи объектов, каждый из которых соединяется с парой-тройкой (довольно слабая связность) других?

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

Вообще вы утвеждаете странные вещи. Есть общепринятые практики проектирования, есть паттерны, GoF-а и другие. Система signal-slot это один из паттернов. Вы предлагаете им заменить всё остальное? Выражу сомнение в том, что это получится.

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

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

>> Хотя если есть на практике программа на С++, целиком построенная на этой архитектуре и объёмом больше двухсот kloc-ов,
>> возьму свои сомнения назад.
ну.. не знаю целиком и полностью-ли, "двести тысяч" или меньше строк, но та-же Opera на QT писана. тот же KDE "и иже с ними". Konqueror например.

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

>>>>а логика в стиле "значит это кому-нибудь надо и игнорировать этот факт нельзя" - это типа - "если мы вызываем мертвую сылку - значит
>>>> это кому-нибудь нужно и игнорировать этот факт нельзя"... ( нельзя игнорировтаь? отлично -получитераcпишитесь "segmentation
>>>>fault".)
>>Получили, расписались, добавили в юнит-тесты, пофиксили, учли на будущее.
да-да-да... конечно) "любой SF можно пофиксить"... когда он всплывет.
только согласитесь - это "латание дыр", "лечение симптомов" а не решение проблемы.
хотя и является "обшепринятым способом действия".

>>>> Тут надо проектировать систему по другому, а не думать "как-же плохо жить без прямых ссылок на объекты".
>> Говорю же, вы акторов имитировать пытаетесь. Делать это не на ерланге или скале — гиблое дело.
констатирую легкий оффтопик ).... давайте ещё 1С и "особенности" "програмирования" в 1С обсудим... (я вам ой как много могу рассказть. в том числе и о том (как это не смешно это звучит) о "способах реализации "компонентной модели" на встроенном языке 1С"... анекдот на пол-вечера...)
не об особенностях и структурах различных языков здесь речь а о методах решения ряда проблем в C++.

лучшее, практики, компонентно-.., аналогии пропускаем мимо ушей
Про структуру — а UML для кого придумали?

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

[Zeus]

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

Ошибочное полагание.

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

Программа-контроллёр в ту же миллисекунду перезапускает вашу программу, ещё десяток миллисекунд проходит для инициализации и восстановления после сбоя

Это речь идёт про перезапуск "Hello world"?

P.S. Я уж не говорю о потере данных при segfault'е

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

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

Не поймите меня превратно, я не призываю плюнуть на ошибки. Я не считаю ситуацию с segfault-ом в production-е допустимой. Это чья то очень серьёзная ошибка, в первую очередь тестировщиков, во вторую очередь тех, кто делал ревью кода.

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

И как программа при segfault'е будет восстанавливать "максимум информации" если она даже не в курсе что и где произошло?
А, например, исключение вместо segfault'а, позволит задействовать резервные ветки алгоритма: обработчики ошибок.

А сегфолты у вас будут всегда, пока вы пишите не на безопасных языках. Всегда кто-нибудь когда-нибудь забудет проверить в функции входящий аргумент на null. И важно уметь не пропускать такие ошибки в продакшн. А не защищаться от абстрактного сегфолта при изъятии системы.

Ошибки в программе есть всегда.
Почему бы не защититься от части из них - нормальным обнаружением во время выполнения, а не просто констатацией факта: "оба-на, а у вас тут программёры накосячили, а тестировщики прозевали!" ?

[GRS]

Нету такой библиотеки.
Про CORBA вообще забудьте - я работал с ней, это просто шляпа, полнейшая шляпа.

Лучше всего разработайте свой COM интерфейс. Проблема компонент удалили - а он используется там-то - решается с помощью умных указателей просто(подсчет ссылок). Ну и нужно смотреть boost, там много чего уже есть в качестве деталей для конструктора, главное суметь собрать этот конструктор правильно. Те же сигналы там тоже есть, как и в Qt, только более гибкие в применении.

[Zeus]

Про CORBA вообще забудьте - я работал с ней, это просто шляпа, полнейшая шляпа.

Мнда? А у нас в конторе во всех проектах CORBA используется.
Не сказал бы что "шляпа".
Есть свои "подводные камни", определённые недостатки, но я их скорее списал бы на конкретную ORB, а не на саму технологию.

Лучше всего разработайте свой COM интерфейс.

Под линухами? Или вообще - кроссплатформенно?

Проблема компонент удалили - а он используется там-то - решается с помощью умных указателей просто(подсчет ссылок). Ну и нужно смотреть boost, там много чего уже есть в качестве деталей для конструктора, главное суметь собрать этот конструктор правильно. Те же сигналы там тоже есть, как и в Qt, только более гибкие в применении.

Вот я примерно это и ищу: чтобы не самому собирать (как сделать одно, другое, третье - в принципе, я знаю), а чтобы всё это уже было сделано, оптимизировано, со всякими блокировками для многопоточной среды.

[GRS]

Zeus
Ну вот у меня на работе кросс-платформенная. Потворюсь про boost - там тоже все кроссплатформенно, и потоки и блокировки все там уже есть.

Про КОРБА - как оно выглядит в идеале, это хорошо. Но как только с ней работать начинаешь ... там не то что подводные камни - там пруд или озеро больше похоже из которого каменные глыбы торчат.