I am working on a multiplatform rendering API with implementations for DirectX 9 and DirectX 11.

Requirements:

- efficiency : no virtual calls

- minimal code duplication : declare the public API once only

- compile-time selection of the implementation

Nice to have:

- exposing to client code only the public API and not private methods and member variables of the actual implementation.

I have been exploring different approaches (e.g. http://www.altdevblogaday.com/2011/06/27/platform-abstraction-with-cpp-templates/ , http://www.altdevblogaday.com/2011/02/01/the-virtual-and-no-virtual/) and then stumbled upon this solution which seems to fit my requirements pretty well:

http://www.crickettechnology.com/blog/?p=116

I quite like this solution and I am considering using it for other systems. I strongly suspect FMOD uses it too, as the FMOD API classes contain only public methods. This solution puts some constraints on the class usage (it seals it and allows manipulation through pointers only). Moreover, the actual .cpp implementation file feels a little hacky and less pretty with all the additional downcasts. I kinda wish C++ supported partial class declarations as part of the language, for cases like mine.

What is your opinion about this approach ?

Thanks

It's called the pimpl idiom, it works, but then so do virtual functions.

class Implementation;
class Interface
{
public:
  Interface();
  void DoStuff();
private:
  Implementation* pimpl;
};
//cpp
Interface::Interface() : pimpl(new Implementation) {}
void Interface::DoStuff() { pimpl->DoStuff(); }

class Interface
{
public:
  static Interface* Create();
  void DoStuff();
};
//cpp
Interface* Interface::Create() { return (Interface*)new Implementation; }
void Interface::DoStuff() { ((Implementation*)this)->DoStuff(); }

struct Normal // a regular C++ class
{
  Normal( int x ) { printf("New Normal %d\n", x); }
  void DoStuff()  { printf("Normal::DoStuff\n" ); }
};

struct Interface // one of my 'PIMPL'-ish classes
{
  Interface( int x );
  void DoStuff();
private:
  ~Interface();//forces people to use my eiNewInterface macro, instead of new
};

//cpp
struct Implementation // an implementation of the above interface
{
  Implementation( int x ) { printf("New Implementation %d\n", x); }
  void DoStuff()          { printf("Implementation::DoStuff\n" ); }
};
// magic macros to bind this to the interface
eiImplementInterface( Interface, Implementation );
eiInterfaceConstructor( Interface, (x), int x );
eiInterfaceFunction( void, Interface, DoStuff, () );

//usage 
Scope a( ... );//my allocator
Normal* x = eiNew(a, Normal)( 42 ); // create a normal class
Interface* y = eiNewInterface(a, Interface)( 42 );//create an implementation of an interface

x->DoStuff();
y->DoStuff();

New Normal 42
New Implementation 42
Normal::DoStuff
Implementation::DoStuff

Thank you all for your opinions.

I was going to reply to RobTheBloke but Hodgman anticipated me with a well written clarification of the advantages of this approach compared to others. I like the suggestion of using macros to beautify the implementation code. The only thing I dislike is the use of a static Create function in the Interface class. I'd let the application take care of the creation of an actual implementation (based on #ifdef s) at a higher level. That would be the only code aware of the actual implementation while the rest of the code would just see the interface API.

nfactorial: this approach does not add a level of indirection as it simply casts the "this" pointer from the interface to its implementation; that should have zero overhead. Also, contrary to what you said, this approach improves compilation time and code decoupling: whenever the class declaration of an implementation changes, a single cpp file has to recompile instead of all code that includes the interface header file.

The naive typedef-based approach you suggest has two problems: first, all client code now depends directly on the DirectX API; second, the public API is duplicated in both the DX9Implementation and DX11Implementation class declarations. You could perhaps put that in a separate file and include it as part of the class declaration:

class DX9Implementation

{

public:

#include "device.h"

private:

};

but that's uglier in my opinion. Also it does not solve the first point.

Hope that's more clear.

The definition for the implementation still must be included in-order for the calls to be forwarded, you could put the call forwarding inside the cpp source file.

The bit after "//cpp" is supposed to be in the cpp file, hidden from the user. The user just sees a completely clean header, with zero implementation details.

I usually define the Implementation class either in a cpp (completely hidden from the world), or in a different header called foo_impl.h, if multiple implementation cpp files need to know about it. These implementation cpp files can incldue foo_impl.h (which might in turn include API-specific headers) while the user cpp files include just the clean foo.h.

So all you've added is extra compile time with no 'true' benefit.

Simplifying headers can greatly reduce C++ compile times.

I don't recommend doing this on everything. E.g. something like a templated container can't be hidden behind an interface (due to the templates), and would likely benefit from inlining.

With something like a GPU-device, or an OS-window, or a physics-scene though, there's a lot of API-specific types used in the implementation that the user doesn't need to know about. In these cases, I hide the implementation using this technique to keep the headers clean. Usually the loss of inlining in these cases isn't a big deal either, and in any case, you can get that kind of inlining back by enabling Link Time Code Generation.