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 Fri, 11 Jan 2019 21:09:35 GMT
Hi,

I am not against C++, just because of the language. I am just questioning -
what are the benefits. Is it worth the effort, put into it. I guess a
relevant benchmark/metric data would make such decision easier.

I am mostly comparing Celix to Karaf, but I would have to compare it
against Felix, I guess. As far as I know, even Karaf/Felix was once one
project, that broke into separate projects, each with a dedicated
focus/goal.

For Karaf I know few big companies that use Karaf in their product lineup,
and as such I know what are the design goals, what are the focus areas.
With Celix I do not have such a clear picture.

With that said. What I meant with additional features was ( and I guess
some are not "core" Celix features ) things like: support for group package
deployment, like Feature in Karaf - list of bundles with dependencies and
dedicated repository for dependencies. For Celix it would be really neat if
apt/yum repositories could be re-used ( I guess there are other, newer
package managers out there, but most of my work is around RHEL 7.5/8 and
Ubuntu Linux ). Again, as I do not know the goal/focus for Celix, I do not
know if appropriate or not, but things like Cellar would be awesome to have
- where one could easily distribute package deployment among nodes. Out of
the box support for REST queries for deployed bundles and "simple"
deployment/management API. Support for bundles in other language - for
example, write Java class / bundle with activator ( support for Java-based
OSGi spec ) and wire into Celix - use other/exiting services. In my design
I would implement such solution in connection with ASN.1 description of the
interfaces ( or some other "low level" data protocol ) - something like (
or exactly like ) FastWebservices (Defined in ITU-T X.892 | ISO/IEC 24824-2
). I guess, this would not be really performance best job, as no one can
avoid JNI penalty, but if someone needs it - it can benefit from it. One
other thing is to make it compile/run on as many hardware/OS platforms as
possible and promote the solution to projects like HEMS, SmartGrid, energy
trading platforms, etc ( this are the fields I know, so I guess other
related could also benefit ). Nowadays all sort of such solutions are
written in PHP, Java, C#, JS or what ever new language someone thinks out
this days.

Celix is like core of the "module platform", but I guess core is OK, but
project needs ecosystem around it, that builds on top of the
benefits/features provided. My goal for sure is to "grow" Celix in a path
like "big boys", for example as Karaf. I know I am "mixing projects" a bit,
but pure OSGi implementation is not usable on its own -- it needs usecases
and provide solid solutions/alternatives. In my early PoC projects, for
same functionality I can outperform Karaf-based solution for around 100x --
in the same time Celix/C can serve 100x more clients or 100x more packages,
but to be able to compete all the surrounding ecosystem needs to exist (
integrated deployment, integrated clustering, integrated etc ). As it is
now, it is not cost effective to go in that direction, no one will approve
such a route.

I am sure someone needed Celix and at that time, there must be some "goal
roadmap", what is the purpose to build Celix. I guess it was not for fun to
implement OSGi in C. No one can have so much time, to have fun, I guess C
is one of the last languages someone picks to make things modular and
dynamically deployable in runtime ( I was referring to application
landscape, not kernel modules etc).

Other thing is, that I did not have Celix application running for non-stop
over long period of time in production. So I can not really comment on
stability, but for what I was testing it was working quite stable and did
not run into any crash - from Celix, it crashed from inside one of my
bundles. I did not even dive deep into Celix, I did at the begging, but not
ever since. I guess over time, every project has heavy weights that could
be cut out.

But this is thread related to C++, so I went out of the topic focus. So my
"final" comment on the subject is: if C++ based implementation has benefits
and has similar or better characteristics compared to existing code base I
am all for it, but to me C is really fun language, that if treated with
love in can do whatever new-age language can do.

And not to forget: existing work is really nicely put together and congrats
to all the authors.

Kind Regards,
Miroslav




V V čet., 10. jan. 2019 ob 21:54 je oseba Pepijn Noltes <
pepijnnoltes@gmail.com> napisala:

