Почему контейнеры STL не имеют виртуальных деструкторов?

Виртуальный деструктор полезен только для сценариев наследования. Контейнеры STL не предназначены для наследования (и это не поддерживаемый сценарий). Следовательно, у них нет виртуальных деструкторов.

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

Я бы посоветовал вам действительно использовать контейнеры через композицию, а не реализацию наследование по принципу «имеет», а не «есть».

Я думаю, что Страуструп косвенно ответил на этот вопрос в своей фантастической статье: Почему C ++ не просто объектно-ориентированный язык программирования :

7 Заключительные замечания
Различны ли объекты, представленные выше объектно или нет? Какие? Используя какое определение объектно-ориентированный? В большинстве случаев я думаю, что это неправильные вопросы. Важно то, какие идеи вы можете ясно выразить, как легко ты можешь комбинировать софт из разных источники, и насколько эффективны и поддерживаемые результирующие программы являются. Другими словами, как вы поддерживаете хорошие методы программирования и хорошие методы дизайна имеют большее значение, чем ярлыки и модные слова. Фундаментальный идея - просто улучшить дизайн и программирование через абстракцию. Вы хотите скрыть детали, вы хотите использовать любую общность в системе, и вы хотите сделать это доступным. Я хотел бы призвать вас не сделать объектно ориентированным бессмысленным срок. Понятие «объектно-ориентированный» слишком часто унижается

- приравнивая его к добру,

- приравнивая это на одном языке, или

- на принимая все как объектно ориентированный.

Я утверждал, что есть - и должны быть - полезные методы, выходящие за рамки объектно-ориентированного программирование и дизайн. Однако чтобы не быть полностью непонятым, я хочу подчеркнуть, что я не стал бы заниматься серьезным проектом используя язык программирования, который по крайней мере не поддерживал классический понятие объектно-ориентированного программирования. В дополнение к объектам, поддерживающим объектно-ориентированное программирование, хочу - и C ++ предоставляет - функции, которые помимо тех, кто поддерживает прямое выражение концепций и

STL был построен, главным образом, с учетом трех концептуальных инструментов. Общее программирование + функциональный стиль + абстракция данных == стиль STL . Неудивительно, что ООП - не лучший способ представления библиотеки структур данных и алгоритмов. Хотя ООП используется в других частях стандартной библиотеки, разработчик STL увидел, что сочетание трех упомянутых методов лучше, чем одно ООП . Короче говоря, библиотека не была разработана с учетом ООП, и в C ++, если вы ее не используете, она не будет связана с вашим кодом. Вы не платите за то, чем не пользуетесь. Классы std :: vector, std :: list, ... являются не концепциями ООП в смысле Java / C #. Это просто абстрактные типы данных в наилучшей интерпретации.

Никакой виртуальный деструктор не препятствует правильному созданию класса подклассами.

вы не должны слепо добавлять виртуальный деструктор к каждому классу. Если бы это было так, язык не позволил бы вам другого выбора. Когда вы добавляете виртуальный метод в класс, у которого нет других виртуальных методов, вы просто увеличиваете размер экземпляров класса на размер указателя, обычно 4 байта. Это дорого, в зависимости от того, что вы делаете. Увеличение размера происходит потому, что создается v-таблица для хранения списка виртуальных методов, и каждому экземпляру требуется указатель обратно на v-таблицу. Обычно он находится в первой ячейке экземпляра.