celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miroslav Beranič <miroslav.bera...@mibesis.si>
Subject Re: [DISCUSS] C++ Celix Framework
Date Wed, 09 Jan 2019 08:29:37 GMT
Hi all,

I've started working with Celix back at 2015. At that time, I as "all about
C++" and thought about C as "C++ predecessor that will fall out", so C++
was obvious was forward. With use of Celix, I've started to see solutions
implemented in C that at that time I thought "only possible in C++". With
time, I've dropped C++ all-together as to my opinion, C++ standard is
moving to fast to radical. For example, Google C++ Style Guide advice on
the C++ is:

" Currently, code should target C++11, i.e., should not use C++14 or C++17
features. The C++ version targeted by this guide will advance
(aggressively) over time.
Code should avoid features that have been removed from the latest language
version (currently C++17), as well as the rare cases where code has a
different meaning in that latest version. Use of some C++ features is
restricted or disallowed. Do not use non-standard extensions."

Over time I've started to appreciate the simplicity of C ( this does not
mean it is less capable ). With C++ there is so many hidden things
generated, it starts to feel like Java. One note here: my day-to-day job is
around Apache Karaf, Camel, JMS, ... enterprise integration; but more and
more I am thinking about porting ( step by step ) from existing bloated
environments where all I want is move data from one end to another to
simple & fast - like Celix. But here, yes - there is a lot of missing
components that Java based "OSGi implementation" counterpart already has.
And it would make ( financially ) no real benefit -- no one will approve
such a project to me.

In my "night time" job I use Celix since day one of using Celix. All I want
from Celix is that it is simple and runs super fast ( and for sure stable ).
@Pepijn, you might do not remember that I wrote about C++ back in 2015. You
wrote back:
"I think support bundles written in other (native) language is quite
feasible. I even started prototyping with some Swift code (which is
promised to become open source) . The beauty about C is that it is the
common dominator for native languages and therefore ideal as core framework
language.
The biggest challenges would be how and if those bundles can share services
written in different language. So cpp pure abstract class as service used
in a C bundle ??
Note that this is my opinion and not _the_ Celix policy, everything is
discussable."

At that time I really started to thing about C as common nominator. Now I
have same code base ( with some obvious differences ) running on Arduino,
Android, RaspberryPI ( Yocto project ) and WebAssembly ( all about moving
data from one end to another using ASN.1 ). To me C is holy grail. It does
have more verbose syntax and it does not all the compile-time checking as
C++ does ( a lot has void* ), but it produces a lot smaller/portable code.
I agree also, this is possible also because I do not know all the latest
bells and whistles from C++. To me C++ is like moving target. It is modern
now, in 5 years time we are talking about "old" C++. With C, code base from
15 years ago works and documentation is valid.

At the and I agree someone will start to implement C++ "version of Celix"
as this is reality. I also agree this should be Celix community, not some
outside community. I would also argue that there should be only C and only
C++ implementations as from my experiences, mixing C and C++ is useless. It
does not have C way of work, it does not have C++ way of work. And C++ is
not "just" C with classes. I do agree C++ has benefits, but we all should
know what those benefits are. Also what is the goal of Celix, what is
roadmap. Is this even an option?

What I am missing from Celix is added functionality. At the end do not
really care C or C++, as long as the metrics are what is expected.

Regarding my metrics data questions, my wife was recently awarded PhD
regarding measuring metrics in software, so I am all about metrics this
days. Did not plan to be "rude" or anything. Main point was - is it
possible to measure benefits of going forward with C++ or not. Is this data
showing better results or not? Would new/better/updated version of C
implementation yell better results? If we can put scale and values on that
scale, decision would be easier. To me it is all about code size it
produces and speed it executes ( with stability).

With languages I was thinking about Lua ( not really programming language,
but hey ... ), Rust, Dart, Java. I guess most of this can be solved with
bindings.

