История изменений
Исправление eao197, (текущая версия) :
Объяснял уже,
Нет.
кидал уже цитаты из документации.
Цитаты были, но они вообще не показывали возможности получить от 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.
Исходная версия eao197, :
Объяснял уже,
Нет.
кидал уже цитаты из документации.
Цитаты были, но они вообще не показывали возможности получить от 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.