我应该为需要在堆上分配的多态类创建包装器吗？(Should I make wrappers for polymorphic classes that need to be allocatd on th

我应该为需要在堆上分配的多态类创建包装器吗？(Should I make wrappers for polymorphic classes that need to be allocatd on the heap?)

现在，我正在开发的游戏的GUI API有一个抽象的Image和Font类。 根据他们是否使用GL，SDL等字体，他们加载如下字体：

Font *segoe = Font::load("segoe.ttf");

还有一个相应的destroy（）静态函数。

我喜欢这个设计，但我想知道包装它是否是一个好主意，以便不需要指针。 像这样的东西（更好的命名约定）

WrappedFont segoe = WrappedFont(Font::load("segoe.ttf"));

它也会超载=和拷贝ctor，以及析构函数。

对于用户来说，通常更希望用户管理他们的图像和字体，还是更适合包装图案？

谢谢

Right now, the GUI API for games I''m developing has an abstract Image and Font class. Depending on whether they use a GL, SDL etc Font, they load fonts like this:

Font *segoe = Font::load("segoe.ttf");

There is also a corresponding destroy() static function as well.

I like this design, but I was wondering if it would be a good idea to wrap it so that no pointers needed. Something like this (with better naming conventions)

WrappedFont segoe = WrappedFont(Font::load("segoe.ttf"));

It would also have overloaded = and a copy ctor, and a destructor.

Is it generally more desired for a game gui for the user to manage their Images and Fonts, or is a wrapped pattern more desirable?

Thanks

最满意答案

基本上，这是一个自定义智能指针类型来处理load/destroy逻辑。 这是非常惯用的，也是使用C ++的方法。 资源管理应该是自动的。

所以你的包装很好，但也许你在这里重新发明轮子。 您可以考虑重写将destroy完成的工作移动到Font析构函数的字体系统，在这种情况下，您可以使用常规的boost::shared_ptr （也可以在旧版编译器中分别从C ++ 0x中的std::tr1中获得）支持技术报告1）。 使用当前代码，您也可以使用shared_ptr ，但是您需要提供自定义删除器，我觉得这有点麻烦。

Basically, that's a custom smart pointer type to handle the load/destroy logic. This is very idiomatic and the way to go in C++. Resource management should be automatic.

So your wrapper is fine, but perhaps you are reinventing the wheel here. You may consider rewriting the font system that the work done by destroy is moved to the Font destructor, in which case you could use a regular boost::shared_ptr (also available from std in C++0x respectively std::tr1 in older compilers with support for the Technical Report 1). With your current code you can use shared_ptr as well, but you need to supply a custom deleter, which I find a bit cumbersome.