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

Я привык под расстрел пускать за использование std::shared_ptr.
Места, где бы он был полезен (в текущей его реализации) днём с огнём не сыщешь. Это должно быть многопоточное приложение, нетребовательное к производительности, в котором этот самый шаренный указатель будет дёргаться с разных потоков без захваченного мьютекса. Так что ты привёл пример, только подтверждающий бесполезность boost.
Более полезными альтернативами можно назвать:
1. Всё то же самое, но без попыток сделать thread safety. Конечно неэффективно, но дёшево и сердито. Многопоточный код всё равно может захватить мьютекс пока работает с объектом
2. Андройдовый wp/sp, который реализует аналогичную штуку, но ref counter хранит внутри объекта, на котрныц указывает. Даже многопоточный вариант будет эффективнее т.к меньше шансов false sharing, а размер указателя там как у обычного указателя получается
3. Другие способы управления памятью вроде пуллов или gc. Здесь нет основного недостатка: каждый доступ к указателю не делает ложного условного перехода в деструктор

Что же касаиельно STL - так он вслед за бустом тянет неудачные решения одно за другим, да и вообще был всегда скорее примером как можно сделать, а не реальной рабочей реализацией. Чего стоит то, что увеличение std::vector не может использовать realloc? Любой чувствительный к производительности проект рано или поздно делает свой вектор с блекджеком и кастомным аллокатором

Я привык под расстрел пускать за использование std::shared_ptr.
Места, где бы он был полезен (в текущей его реализации) днём с огнём не сыщешь. Это должно быть многопоточное приложение, нетребовательное к производительности, в котором этот самый шаренный указатель будет дёргаться с разных потоков без захваченного мьютекса. Так что ты привёл пример, только подтверждающий бесполезность boost.
Более полезными альтернативами можно назвать:
1. Всё то же самое, но без попыток сделать thread safety. Конечно неэффективно, но дёшево и сердито. Многопоточный код всё равно может захватить мьютекс пока работает с объектом
2. Андройдовый wp/sp, который реализует аналогичную штуку, но ref counter хранит внутри объекта, на котрныц указывает. Даже многопоточный вариант будет эффективнее т.к меньше шансов false sharing, а размер указателя там как у обычного указателя получается
3. Другие способы управления памятью вроде пуллов или gc. Здесь нет основного недостатка: каждый доступ к указателю не делает ложного условного перехода в деструктор