celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerrit Binnenmars <gerritbinnenm...@gmail.com>
Subject Re: [DISCUSS] C++ Celix Framework
Date Tue, 08 Jan 2019 18:13:01 GMT
Hello Pepijn,

I am a bit concerned by this move. Introducing C++ in the framework makes
Celix no longer a dynamic service framework for C.
I understood the support for C++ in the API, so C++ bundles were supported,
but this is something different.
A lot of effort is put in the code quality and stability of the framework,
does this work need to be done once more?

My conclusion: I would prefer to keep the framework as is and concentrate
on adding functionality.
A C++ framework implementation does not bring enough to Celix.
If you really want to continue this should not go into Celix but in a new
Apache project.

I am quite curious what the rest of the community thinks.

Gerrit



On Mon, Jan 7, 2019 at 11:19 PM Miroslav Beranič <
miroslav.beranic@mibesis.si> wrote:

> 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 <
> pepijnnoltes@gmail.com> 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
> miroslav.beranic@mibesis.si
> https://www.mibesis.si
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message