我不相信你可以直接用shared_ptr API来做到这一点。
如果Lib :: SomeClass是一个接口/抽象基类,您可能可以使用Decorator。这个想法是定义一个类Lib::SomeClass
的子类,包含shared_ptr<Lib::SomeClass>
和std::ofstream*
,其方法都转发给包含的shared_ptr的相应方法。然而,装饰者的析构函数将删除包含的ofstream
(或者您可以将其存储在某种RAII容器中,如scoped_ptr
)。所以这将是您传递给appendWriter的装饰器实例。这里有一个素描:
class SomeClassDecorator : public Lib::SomeClass
{
public:
SomeClassDecorator(shared_ptr<Lib::SomeClass> p, std::ofstream* stream)
: p_(p), stream_(stream)
{}
virtual int MethodOfSomeClass(int x) {
return p_->MethodOfSomeClass(x);
}
private:
shared_ptr<Lib::SomeClass> p_;
scoped_ptr<std::ofstream> stream_;
};
std::ofstream* out = new std::ofstream();
...
shared_ptr<Lib::SomeClass> writer = Library.createWriter(out);
shared_ptr<Lib::SomeClass> wrapper(new SomeClassDecorator(writer, out));
Library.appendWriter(wrapper);
对我来说,就像createWriter()API定义的契约一样,应该指定谁拥有输入流*,并且暗示它如何以及何时被释放。要么图书馆释放它,要么你必须。我没有看到它封装在一个shared_ptr帮助,除非这是如何定义createWriter()。 – 2010-09-17 17:24:03
他们没有指定它,但从看他们的代码,我看到他们希望我拥有它。不幸的是,当他们不再使用它时,他们不告诉我。这就是为什么它认为等待shared_ptr发布可能是一个可行的解决方案。 – 2010-09-17 17:31:22
除非API采用shared_ptr,否则您已经回到了原点。一旦交给图书馆后会发生什么?它在库代码中不再被使用时显而易见?如果您可以将最终的使用情况与代码中的API使用情况相关联,则可以确定一个合理的点来假设您可以清理流。 –
2010-09-17 17:52:38