C++ equivalently performant version of C-like implementation

Question

I'm learning C++ while I run into this situation, where I want to implement an equivalently efficient version in C++ of the following symbolic code in C.

<header.h>
struct Obj;
Obj* create(...);
void do_some_thing(Obj*);
void do_another_thing(Obj*);
void destroy(Obj*);

The requirements are:

• The implementation is provided in a library (static/dynamic) and the header doesn't expose any detail other than the interface
• It should be equally efficient

Exposing an interface (COM-like) with virtual functions doesn't qualify; that's a solution to enable polymorphism (more than one implementation exposed through the same interface) which isn't the case, and since I don't need the value it brings, I can't see why I should pay the cost of calling functions through 2 indirect pointers. So my next thought was the pimpl idiom:

<header.h>
class Obj {
public:
  Obj();
  ~Obj();
  void do_some_thing();
  void do_another_thing();
private:
  class Impl;
  smart_ptr<Impl>  impl_; // ! What should I use here, unique_ptr<> or shared_ptr<> ?
};

shared_ptr<> doesn't seem to qualify, I would pay for unnecessary interlocked increment/decrement that didn't exist in the original implementation. On the other hand unique_ptr<> makes Obj non-copyable. This means that the client can't call his own functions that take Obj by value, and Obj is merely a wrapper for a pointer, so essentially he can't pass pointers by value! He could do that in the original version. (passing by reference still doesn't qualify: he's still passing a pointer to a pointer)

So what should be the equally efficient way to implement this in C++?

EDIT: I gave it some more thought and I came to this solution:

<header.h>
class ObjRef // I exist only to provide an interface to implementation
{            //  (without virtual functions and their double-level indirect pointers)
public:
  ObjRef();
  ObjRef(ObjRef);           // I simply copy pointers value
  ObjRef operator=(ObjRef); // ...
  void do_some_thing();
  void do_another_thing();
protected:
  class Impl;
  Impl*  impl_; // raw pointer here, I'm not responsible for lifetime management
};

class Obj : public ObjRef
{
  Obj(Obj const&);            // I'm not copyable
  Obj& operator=(Obj const&); // or assignable 
public:
  Obj(Obj&&);                 // but I'm movable (I'll have to implement unique_ptr<> functionality)
  Obj& operator=(Obj&&);
  Obj();
  ~Obj(); // I destroy impl_
  // and expose the interface of ObjRef through inheritance
};

Now I return to client Obj, and If client needs to distribute the usage of Obj by calling some other his functions, he can declare them as

void use_obj(ObjRef o);

// and call them:
Obj o = call_my_lib_factory();
use_obj(o);

Answer 1

Why not keep the C original? The reason that you didn't have to pay the reference counting premium in the C version is that the C version relied on the caller to keep any tally of the number of copies of Obj* in use.

By trying to ensure that the replacement is both copyable and that ensure that the underlying destroy method is only called once the last reference is destroyed you are imposing additional requirements over the original, so it is only natural that the proper solution (which seems to me to be shared_ptr) has some limited additional expense over the original.

Answer 2

I assume there's a reason why you need the a pointer to the object in the first place. Because the simplest, and most efficient approach, would be to just create it on the stack:

{
  Obj x(...);
  x.do_some_thing();
  x.do_another_thing();
} // let the destructor handle `destroy()` when the object goes out of scope

But say you need it created on the heap, for whatever reason, most of it is just as simple, and just as efficient:

{
  std::unique_ptr<Obj> x = Obj::create(...); // if you want a separate `create` function
  std::unique_ptr<Obj> x = new Obj(...); // Otherwise, a plain constructor will do

  x->do_some_thing();
  x->do_another_thing();
} // as before, let the destructor handle destruction

There is no need for inheritance or interfaces or virtual functions. You're writing C++, not Java. One of the fundamental rules of C++ is "don't pay for what you don't use". C++ is as performant as C by default. You don't have to do anything special to achieve good performance. All you have to do is not use the features which have a performance cost if you don't need them.

You didn't need reference counting in your C version, so why would you use reference counting in the C++ version (with shared_ptr)? You didn't need the functionality that virtual functions provide in the C version (where it would be implemented through function pointers), so why would you make anything virtual in the C++ function?

But C++ lets you tidy up the create/destroy stuff in particular, and that costs you nothing. So use that. Create the object in its constructor, and let its destructor destroy it. And just place the object in an appropriate scope, so it'll go out of scope when you want it destroyed. And it gives you nicer syntax for calling "member" functions, so make use of that too.

On the other hand unique_ptr<> makes Obj non-copyable. This means that the client can't call his own functions that take Obj by value, and Obj is merely a wrapper for a pointer, so essentially he can't pass pointers by value! He could do that in the original version. (passing by reference still doesn't qualify: he's still passing a pointer to a pointer)

The client can take Obj by value if you use move semantics. But if you want the object to be copied, then let it be copied. Use my first example, and create the object on the stack, and just pass it by value when it needs to be passed by value. It it contains any complex resources (such as pointers to allocated memory), then be sure to write an appropriate copy constructor and assignment operator, and then you can create the object (on the stack, or wherever you need it), pass it around as you desire, by value, by reference, by wrapping it in a smart pointer, or by moving it (if you implement the necessary move constructor and move assignment operator).