> On Wed, Jan 9, 2019 at 3:39 PM Gabriele Ricciardi
> <lele.ricciardi@gmail.com> wrote:
> >
> > Hi all,
> >
> > as for many things, in my opinion there are many pros and cons in moving
> to
> > a C++ implementation of the framework.
> >
> > I discussed the subject with Pepijn already few times, and he has many
> > points: C++ is a popular language, and offering support for it will
> surely
> > give more visibility to the project and also give more opportunities to
> the
> > end developers for choosing Celix as base framework for their
> applications.
> > I can agree on some technical arguments like type safety and smaller/more
> > compact code base that may increase the maintainability.
> > I also understand that using some of the modern C++ construct can make
> life
> > easier when it's about implementing core parts of the framework.
> > Moreover, I also think that introducing C++ support may open new horizons
> > for "pure" C programmers (like me).
> >
> > I'm not really concerned about the possible stability issues we may
> > encounter, Celix got pretty stable in the last few years and I don't see
> a
> > reason why a different implementation can't reach the actual level of
> > stability (or even better).
> >
> > What concerns me a bit more is the possibility of eventually dropping the
> > support for C: of course the current implementation should (or better,
> has
> > to) improve, but honestly I think that arguments like RAII and error
> > handling are not sufficient to justify such a swift direction change.
> >
> > As Miroslav pointed out, C is a bit more verbose but is also very stable
> > throughout years, the code is (in my opinion) more readable and, if well
> > written, it is portable and not really error-prone: basically, I agree
> with
> > C being a "holy grail" and as developer I would always like to have the
> > opportunity to play that card.
> >
> > For those reasons I think that moving and concentrating only on C++ and
> > just provide a "(mostly) backwards compatibility C API" (for eventually
> > phasing it out) would be a real pity.
> >
> > In my opinion, support for C and C++ should get the same attention and
> try
> > to provide (as far as allowed by the specific language) the same
> > functionalities: in the end, I don't see a problem in keeping up with two
> > implementations, even if one will be a bit more verbose or slightly
> harder
> > to code (of course, benefits should always outweigh or at least balance
> the
> > efforts, so if a new feature is easy to implement in C++ and nearly
> > impossible to implement in C... well, it will be unsupported for C).
> >
> > On the contrary, I do see the benefits of keeping up with two
> > implementations: we can really provide a flexible framework that gives
> the
> > end developer the possibility to choose what he thinks it' better for him
> > and his application. Of course it will require a bit more effort on our
> > side, but I see it as a good opportunity to bring Celix to the next
> level.
>
> I have not though about maintaining a C and C++ version and my first
> reaction is that we should not do this, but
> to be honest I have to think about this.
>
>
> >
> >
> > Kind regards,
> >
> > Gabriele
> >
> > Il giorno mer 9 gen 2019 alle ore 09:29 Miroslav Beranič <
> > miroslav.beranic@mibesis.si> ha scritto:
> >
> > > 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?
>
> Well said and I agree with this - especially, because you also quoting
> me... ;).
> Specifically the fast movement of C++ language - although that also
> has it benefits - is indeed a real concern.
> This combined with the idea that C++ is a "expert friendly" language,
> creates a risk that the code can become "old" quickly and as result
> inverse the maintainability.
>
> I also still think that C is the more clean and elegant language and
> that it is also the common nominator to expand to other languages.
> The thing is, that the common nominator part can be done by providing
> a C API from a C++ implementation and maybe I see this incorrect, but
> I do think the combination (with effort) of C/C++ is feasible.
>
> When I started working on the C++ implementation I was quite surprised
> at the progress I was able to make (and for that reason, I probably
> took this experiment to far before discussing this) and
> combining this with ability to create a more concise user API and the
> popularity of C++ is the reason I think we should really consider
> this.
>
> To be clear If the general consensus it that we should keep the focus
> on C I have no problem with. I enjoy writing code in C and I also
> agree with Gabriele that - if done well - C delivers very readable
> code (it just requires lots of lines of codes .. ).
> My point is that the goal of Celix is what we as community make of it
> and to keep Celix relevant I have no problem changing this when needed
> (e.g. more or less strict on OSGi or implemented in C or C++).
>
>
> > >
> > > 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).
>
> No worries. I did not think it was rude and I am actually happy with
> the feedback/comments.
> And metrics would indeed be welcome, but is just something we have not
> put effort in.
>
> > >
> > > 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.
>
> Ok thanks, I was just curious. I know there has been no real progress
> on other languages  - well except C++ ;) -, but this is something I
> still really would like.
> There is btw hopefully a window on my "day job" to pursue support for
> Python,
>
> > >
> > > 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 ).
>
> Good point. I still think that the current core framework in not good
> enough yet and as result are still focusing on refactoring the
> implementation and API of the Celix framework.
> But are there any specific features/functionalities you think Celix is
> missing?
>
> > >
> > > 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
> > >
>


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