To close this one: Go with C or C++, but do not mix. If core needs to be
updated it would be nice if it could be done in C ( in existing code base
). If C++ is taken, use it with all the features it has and not use it as
C. In either way Celix needs more added functionalities ( with clear goals
and roadmap ).

Kind Regards,
Miroslav







V V tor., 8. jan. 2019 ob 21:24 je oseba Pepijn Noltes <
pepijnnoltes@gmail.com> napisala:

> Hi,
>
> On Tue, Jan 8, 2019 at 7:13 PM Gerrit Binnenmars
> <gerritbinnenmars@gmail.com> wrote:
> >
> > 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.
>
> Note that even if the framework is done is C++, we can still deliver a
> C API - for the framework and for the services provided by the
> bundles.
> It does add a mandatory requirement to a C++(11) compiler and
> dependency to libstdc++.
>
> My concern here is that moving to C++ could (eventually) lead to some
> bundles only provided/consuming a C++ API and shut out C support.
>
> > A lot of effort is put in the code quality and stability of the
> framework,
> > does this work need to be done once more?
>
> I understand your concern, and yes of course recreating the framework
> will lead to some stability issues.
> I started experimenting with a C++ framework for two reasons; 1) I
> wanted to tryout what features/concepts of C++ we should include in a
> C++ API to make it more accessible for C++ users and 2) IMO the
> current implement/design of the Celix framework is flawed and as
> result we still run into stability issues. Those two issues combined
> are there reason there is now an experimental C++ branch.
>
> Wether we decide to move to C++ or not, I still think we need recreate
> the celix framework.
> What if forgot the mention in the previous mail is that in the C++
> registry all registration/unregistration and the starting/stopping of
> trackers are handled in registry and with use of ref counting & async
> calls (future) to prevent deadlocks in the framework; this is somewhat
> complex, but manageable. For the current celix implementation this
> partly done in the framework object, the service registry object and
> the service tracker object and this combined with (no ref count)
> handling of services references & service registrations and a lot of
> entanglement between those objects currently still leads to race
> condition / dead lock issues.
> This approach can also be done in C, but requires simple more lines of
> code ...
>
> With the updated C API I also started cutting out some
> concepts/complexity we IMO do not need (service references, bundle
> archive, bundle revision, module, service listeners, service listener
> hooks, framework listener), with the idea to eventually drop those
> concepts. These concepts are already dropped in the current C++
> framework implementation.
>
> So moving forward with C or C++ we should IMO (eventually) go for a
> 3.0 release with a more lean API, implementation and support for
> bundles as linkable shared objects.
> And this will lead to some stability issues, but for sure become a
> more stable and maintainable framework in the end.
>
> >
> > 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.
>
> Functionally I agree, but it does arguable result in less lines of
> code framework .. i.e. a better maintainability & productivity.
>
> > If you really want to continue this should not go into Celix but in a new
> > Apache project.
>
> I do not agree. Yes it would introduce back incompatibility changes,
> but that does not make it a different project.
>
> >
> > I am quite curious what the rest of the community thinks.
>
> Indeed...
>
> >
> > 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++?
>
> Code size I do not know, but is something we can measure.
>
> For performance I assume you mean the overhead of calling services?
> I have no metric for that .. although that would be nice.
>
> In my reasoning as long as you can still provide/consume pointers to C
> service structs (as with the current Celix framework) for C usage,
> there is no performance difference.
> And the goal of the C++ framework should be to still a) support a C
> API and b) support C service struct. So there should be no change.
>
> For C++ usage there will be the overhead of dereferencing the
> std::shared_ptr and overhead of accessing a std::function / pure
> abstract C++ interface (i.e. virtual method).
>
>
> > >
> > > Is there any plan to support other languages ( using language bindings
> ) ?
>
> A C API, conform the current updated (celix_* headers) C API, should
> IMO be added 'out of the box'. Any other languages you where thinking
> about?
>
> > >
> > > 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
> > >
>


-- 
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