Hi Pepijn, is there any metric data regarding performance, code size etc - compared C and "new" C++?
Is there any plan to support other languages ( using language bindings ) ? >From my side, I would really like to see C version, but I guess C++ is "must have". Kind Regards, Miroslav V V pon., 7. jan. 2019 ob 22:25 je oseba Pepijn Noltes < [email protected]> napisala: > Hi All, > > The last weeks I put some effort in exploring the benefits and > downsides of changing the primary language of Celix from C to C++ in > an experimental branch. > > As you probably already know Celix start around 2010 with the focus on > a OSGi implementation in C; following the Java OSGi spec very > strictly. And IMO that was correct choice at that time and with our > given experience. > My current vision is that we should follow the concepts of OSGi and > where possible the nomenclature, but focus on delivering a (as much as > possible) easy to use dynamic services framework for C/C++. > > IMO this also means that we should think about moving to C++. Because: > a) With the concepts of C++11 we can create a much easier to use and > hopefully also easier to develop/maintain framework. > b) More type safe > c) RAII; which really helps a lot in dealing with volatile services > and trying to keep track of which services are still in use. > b) C++ is simply more relevant and popular, which should help in > getting more traction for Celix. > > To get the discussion rolling and for me to get a feeling what the > effect of moving to C++ would mean, I created C++ experimental (but > functionally quite complete) Celix C++ framework [1]. > And I would like some feedback/discussion if this is an improvement > for Celix or any remarks on the Celix C++ framework implementation. > > There are a few interesting changes in the approach/design of the C++ > framework: > 1) There is a separate (static) Registry library [2], which delivers > the functionality to register/use/track (and TODO listener hooks) > services. This library, by design, can be used without the rest of the > framework. I designed the Registry library separate to keep it clean > of bundles lifecycle stuff. > - ServiceRegistration/ServiceRegistry uses RAII to make it easier > in use, specifically for cleanup. > - The registry also support registering std::function as services, > this seems logical for C++. > - The service template argument is used to deduce the service name. > - The concept of services versions is dropped. I do think versions > on API is important, but more in a distributed environment. In my > experience for Celix everything should be build against the same > service API's. Playing around with backwards compatibility on binary > level with C++ is just reasonable. > 2) The framework library [3]. Here the focus in on the BundleContext > api so that almost everything can be done through the bundle context > api. > - It is now also possible to register "static" bundles. These > bundles are installed on every created Framework object. This make it > possible to register bundles with use a __attribute__((constructor)) > decorated function. With support for "static" bundles, bundles can be > created as shared objects, which "just work" if you link against them. > See the C++ Shell example [4]. IMO this is a much .. much more natural > way to handle bundles in a C/C++ environment. > - Support for zip bundles and dynamically loaded shared object - with > use a the bundle create, start,stop ..etc symbols is still TODO > - BundleActivator now work on the constructor/destructor, i.e. also > following a RAII approach. > - There is no concept of a ServiceReference (same as in the updated C > api). > 3) Resources can be linked against a shared object and in that way > OSGi extender pattern concept can be used without using zip files as > bundles. See the C++ Shell implementation as an example (this bundles > has a version.properties resource) [5]. > 4) For now glog is used as logging framework. > 5) libzip is used to handle the zip files. Note that resources linked > against the shared object bundles are packed as a zip file. > 6) googletest is used for testing. > - It is also easier to test bundles, because the test executable > "just" has to link against the bundle shared objects to make them > available. See the tests of the C++ Shell bundle [5] > 7) For now there is no way to export/import (versioned) shared objects > from other bundles. I personally do no think this is really needed (I > never use it myself). I also think that this should be solved by the > language itself (i.e. C++ Modules). > 8) As far as I can see it is possible to create a (mostly) backwards > compatibility C API from the C++ framework. As long as we only support > the updated C API, i.e. the the celix_* headers. > > The C++ framework API has no documentation yet, please be aware. I do > think that it should be clear enough for experience users and the > developers, but this is still a TODO. > Currently for C++ there is a Registry [2] library, a Framework library > [3], a C++ Shell bundle [5], a C++ Shell TUI bundle [6] and a single > example executable to run everything [4]. > I also took some effort to ensure that the code coverage result are > generated and somewhat respectable. > > My experience thus far is mostly positive. Fewer lines of code are > needed (duh), but also (mainly because of RAII) less if else branches > are needed / error handling is needed. > I do have some trouble arrange the code, because some part need to be > in the header (template) or in Impl classes to ensure a more clean > user API and the rest is in the sources files. > > Please feel free to let me know what you think. Note that this is > still experimental and we will discuss how to move forward later. > > [1] feature/cxx branch (for the 807b88 .. commit): > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f > [2] registry dir: > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/libs/registry > [3] > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/libs/framework_cxx > [4] > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/examples/celix-examples/cxx_shell_example > [5] > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/bundles/shell/cxx_shell > [6] > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/bundles/shell/cxx_shell_tui > > > Greetings, > Pepijn > -- Miroslav Beranič MIBESIS +386(0)40/814-843 [email protected] https://www.mibesis.si
