Есть ли реальный риск получения из контейнеров C ++ STL?
Или, вернее, вы всегда должны использовать классы нового стиля, , если у вас нет кода, который должен работать с версиями Python старше 2.2.
7 ответов
Потому что вам нужен виртуальный деструктор, а в контейнерах std его нет. Контейнеры std не предназначены для работы в качестве базового класса.
Для получения дополнительной информации прочтите статью «Почему мы не должны наследовать класс из классов STL?»
Рекомендация
Базовый класс должен иметь:
- публичный виртуальный деструктор
- или защищенный невиртуальный деструктор
Стандартные контейнеры не имеют виртуальных деструкторов, поэтому вы не можете обрабатывать их полиморфно. Если вы этого не сделаете, и все, кто использует ваш код, не будут этого делать, это не «неправильно» само по себе. Однако для ясности в любом случае лучше использовать композицию.
На мой взгляд, один сильный контраргумент состоит в том, что вы навязываете интерфейс и реализацию вашим типам. Что произойдет, если вы обнаружите, что стратегия распределения векторной памяти не соответствует вашим потребностям? Будете ли вы производным от std: deque ? А как насчет тех 128K строк кода, которые уже используют ваш класс? Всем ли нужно будет все перекомпилировать? Будет ли он компилироваться?
Помимо того факта, что базовому классу нужен виртуальный деструктор или защищенный не виртуальный деструктор, вы делаете следующее утверждение в своем проекте:
Ставки и сборы, если на то пошло, ТАК ЖЕ, КАК вектор удвоений в приведенном выше примере. По вашему собственному утверждению «... со временем ставки и сборы развивают личности ...», тогда является ли утверждение, что ставки ТАК ЖЕ, КАК , вектор удвоения на данный момент? Например, вектор двойников не является синглтоном, поэтому, если я использую ваши ставки для объявления моего вектора двойников для виджетов, у меня может возникнуть головная боль из-за вашего кода. Какие еще тарифы и сборы могут быть изменены? Надежно ли изолированы какие-либо изменения базового класса от клиентов вашего проекта, если они изменятся фундаментальным образом?
Дело в том, что класс является одним из многих элементов в C ++, выражающих намерения проекта. Сказать то, что вы имеете в виду, и иметь в виду то, что вы говорите, является причиной против использования наследования таким образом.
... Или просто написал более сжато перед моим ответом: Замена.
Кроме того, в большинстве случаев по возможности следует предпочесть композицию или агрегацию наследованию.
Проблема не в философии, а в реализации. Деструкторы стандартных контейнеров не являются виртуальными, а это означает, что нет способа использовать для них полиморфизмы времени выполнения, чтобы получить правильный десктруктор.
На практике я обнаружил, что создать свой собственный не так уж и сложно. настраиваемые классы списков только с теми методами, которые необходимы моему коду (и частным членом «родительского» класса). Фактически, это часто приводит к созданию лучше спроектированных классов.