Действительно удаляет работу с указателями на базовый класс?
Существует еще один способ использования Spring-управляемых компонентов в JSF-управляемых компонентах, просто расширяя ваш JSF-компонент из SpringBeanAutowiringSupport, а Spring будет обрабатывать инъекцию зависимостей.
@ManagedBean // JSF-managed.
@ViewScoped // JSF-managed scope.
public class GoodBean extends SpringBeanAutowiringSupport {
@Autowired
private SpringBeanClass springBeanName; // No setter required.
// springBeanName is now available.
}
2 ответа
Да, это будет работать, , если и только если деструктор базового класса является виртуальным, который Вы сделали для Base базовый класс, но не для IFoo базовый класс. Если деструктор базового класса является виртуальным, то, когда Вы звоните operator delete на указателе базового класса, он использует динамическую отправку, чтобы выяснить, как удалить объект путем поиска деструктора производного класса в таблице виртуальной функции.
В Вашем случае множественного наследования, это будет только работать, если базовый класс, Вы удаляете его через, будет иметь виртуальный деструктор; для других базовых классов нормально не иметь виртуальный деструктор, но только если Вы не пытаетесь удалить любые производные объекты через те другие указатели базового класса.
Это не касается Вашего данного примера, но так как Вы упомянули, что действительно интересуетесь shared_ptr поведение при удалении его находящегося в собственности объекта, Вы могли бы интересоваться использованием shared_ptr 'средство удаления'.
, Если объект, принадлежавший shared_ptr потребности специальная обработка, будучи удаленным, можно определить 'средство удаления' для какого-либо конкретного shared_ptr<>. Средство удаления не является частью типа, это - атрибут shared_ptr<> экземпляр, таким образом, Ваш контейнер shared_ptr<> объекты мог иметь некоторые объекты с различными средствами удаления. Вот то, что документы Повышения говорят о shared_ptr<> средство удаления:
Пользовательские deallocators позволяют функции фабрики возврат
shared_ptrдля изоляции пользователя от его стратегии выделения памяти. Так как deallocator не является частью типа, изменение стратегии выделения не повреждает источник или совместимость на уровне двоичных кодов, и не требует клиентской перекомпиляции. Например, "нет" deallocator полезен при возвратеshared_ptrк статически выделенному объекту, и другие изменения позволяютshared_ptrиспользоваться в качестве обертки для другого интеллектуального указателя, упрощая совместимость.
Это было бы самым чистым, если Вы могли бы изменить IFoo для имения виртуального деструктора, так как Вы планируете удалить объекты, которые являются подклассами его через IFoo ссылка или указатель. Но если Вы застреваете с IFoo, который не может быть исправлен, тогда если Вы хотите использовать shared_ptr<IFoo> в Вашем контейнере, но иметь его указывающий Bar, Вы могли создать shared_ptr экземпляр со средством удаления, которое работает, удрученное к Bar* тогда делает удалить операцию. Downcasts считают невоспитанностью, но эта техника могла бы быть чем-то, что Вы могли использовать в связывании.