История изменений

Объяснял уже,

Нет.

кидал уже цитаты из документации.

Цитаты были, но они вообще не показывали возможности получить от Qt реализацию publish-subscribe, о которой я вас просил. На просьбы описать механизм своими словами или хотя бы показать соответствующие фрагменты кода Qt вы, ожидаемо, не смогли отреагировать.

Но на минуточку, вы забыли с чего мы начинали обсуждение? Вообще-то с ненужности shared_ptr.

На минуточку, мы начали с того, что shared_ptr нужен там, где граф владения != графу порождения: www.linux.org.ru/add_comment.jsp?topic=14042354&replyto=14049165

И механизмы реализации publish-subscribe (если бы вы их понимали) как раз демонстрируют такую ситуацию. Сообщение порождает publisher-а, потом отдает владение операции publish, которая передает владение сообщением очередям subscriber-ов. Поскольку subscriber-ов N, то и очередей (в простейшем случае) N. Следовательно, будет N владельцев сообщением. И это только при начальном publish-е. Но, т.к. любой subscriber может сделать повторный publish этого же сообщение, то владельцев станет еще больше.

Я могу вам показать, как это решается без использования GC и подсчета ссылок. Но это неэффективная реализация. Поэтому применение shared_ptr в такой задаче — естественный вариант.

Вы утверждаете, что этого можно достичь без shared_ptr. Ok. Рассказывайте. Своими словами.

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

PS. Ну и да, меленькая мелочь: в нашем разговоре под shared_ptr понимается абстракция «умный указатель на базе подсчета ссылок». Реализаций этой абстракции может быть множество, вовсе необязательно, что это boost::shared_ptr или std::shared_ptr.

Объяснял уже,

Нет.

кидал уже цитаты из документации.

Цитаты были, но они вообще не показывали возможности получить от Qt реализацию publish-subscribe, о которой я вас просил. На просьбы описать механизм своими словами или хотя бы показать соответствующие фрагменты кода Qt вы, ожидаемо, не смогли отреагировать.

Но на минуточку, вы забыли с чего мы начинали обсуждение? Вообще-то с ненужности shared_ptr.

На минуточку, мы начали с того, что shared_ptr нужен там, где граф владения != графу порождения: www.linux.org.ru/add_comment.jsp?topic=14042354&replyto=14049165

И механизмы реализации publish-subscribe (если бы вы их понимали) как раз демонстрируют такую ситуацию. Сообщение порождает publisher-а, потом отдает владение операции publish, которая передает владение сообщением очередям subscriber-ов. Поскольку subscriber-ов N, то и очередей (в простейшем случае N). Следовательно, будет N владельцев сообщением. И это только при начальном publish-е. Но, т.к. любой subscriber может сделать повторный publish этого же сообщение, то владельцев станет еще больше.

Я могу вам показать, как это решается без использования GC и подсчета ссылок. Но это неэффективная реализация. Поэтому применение shared_ptr в такой задаче — естественный вариант.

Вы утверждаете, что этого можно достичь без shared_ptr. Ok. Рассказывайте. Своими словами.

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

PS. Ну и да, меленькая мелочь: в нашем разговоре под shared_ptr понимается абстракция «умный указатель на базе подсчета ссылок». Реализаций этой абстракции может быть множество, вовсе необязательно, что это boost::shared_ptr или std::shared_ptr.