使用shared_ptr作为输出参数 我正在研究一个C++ API,它从一个DLL导出了几个类。

使用shared_ptr作为输出参数 我正在研究一个C++ API,它从一个DLL导出了几个类。,c++,api,error-handling,shared-ptr,C++,Api,Error Handling,Shared Ptr,公共类接口应遵循以下约定: 所有函数都返回一个错误代码 输出参数用于其他返回值 传递指针用于输出参数 Pass-by-const引用用于输入参数(原语类型的Pass-by值) 当客户端应该拥有输出参数的所有权时,将使用shared_ptr,否则将使用普通指针 接口示例: typedef std::shared_ptr<Object> ObjectPtr; class APIClass { ErrorCode SetSomething(int i); ErrorC

公共类接口应遵循以下约定:

  • 所有函数都返回一个错误代码
  • 输出参数用于其他返回值
  • 传递指针用于输出参数
  • Pass-by-const引用用于输入参数(原语类型的Pass-by值)
  • 当客户端应该拥有输出参数的所有权时,将使用
    shared_ptr
    ,否则将使用普通指针
接口示例:

typedef std::shared_ptr<Object> ObjectPtr;

class APIClass
{
    ErrorCode SetSomething(int i);
    ErrorCode IsSomethingSet(bool* ask);
    ErrorCode DoSomething();
    ErrorCode GetSomething(ObjectPtr* outObj);
}
GetSomething实现:

ErrorCode APIClass::GetSomething(ObjectPtr* outObj)
{
   ObjectPtr temp(new Object(), CleanUpFunction<Object>);

   // Do something with object temp.
   ...

   *outObj= temp;

   return OK;
}
ErrorCode APIClass::GetSomething(ObjectPtr*outObj)
{
ObjectPtr temp(新对象(),CleanUpFunction);
//对对象温度执行一些操作。
...
*outObj=温度;
返回OK;
}

以这种方式使用共享ptr是否节省成本,或者是否存在我应该注意的可能问题

这很好,但我想问一下,在这种情况下是否真的需要共享指针。主要是因为您无法以任何正常的方式从
共享\u ptr
释放指针。。。这可能会导致以后出现问题。而
shared_ptr
实际上意味着底层资源的未指定或共享所有权

我通常会记录函数,并使用以下内容:

// Caller must delete the outObj once done.
ErrorCode APIClass::GetSomething( Object* & outObj )
{
  // I use auto_ptr so I can release it later...
  // Mostly I hate auto_ptr, but for this its invaluable.

  auto_ptr<Object> obj( new Object );
  ...
  outObj = obj.release();
  return OK;
}
//调用方完成后必须删除outObj。
错误代码APIClass::GetSomething(对象*&outObj)
{
//我使用auto_ptr,以便稍后发布它。。。
//大多数情况下,我讨厌auto_ptr,但这是非常宝贵的。
自动ptr obj(新对象);
...
outObj=obj.release();
返回OK;
}
这样,由客户机决定他们要将指针存储到什么中,并且很明显,对象的所有权会传递给调用方

然后,客户机代码可以使用适当的容器

Object * obj_raw;
ErrorCode ec = apiClass.GetSomething( obj_raw )
if( ec!=OK ) { .. do something with ec .. }
shared_ptr<Object> obj( obj_raw );
Object*obj_raw;
错误代码ec=apiClass.GetSomething(obj_原始)
如果(ec!=OK){..用ec做点什么..}
共享对象(obj_raw);

auto_ptr obj(obj_raw);

scoped_ptr obj(obj_raw);
等等

请注意,如果将函数定义更改为:

// Caller must delete the return value.
// On error, NULL is returned and e filled in appropriately.
Object* APIClass::GetSomething( ErrorCode & e )
{
   auto_ptr<Object> obj( new Object );
   ..
   e = OK;
   return obj.release();
}

//Now using it looks like this:
ErrorCode ec;
shared_ptr<Object> obj( apiObject.GetSomething(ec) ); 
if(!obj)
{
   .. do something with ec ..
}
//调用方必须删除返回值。
//出现错误时,返回NULL并正确填写e。
对象*APIClass::GetSomething(错误代码&e)
{
自动ptr obj(新对象);
..
e=正常;
返回obj.release();
}
//现在使用它看起来像这样:
错误代码ec;
共享对象(apiObject.GetSomething(ec));
如果(!obj)
{
…用ec做点什么。。
}

您是否考虑过使用而不是返回错误代码?是的,但我不想使用异常,因为在DLL范围内使用它们受到限制。编辑该问题,因为它太冗长。感谢您的回复。跨DLL边界(至少在Windows上)传递指针存在问题,例如在DLL中分配内存并在客户端删除内存。请参见此处:。这就是为什么我在创建共享\u ptr时使用DLL(CleanUpFunction)中定义的自定义删除程序的原因。但一般来说,您认为解决方案应该很好,正如我所理解的那样?在这种情况下,以后不能释放指针可能会有问题,或者为什么要释放它?此外,我正在考虑与您提到的类似的替代设计,将错误代码作为可选参数传递,如:ObjectPtr APIClass::GetSomething(ErrorCode*e=nullptr)。但是还不能决定哪种设计更好。@Hoschie0815您可能希望稍后发布它的原因是将它传递给一个期望获得对象所有权的接口。@Hoschie0815
shared\u ptr
不会使您免于内存分配问题,因为shared\u ptr构造函数分配一个块(包含引用计数等)及其析构函数将释放该块。如果在DLL中创建该块并在DLL外部销毁,则返回的问题与此完全相同。
auto_ptr<Object> obj( obj_raw );
scoped_ptr<Object> obj( obj_raw); 
// Caller must delete the return value.
// On error, NULL is returned and e filled in appropriately.
Object* APIClass::GetSomething( ErrorCode & e )
{
   auto_ptr<Object> obj( new Object );
   ..
   e = OK;
   return obj.release();
}

//Now using it looks like this:
ErrorCode ec;
shared_ptr<Object> obj( apiObject.GetSomething(ec) ); 
if(!obj)
{
   .. do something with ec ..
}