From dev-return-1328-archive-asf-public=cust-asf.ponee.io@celix.apache.org Thu Jan 10 21:54:59 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 25A2B18062A for ; Thu, 10 Jan 2019 21:54:57 +0100 (CET) Received: (qmail 23438 invoked by uid 500); 10 Jan 2019 20:54:57 -0000 Mailing-List: contact dev-help@celix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@celix.apache.org Delivered-To: mailing list dev@celix.apache.org Received: (qmail 23426 invoked by uid 99); 10 Jan 2019 20:54:56 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Jan 2019 20:54:56 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 36282CC6D4 for ; Thu, 10 Jan 2019 20:54:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.143, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, KAM_LOTSOFHASH=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id ciixxhGACYbO for ; Thu, 10 Jan 2019 20:54:53 +0000 (UTC) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 54C7C5F3CE for ; Thu, 10 Jan 2019 20:54:53 +0000 (UTC) Received: by mail-it1-f182.google.com with SMTP id g76so796579itg.2 for ; Thu, 10 Jan 2019 12:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=kkrwVY/X+TsGdN+WFaalGEjg1fHgzB1sHUgv1MrMC4Y=; b=CrbQI8Ens9EdjPtElelQUKhHQzOMk6GBIgck9IiBNzrP8ZYy2nNudAJlUbfspuB7Fr ee8fPcrWUYtW+Nf7wV0uBskCy+XH9olQRB3+ER9riHy8s5Hdbo8lCvER3rSqcdkweEZW EnsHJE/IXf99yKzM3W62YfJC93UIq0JK0AryhnLSA2lcVWVoLwknt7KuaxhBwB1+PYhE Jty41f9hp8Pv6hbIhRX23iLZYafXiDRjxpXx19OxArRSaYxcSnr9dgxLZcSln1VnCrKA ciifiy10gtb8sQ0KAa9rkPTlDRv/x+NuubUC3HaJNDVONQD9gfdLZl0ZM3pkz0S708VU ja/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=kkrwVY/X+TsGdN+WFaalGEjg1fHgzB1sHUgv1MrMC4Y=; b=BeAbT7iE8fFsZLAB4jbMsns+4WHv7puNSA16EVC/1IZwB+W9XKJCGMln/J/K6wyQ6I TnOth5+2CZdPDpVyWF3rHJjz4EeIQEmyqlj8Wm/N0QBVtrNAQd01TVftOPof+TLxedOf IW45vPvqHXw1bSYWizO0uiee7IcWgXuHSuplPaBxUhrwWxCzycCv/EbG9q8rI8NKFiqO k7R0X4WZWj1VrAAits88v3I1qrvenbzAEK45qvKl5xu2oBtG5+6ESEdukkLfPOnoZnf0 eexX88Ki/KyYjAiH8VpxgTreWIBuhqlmP0ChxXXIoIqbdKdXzqPq8tTKs6vYRLtPSmM5 8Edw== X-Gm-Message-State: AJcUukeJBix3ULi0m3bpGLLVNa/VRmJV0+Yr+UA4xpPZtiRi8LBQrE7Q MN+SQnHuxNt1nVqGgRpT0la6L/FUq3E7P4jfuXenrLOn X-Google-Smtp-Source: ALg8bN5ApgKTTqo4LwW7+wsT2wM/YBAjonmcR1CRnFM/IQU2EG+N+bgYundrhIuv6sq3djew57sfKxzTEm6XRMELSP0= X-Received: by 2002:a24:9d1:: with SMTP id 200mr328742itm.53.1547153692320; Thu, 10 Jan 2019 12:54:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pepijn Noltes Date: Thu, 10 Jan 2019 21:54:41 +0100 Message-ID: Subject: Re: [DISCUSS] C++ Celix Framework To: dev@celix.apache.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 9, 2019 at 3:39 PM Gabriele Ricciardi 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 surel= y > give more visibility to the project and also give more opportunities to t= he > end developers for choosing Celix as base framework for their application= s. > 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 li= fe > 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, ha= s > 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 wi= th > 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 tr= y > 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 harde= r > to code (of course, benefits should always outweigh or at least balance t= he > 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 th= e > 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=C4=8D < > miroslav.beranic@mibesis.si> ha scritto: > > > Hi all, > > > > I've started working with Celix back at 2015. At that time, I as "all a= bout > > 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 solutio= ns > > implemented in C that at that time I thought "only possible in C++". Wi= th > > 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 o= n > > 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 langu= age > > 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 no= t > > 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 jo= b is > > around Apache Karaf, Camel, JMS, ... enterprise integration; but more a= nd > > 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 ha= s. > > And it would make ( financially ) no real benefit -- no one will approv= e > > 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 stab= le > > ). > > @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 frame= work > > language. > > The biggest challenges would be how and if those bundles can share serv= ices > > written in different language. So cpp pure abstract class as service us= ed > > 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 Arduin= o, > > Android, RaspberryPI ( Yocto project ) and WebAssembly ( all about movi= ng > > data from one end to another using ASN.1 ). To me C is holy grail. It d= oes > > 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 co= de. > > I agree also, this is possible also because I do not know all the lates= t > > bells and whistles from C++. To me C++ is like moving target. It is mod= ern > > 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 Celi= x" > > as this is reality. I also agree this should be Celix community, not so= me > > outside community. I would also argue that there should be only C and o= nly > > 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 shou= ld > > 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 t= hat > > 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 langua= ge, > > but hey ... ), Rust, Dart, Java. I guess most of this can be solved wit= h > > 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 Pytho= n, > > > > To close this one: Go with C or C++, but do not mix. If core needs to b= e > > updated it would be nice if it could be done in C ( in existing code ba= se > > ). 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 go= als > > 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 miss= ing? > > > > 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 > > > 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 recreat= e > > > 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 somewha= t > > > 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 o= f > > > 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=C4=8D < > > > > 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 f= ocus > > > 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 us= e > > and > > > > > > hopefully also easier to develop/maintain framework. > > > > > > b) More type safe > > > > > > c) RAII; which really helps a lot in dealing with volatile serv= ices > > > > > > and trying to keep track of which services are still in use. > > > > > > b) C++ is simply more relevant and popular, which should help i= n > > > > > > 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 improve= ment > > > > > > for Celix or any remarks on the Celix C++ framework implementat= ion. > > > > > > > > > > > > There are a few interesting changes in the approach/design of t= he > > C++ > > > > > > framework: > > > > > > 1) There is a separate (static) Registry library [2], which > > delivers > > > > > > the functionality to register/use/track (and TODO listener hook= s) > > > > > > 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 servic= e > > > 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 sam= e > > > > > > 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 m= ake > > 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 agains= t > > > 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 fil= es > > 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 executa= ble > > > > > > "just" has to link against the bundle shared objects to make th= em > > > > > > 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 nee= ded > > (I > > > > > > never use it myself). I also think that this should be solved b= y > > 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 t= he > > > > > > 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 cl= ean > > > > > > 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 late= r. > > > > > > > > > > > > [1] feature/cxx branch (for the 807b88 .. commit): > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc= 60584f > > > > > > [2] registry dir: > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc= 60584f/libs/registry > > > > > > [3] > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc= 60584f/libs/framework_cxx > > > > > > [4] > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc= 60584f/examples/celix-examples/cxx_shell_example > > > > > > [5] > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc= 60584f/bundles/shell/cxx_shell > > > > > > [6] > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc= 60584f/bundles/shell/cxx_shell_tui > > > > > > > > > > > > > > > > > > Greetings, > > > > > > Pepijn > > > > > > > > > > > > > > > > > > > > > -- > > > > > Miroslav Berani=C4=8D > > > > > MIBESIS > > > > > +386(0)40/814-843 > > > > > miroslav.beranic@mibesis.si > > > > > https://www.mibesis.si > > > > > > > > > > > > > > -- > > Miroslav Berani=C4=8D > > MIBESIS > > +386(0)40/814-843 > > miroslav.beranic@mibesis.si > > https://www.mibesis.si > >