Handles Comparison: empty classes vs. undefined classes vs. void*

Posted by Nawaz on Stack Overflow See other posts from Stack Overflow or by Nawaz
Published on 2010-12-24T10:47:05Z Indexed on 2010/12/24 11:54 UTC
Read the original article Hit count: 258

Filed under:
|
|
|
|

Microsoft's GDI+ defines many empty classes to be treated as handles internally. For example, (source GdiPlusGpStubs.h)

//Approach 1

class GpGraphics {};

class GpBrush {};
class GpTexture : public GpBrush {};
class GpSolidFill : public GpBrush {};
class GpLineGradient : public GpBrush {};
class GpPathGradient : public GpBrush {};
class GpHatch : public GpBrush {};

class GpPen {};
class GpCustomLineCap {};

There are other two ways to define handles. They're,

//Approach 2
class BOOK;  //no need to define it!
typedef BOOK *PBOOK;
typedef PBOOK HBOOK; //handle to be used internally

//Approach 3
typedef void* PVOID;
typedef PVOID HBOOK; //handle to be used internally

I just want to know the advantages and disadvantages of each of these approaches.

One advantage with Microsoft's approach is that, they can define type-safe hierarchy of handles using empty classes, which (I think) is not possible with the other two approaches. What else?

EDIT:

One advantage with the second approach (i.e using incomplete classes) is that we can prevent clients from dereferencing the handles (that means, this approach appears to support encapsulation strongly, I suppose). The code would not even compile if one attempts to dereference handles. What else?

© Stack Overflow or respective owner

Related posts about c++

Related posts about c