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

Тё>Визитор, внезапно, это колбек.

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

L>>В предложенной тобой схеме каждый Subscription должен владеть списком подписок.
Тё>Каждая подписка должна владеть списком подписок? Ты сам-то понял, что написал?

Я-то прекрасно понял. Потому что решал подобные задачи на практике. А вот ты упорно не понимаешь проблему.

Тё>Кто чем владеет- не обсуждалось.

Эта тема поднималась, только ты с нее соскочил на наезды на детали реализации. Исходная схема, когда единой точкой входа и для подписок и для отписок являлся менеджер подписок, тебя не устроила. Ты вместо нее предложил схему, где отпиской управляет отдельный объект Subscription, и про менеджер после подписки можно забыть. Вот и получил необходимость поддерживать жизнь списка подписок через Subscription'ы, а не только через менеджер.

Тё>Можно сделать, что если Observable удалён раньше, чем последняя подписка- отцепить его sentinel от циклического списка и оставить неотписавшихся висеть в памяти. Когда неотписавшиеся отпишутся, они себя очистят.

Ну, то есть, мы возвращаемся к тому, что при отписке никакого сентинела может уже не быть, и это нужно учитывать. И нафига он тогда вообще нужен? Это не говоря о том, что в реальной жизни помимо списка подписок и сентинела почти наверняка нужны будут какие-то вспомогательные флаги/мьютексы/т.п.

Тё>Ещё один безграмотный. Речь про shared_ptr без разделяемого счётчика на куче.

Сам ты безграмотный. Ты можешь, наверное, написать аллокатор, который будет хранить счетчик в статической памяти, например. Или написать свой shared_ptr, который будет его хранить хрен знает где (в TLS, например). Только, это никому не нужно, ибо через make_shared счетчик спокойно аллоцируется в той же памяти, что и объект, которым владеет shared_ptr. А в случае интрузивных поинтеров счетчик просто является частью объекта.

Тё>Перечисление граблей- это по-твоему понимание C++? Ну так тогда ты на 100% попадаешь под моё описание C++ ка.

Если тебе всюду мерещатся грабли, то с этим к психиатру надо бы.

Тё>Если тебе использование C++ разжижило мозг, то это твоя проблема. Ибо на массиве, r-b tree и hash map, структуры данных не заканчиваются.

Мне оно мозг, наоборот, укрепило. Например, я не пытаюсь пихать сомнительные паттерны везде, где только можно. И не хватаюсь использовать сторонние библиотеки только потому, что они выглядят красивее, чем кастомные решения. И главное, не считаю себя умнее всех.
Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами.