Здравствуйте, Тёмчик, Вы писали:

Тё>>>Ну смотри — удаление подписки. Как ты её собрался искать в контейнере? Какова стоимость?

S>>Зависит от обстоятельств. К которым мы перейдем ниже, там где фрагменты кода появятся.
Тё>Не юли.

Сперва прочитайте то, что вам пишут, потом уже отвечайте.

S>>Гораздо более серьезно, чем когда вы заявляете, что C++ не используется для рилтайма.
Тё>Я заявлял, что в ядре не место C++. Именно полноценному C++, ибо C-с-классами не является полноценным C++ в понимании стандарта C++.

Вы заявили следующее (http://rsdn.org/forum/job/7907304.1):

Автор: Тёмчик
Дата: 17.12.20

> Реалтаймовые системы не на плюсах делают.

Все ходы записаны.

Тё>И часто вас жизнь заставляет замерять оверхед на 10 элементах?

Нет. Но бывает.

S>>Ибо в C++ Node<T> хранил бы экземпляр T не по указателю, а по значению. А то у вас получится по две аллокации на объект в списке: первая для самого T, вторая для Node<T>.
Тё>Ты в курсе, что есть указатель на T, в данном случае? Может быть, это указатель на какой-то родительский объект или другую подписку, которого можно дёрнуть для оповещения об изменениях. Может быть, его и заполнять необязательно.

Тёмчик, давайте говорить о примере от B0FEE664. В котором под T можно подразумевать только std::pair<OnPress, void*>. Если вы хотите ввести в обсуждение еще что-то, то потрудитесь это описать, чтобы люди понимали, о чем речь.

Тё>Чувачелло, величина твоего невежества зашкаливает. Но я же привёл ссылку. Сложно прочитать?
Тё>

Тё>>>https://en.wikipedia.org/wiki/Sentinel_node#Linked_list_implementation

Т.е. вы для хранения списка подписок предлагаете хранить еще и специальный sentinel node?

Тё>Если пописчиков немного, то не стоит заморачиваться на алгоритмическую сложность.

Если вы еще не заметили, то речь идет не про алгоритмическую сложность, а о стоимости по памяти и времени исполнения. В случаях, когда подписчиков немного.

Тё>Кто управляет временем жизни callback?

Подписчик.

S>>Если достаточно всего лишь указателя на callback, то хранение для каждой подписки Subscription -- это дополнительная головная боль. Особенно в C++, где ничего не защищает от обращения к повисшим указателям.
Тё>У хорошего плюсника не бывает тухлых указателей. Вы к таким определённо не относитесь.

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

S>> Использовали экземпляр subscription для отписки один раз, а потом, по ошибке, сделали отписку повторно. И что будет в итоге?
Тё>В итоге будет nullptr и это правильно. Ибо кривые руки повторно-вызывальщиков отписок, релизов, диспозов и прочих делетов нужно испрямнять жёстко и без церемоний.

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

Кроме того, в C++ объекты по умолчанию копируются. Т.е. если есть:

class Subscription {
  Node * node_;
public:
  ...
  void unsubscribe() {
    if(node_) {
      ...
      node_ = nullptr;
    }
  }
};

То потребуется еще позаботится о том, чтобы объекты Subscription не копировались. Потому что зануление node_ в копии никак не скажется на исходном объекте. А до C++11 нормальных средств для этого в языке не было (а код от B0FEE664 явно написан для C++98).