What are the strengths and weaknesses of using VTable/COM-centric APIs?

1 week ago 4
ARTICLE AD BOX

I'm currently designing a library,
I want this library to maintain a stable interface for old applications,
however it should be expandable.
It acts as a hardware abstraction layer.

The graphics libraries OpenGL, Vulkan or DirectX come closest in terms of requirements.

Comparing them unveiled three different approaches to providing an API:

OpenGL provides a certain set of stable symbols, while the rest of the symbols has to be obtained at runtime, via GetProcAddress or dlsym. This requires the user, to either get the function pointers on their own, or to use a library such as glew, glproxy or now commonly used epoxy.

This seems rather cumbersome.

Vulkan decided to take a similar approach, by only exporting the symbols of the core profile.
However most notably, a lot of the extension specific functionality can be accessed via a single-linked list passed to functions, informing about the extensions of the structure.

Now we come to the core of my question:

The DirectX API uses a singular function, that has to be linked in.
"Direct3DCreate9", which is called by passing a parameter identifying the version of the headers that were used during compilation. After that, a pointer is received to an opaque object, that can be accessed via virtual functions.

To me this seems like the most simple approach.
And I fail to see why not more libraries opted for this.
There must be something I'm missing.

I appreciate any input about experiences with maintaining or using different API approaches!

Read Entire Article