0

This question follows the previous one below:

Easy way to guarantee binary compatibility for C++ library, C linkage?

I wondered if making interface functions of C++ DLL or shared library with C linkage brings forward compatibility of Compiler and of standard library.

extern "C" someAPI();

The most voted answer was saying that I am wrong. The answer recommended making it open-source. And never mentioned about COM or CORBA. Making it open-source is not always possible.

But recently I am reading books about Windows COM. And I think COM maybe brings the compatibility I wanted. And there is another thing CORBA.

So I wonder if these things, COM and CORBA, really brings forward compatibity of compiler and standard library?

I think network library ACE uses CORBA. And that is only one I know about CORBA. Isn't CORBA popular nowadays? What about COM? ActiveX is maybe disappearing but WDF(Windows Driver Foundation) depends on COM.

Thank you very much!

Jumogehn
  • 1,102
  • 3
  • 11
  • 29
  • 1
    I'm not familiar with CORBA. COM ensures binary compatibility by (among other things) strictly limiting the allowed types of method parameters and return values to a subset of POD types. In particular, no standard library classes (or, for that matter, user-defined classes) can be mentioned in a COM interface, rendering the issue of standard library compatibility moot. – Igor Tandetnik Jan 02 '18 at 12:02

1 Answers1

3

Yes, COM was created, among other reasons, to overcome source code (and .obj, static lib, etc.) reuse issues, whether that source is C/C++ or anything else.

The essence of COM (v-table layout + IUnknown, forget about registration, OLE, Automation, marshaling, and other additional stuff) is very simple (in fact, it's hard to make it more simple). Since it only relies on binary contracts, you can write COM client and/or server code using any language (and any platform, but in reality, only Windows uses it). So you can have a 32-bit COM client written in python talk to a 64-bit COM server written in C++ for example (well, this example in fact requires some cross process marshaling, so it's not pure lightweight COM).

COM is very far from being dead or disappearing (because it's, again, quite simple). "ActiveX" was a marketing / tech mix name, but it's basically COM, and is massively used in Windows, by Windows and 3rd parties.

COM over the physical network (DCOM) is indeed disappearing (in favor of other technologies, like Web, sockets, HTTP, REST, or in general technologies more simple than COM), and what's still used today is basically in-process and out-process COM (out-process is somehow DCOM on the same machine).

I know that CORBA was once upon a time a strong COM competitor (especially because it was available on multiple platforms, including Windows), but it seems to be seriously declining, also in favor of the same more simple technologies (web, etc.).

Simon Mourier
  • 132,049
  • 21
  • 248
  • 298