我读了很多:
...您可能想要 shared_ptrs ...
我会鼓励人们unique_ptr在不确定时默认。在shared_ptr没有内存所有权设计的情况下崩溃正是导致循环内存泄漏的原因。
是的,您也可以创建循环内存泄漏unique_ptr。然而,我的经验是,当unique_ptr使用它时,它会鼓励设计人员了解随着设计的发展谁拥有什么,从而降低循环内存泄漏的可能性,并且在发生时更容易调试。
如果在这个设计过程中,设计者发现共享所有权语义实际上是需要的,那么一定要努力shared_ptr(并且可能weak_ptr也打破这些循环)。
最后,尽快将原始指针绑定到智能指针。以下是遵循最佳实践的 OP 问题的可编译草图:
#include <type_traits>
#include <utility>
#include <memory>
#include <vector>
// A general purpose factory function for unique_ptrs
// Feel free to make this factory function more specific to your domain
template <class T, class ...Args>
typename std::enable_if
<
!std::is_array<T>::value,
std::unique_ptr<T>
>::type
make_ScreenParts(Args&& ...args)
{
return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}
// Your class hierarchy
struct ScreenBase
{
// Don't forget to make your destructors virtual
virtual ~ScreenBase() = default;
};
// Future-proof your code with typedef's
// If / when you need to switch smart pointer types
// or container types, you'll thank yourself
typedef std::unique_ptr<ScreenBase> ScreenPtr;
typedef std::vector<ScreenPtr> ScreenContainer;
struct GameplayScreen
: public ScreenBase
{
};
struct MenuScreen
: public ScreenBase
{
};
struct PauseScreen
: public ScreenBase
{
};
int main()
{
// raw pointers never exposed here...
ScreenContainer screens;
screens.push_back(make_ScreenParts<GameplayScreen>());
}