Igors, это ты? :)

[ViTech]

И все это поместить в MainWindow и композиция будет завершенной.

А в центре вишенку - вьюху дерева с 300 методами, которая синглтон.

[Old]

А в центре вишенку - вьюху дерева с 300 методами, которая синглтон.

Ну это же идеальный MainWindow.

[m_ax]

А в центре вишенку - вьюху дерева с 300 методами, которая синглтон.

Ну это же идеальный MainWindow.

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

[Igors]

Эти клиенты/ссылающиеся одного типа (или имеют общий базовый тип)? Или могут быть несвязанными между собой типами и ссылаться на один объект?

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

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

Меня тут другой вопрос вопрос беспокоит: С какого кхм-кхм.. объекту знать о всех клиентах?

Ну объявить неудобную задачу неграмотной хочется всегда   Но налицо по меньшей мере 3 случая когда это необходимо

1) Объект удаляется - обнулить ссылки на него
2) Сохранить данные undo перед удалением объекта
3) "Оповещение" что данные ссылки изменились

Конечно можно решить "1" напр вумным указателем, а остальные 2 напр сигналами, но... хорошо ли это? Ведь очевидно что во всех случаях нужен доступ к одним и тем же данным (ссылающиеся). Или может это нарушает какие-то прынцыпы, мол, выходит "все о всех знают". Но ведь мы же сами устанавливаем "отношение" между объектами, поэтому появление новых зависимостей - то что и должны были получить. И с какой стати эти зависимости должны быть "одно направленными"? Чем это "отношение" хуже (или лучше) того же парент-чайлд?

А в центре вишенку - вьюху дерева с 300 методами, которая синглтон.

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

[Old]

никаких идей/мыслей у человека нет, а поиск в std-багаже ничего не дал.

А какие идеи/мысли вы ждете? Вы все уже ответили в своем сообщение выше: нужно использовать shared_ptr/wake_ptr, которые вы использовать не хотите, придумывая всякие отговорки.
А запердролить специальный менеджер, познакомить всех со всеми - вот это решение по вам.
Но обдумывать и серьезно обсуждать этот трешак уже никто не хочет, не смотря на то знает человек std или нет.

[ViTech]

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

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

Возможно, следует обратить внимание на SOLID.

А в центре вишенку - вьюху дерева с 300 методами, которая синглтон.

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

Это Вы правильно подметили: от человека, который не догадается сделать View синглтоном, не стоит ожидать мыслей высокого полёта и ослепительных идей. Даже если какие и появятся, всё одно будут выглядеть бледно на фоне сего .

[Igors]

Это Вы правильно подметили: от человека, который не догадается сделать View синглтоном, не стоит ожидать мыслей высокого полёта и ослепительных идей. Даже если какие и появятся, всё одно будут выглядеть бледно на фоне сего .

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

Но увы, такие простенькие соображения почему-то не приходят в std::головы Им обязательно надо что-то намутить с очередным вумным указателем, обязательно использовать std::вызовы, хотя очевидно что здесь они никак не помогут. Мнение что, якобы, "std - основа" - совершенно ложно и приносит немало вреда. Это всего лишь либа предоставляющая некоторые возможности (довольно ограниченные) - и не более того. Программиста не должно смущать что в std не находится ничего подходящего - там, правду сказать, вообще мало чего хорошего 

[ViTech]

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

Ну так и реализуйте, в чём проблема . Контейнеры, кстати, какие будете использовать?

[Old]

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

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

Но увы, такие простенькие соображения почему-то не приходят в std::головы

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

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

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

Мнение что, якобы, "std - основа" - совершенно ложно и приносит немало вреда.

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

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

Вы нашли там vector, уже хорошо.

[Igors]

Контейнеры, кстати, какие будете использовать?

Может и std, незачем здесь завязываться только на Qt

Ну так и реализуйте, в чём проблема .

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

Думается мешает сама "идиома" умных указателей (если я правильно употребляю этот термин). Мол "все как с обычным/голым указателем только.. (или плюс еще..)". Это слишком жиденько/маломощно, если мы хотим управлять зависимостями - то по меньшей мере их надо хранить, отделаться счетчиками точно не удастся. Да и вообще называть вещи своими именами - ну граф так граф (зависимостей), это нормально. А вумные указатели лучше бы реализовывали упр-е этим графом.

Да, ну и конечно это совсем не ново - нечто подобное наблюдаю еще с 90x, последний раз в GStreamer с которым познакомился в этом году. Когда-то обсуждали здесь "а как же (де)сериализовать такой член-указатель" - и по меньшей мере 3 человека рассказали о своих великах (весьма капитальных). Так что делать это приходится если и не всем то многим.

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

[Авварон]

Думается мешает сама "идиома" умных указателей (если я правильно употребляю этот термин). Мол "все как с обычным/голым указателем только.. (или плюс еще..)". Это слишком жиденько/маломощно, если мы хотим управлять зависимостями - то по меньшей мере их надо хранить, отделаться счетчиками точно не удастся. Да и вообще называть вещи своими именами - ну граф так граф (зависимостей), это нормально. А вумные указатели лучше бы реализовывали упр-е этим графом.

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

[ViTech]

А Вы, стало быть, в кусты

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

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

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

Да, это место(а) сделано коряво, но работает - и слава богу. Проблемы, стало быть, нет - ну и хорошо что нет.

Аминь!

[Old]

и так уже юзвери недовольны моим бесконечным рефакторингом.

И их можно понять.
С такими рефакторингами, программа может вообще перестать работать.

[Igors]

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

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

[Old]

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

А из этого ничего выжимать и не надо. Даже, при вновь всплывших, операциях сериализации/десериализации.
Есть слабый указатель, если он ссылается на валидный объект - сериализуем id этого объекта, что бы при десериализации можно было восстановить связь, если ссылается на не валидный - сериализуем null-id, и при десериализации связь не восстанавливаем. id должен позволять однозначно находить объект при десериализации.