Наверное логично брать лучшее из stl?

да я не против ВООБЩЕ, ну это говорит о лени чуваков... изначально то было круче STL сделано

В смысле о лени? Изначально этого не было в stl... Потом там появилось. Соответственно, всё лучшее стоит взять оттуда, а если не взять, то хоть обеспечить совместимость на уровне api.

если бы сами развивали, то были бы как и 10 лет назад на два шага впереди

Я бы по другому вопрос поставил. Почему qt не сидит в группе стандартизации и не проталкивает свои реализации/хотелки в язык, а пилить их только на уровне фреймворка?

explicitly shared не даст контейнерам Qt быть на шаг впереди, они будут на шаг-два сзади. поэтому контейнеры - это не конек Qt, во всяком случае не конек в плане производительности. это просто кроссплатформенный обвес, который все больше и больше тянет назад...

Тоесть их проще слить и юзать контейнеры в STL, которые реализованы лучше🤔

Не совсем, посколько отсутствие explicit shared ударит по сигналам и слотом.

:()

Михаил... ну тут уже риторика :) Ну да.. по русски это было с появлением 5.15 так "какго суки, у вас же было все заебись и впереди планеты всей" и знаешь... они не услышали :D

А их прям необходимо использовать? Я например в основном stl'ные варианты юзаю для контейнеров с Qt типами, ни разу не могу вспомнить каких-то проблем с этим.

никаких проблем и нет, просто STL контейнер полностью копируется, то есть, идут лишние копии

Ага, а у Qtшные какие-то оптимизации под капотом есть для этого? Там что-то типа глобальной ECS и он хранит рефки?

COW

понял