Я понимаю почему std::forward_list
не имеет size()
функция-член, с тех пор O(1)
версия будет испортить сложность определенных splice()
перегрузки, а так как O(N)
версия будет несовместима со всеми остальными контейнерами стандартной библиотеки.
Также верно, что оба std::list
а также std::forward_list
уже есть несколько других функций-членов с той же семантикой, что и их кузены из <algorithm>
угол стандартной библиотеки (merge()
, reverse()
, remove()
, remove_if()
, unique()
, sort()
).
Так почему не было count()
функция-член O(N)
сложность предоставляется std::forward_list
который имел семантику возвращения std::distance(std::begin(some_list), std::end(some_list))
?
Функции члена, о которых вы упомянули (merge()
, reverse()
, remove()
, remove_if()
, unique()
, sort()
), потому что они имеют лучшую сложность, чем общие алгоритмы в <algorithm>
стандартные заголовки.
Функция-член, такая как count()
с другой стороны, не сложнее, чем std::distance(std::begin(some_list), std::end(some_list))
,
Кроме того, это может быть неверно истолковано как более сложная версия std::count
универсальный алгоритм, который делает что-то принципиально другое.
Причина в том, что, в отличие от перечисленных вами функций, использование стандартного библиотечного алгоритма для функции count или size будет такой же быстрой версией, которая имеет прямой доступ к базовой реализации.
Каждая из функций-членов, о которых вы упомянули std::forward_list
на самом деле быстрее, когда реализовано в качестве членов. В частности, они могут работать без выполнения каких-либо ненужных копий или перемещений содержащихся данных. Версии алгоритма стандартной библиотеки требуют, чтобы данные в контейнере были скопированы или перемещены.