5

I've been using COM and .NET assemblies in the past to develop component-based-systems. Now I'm going to work on a cross-plattform-C++-project and want to structure the code in components aswell…

Obviously COM and .NET are not an option, as COM is not available anywhere but Windows and Assemblies would add dependencies to the .NET framwork which may be not available at the target system.

I'm aware that due to ABI-differences I won't be able to move components between different operating systems without recompilation, but I would like to write the code in a manner, that it's compatible at source-code-level.

Is there any system/framework that enables such a architecture in C++?

MFH
  • 1,664
  • 3
  • 18
  • 38
  • are you looking for communication across component/process/machines boundaries? – Jimmy Feb 26 '11 at 16:10
  • Related: http://stackoverflow.com/questions/1310338/does-any-c-component-framework-beyond-corba-components-exist. – Emile Cormier Feb 26 '11 at 16:26
  • Sharing the components between different programs would be nice, but is not mandatory. Neither are "remoting" or language independence… – MFH Feb 26 '11 at 16:27
  • 1
    won't *shared libraries* i.e. `Linux .so/Windows dll` be enough for your needs? COM's big promise, AFAIK, is the binary compatibility, so you can use the same component from anywhere, languages, scripts, browsers etc. Do you need this? If you just want to break your system into reusable, pluggable pieces, than seems that `.so` are simple and efficient enough. – davka Feb 26 '11 at 20:45
  • I somewhat came to the same conclusion - as I don't need interop with other client-languages - I might aswell use normal DLLs and SOs… Think I'll add a simple lookup-logic similar to COM and a class-factory system like in COM to fullfill my needs… – MFH Feb 26 '11 at 20:49

4 Answers4

2

The Mozilla suite uses a framework called XPCOM. Never used it myself, but the implication it's supposed to be like Microsoft's COM but portable. That's the only in-process component system I know of that's native code based; if you're working in Java, there's OSGi.

These days most Unix software appears to use distributed component models, where components live in different processes. The current fashionable system appears to be DBus; KDE3 used an alternative called DCOP; and of course if you want to go this route there's good old CORBA.

David Given
  • 13,277
  • 9
  • 76
  • 123
  • Thanks for the input. Actually XPCOM looks interessting, but according to Wikipedia it's playqued by a whole lot of Marshalling-Overhead… Gotta look into that before deciding wheter it's useable for me or not. Building such a - really basic - system up from the ground would be interessting - and time consuming :( Guess I'll have to look into native DLLs and shared objects… – MFH Feb 26 '11 at 17:47
2

I have worked with such a system in the past - we basically re-invented COM. If you are interested in that approach, check out this great article: http://msdn.microsoft.com/en-us/library/ms809983.aspx

Nemanja Trifunovic
  • 24,346
  • 3
  • 50
  • 88
2

If you can live with a Qt dependency (only core libraries, no GUI libs), you could have a look at the CTK Plugin Framework

It is licensed under Apache 2.0 and is a dynamic C++ component system with an API which is nearly identical to OSGi.

Sascha
  • 1,104
  • 8
  • 15
1

Maybe this: http://blog.redshoelace.com/2007/09/what-is-boostextension.html

Edward Strange
  • 40,307
  • 7
  • 73
  • 125