I notice that U have merged the branch. So, where exactly should we start?
> 在 2016年1月13日，上午1:55，Konrad Grochowski <[email protected]> 写道： > > Hey Tomas, > > I'll try to merge/rebase it against master and include recent changes in c++ > lib into c++ v2 lib, probably this weekend (I hope I'll find some time). > > As for C++11 - quick answer: because then at some point Thrift would have to > introduce std17 or std14 etc :) > Long answer - when I started my branch there was some discussion which lead > to following - Thrift should have one C++ library for "the best of modern > C++", which should be updated along with new compilers, new language and > library features etc. This library should be named cpp v2 to not mix with any > current new versions of C++ standard, as we want Thrift to be able to make > this library compatible with current newest standard, be it std11 or std23. > At some point this library should become standard (--gen cpp) and most new > users should be happy. Current c++ library should be kept as "most common > subset of C++ compilers features" library, to enable Thrift on some older or > outdated environments. As for keeping multiple libs for cpp11, cpp14, cpp17 > etc - it would just add too big maintenance cost to Thrift. > > Best regards, > Konrad > > W dniu 2016-01-12 o 17:24, 刘畅 pisze: >> Dear Konrad, >> >> It’s exciting to see the effort here. >> >> I’ve checked your branch and it’s really a little out of date. >> >> Why not merge the modification lately and let’s plan it out together? >> >> as for the generator, is it nice to call it cpp_v2? why not just use cpp >> version instead? >> >> such as “—gen cpp_std11 ” >> >> Best regard, >> >> Tomas >> >>> 在 2016年1月12日，下午5:37，Konrad Grochowski <[email protected]> 写道： >>> >>> Hey All, >>> >>> Few thoughts from previous discussion about C++ >= 11: >>> - we have to keep old C++ lib (at least for a while) as C++11 lib would >>> break iface compatibility >>> - to avoid confusion at some point we agreed to use cpp_v2 name for new >>> lib, so no user would ask "What is C++2?" (it's not perfect solution, still >>> at least it's some solution). Current C++ lib should be renamed to cpp_v1, >>> and "--gen cpp" should be an alias for cpp_v1, and later (1.0? 1.1? 2.0?) >>> changed to cpp_v2 (keeping v1 for backward compatibility) >>> >>> As for my branch: >>> - it is probably a little bit outdated (haven't merged or rebased it for a >>> while) >>> - does not include CMake build files >>> - Contains full copy of cpp_v1 lib, but with std::shared_ptr and >>> std::thread instead of boost counterparts (boost usage is reduced >>> significantly). >>> - Optional fields are now using boost::optional (we need to check - maybe >>> some compilers already support C++17 std::optional, so we could switch to >>> that - C++17 will probably be released, before cpp_v2 become standard :) ) >>> - I've simplified ThreadManager, but it's not tested >>> - while writing compiler I stopped at generating Processors and I think >>> that's the last thing that is missing. >>> >>> Best regards, >>> Konrad >>> >>> W dniu 2016-01-12 o 00:12, Roger Meier pisze: >>>> Yes Randy, that's it! >>>> >>>> I just found another issue about std::shared_ptr >>>> https://issues.apache.org/jira/browse/THRIFT-2221 >>>> >>>> We can easily switch to boost-less code generation in place within the >>>> compiler by using the new, modular and testable code from Konrad and >>>> fine tune the C++ library for bare metal systems via CMake. >>>> >>>> good afternoon, good evening, and good night! >>>> -roger >>>> >>>> PS: good morning ;-) >>>> >>>> Quoting Randy Abernethy <[email protected]>: >>>> >>>>> Most boost usage in Thrift is header based. The C++ lib "API" today uses >>>>> boost::shared_ptr liberally and there are lots of other small incursions. >>>>> While the elegance of Boost is uncontested, it is another dependency and >>>>> as >>>>> far as the Thrift C++ lib is concerned, it is redundant in the context of >>>>> C++ >= 11. There are also boost thread bits which are lib based. Again you >>>>> can work around this stuff but it is much easier, and at no cost of >>>>> functionality, to just use C++11 these days. >>>>> >>>>> >>>>> >>>>> On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <[email protected]> >>>>> wrote: >>>>> >>>>>> Just out of interest, what's the nature of Thrift's dependency on Boost? >>>>>> >>>>>> My recollection (also from embedded systems), is that *much* (but not >>>>>> all) of Boost doesn't cause any real library dependencies because so >>>>>> much of the Boost code is provided in full as template in header files >>>>>> (i.e. it does not necessarily generate linker dependencies on boost >>>>>> libraries). >>>>>> >>>>>> Is this the case for Thrift's use of boost? Does it require some >>>>>> linking against a boost library -- and could that dependency be cut? >>>>>> >>>>>> - Stu >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy >>>>>> <[email protected]> wrote: >>>>>>> Hey Roger, >>>>>>> >>>>>>> I agree with the goal. However I think the easiest way to start is with >>>>>>> a >>>>>>> new base (--gen cpp2). In this way we can get something in place for >>>>>> those >>>>>>> who need it now and then we can excommunicate the old lib whenever the >>>>>>> community is ok with it. The changes contemplated break the API, not >>>>>>> something we can just do to the old C++ lib without harming a lot of >>>>>> folks. >>>>>>> -Randy >>>>>>> >>>>>>> On Mon, Jan 11, 2016 at 12:04 PM, Roger Meier <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all >>>>>>>> >>>>>>>> I think we should rework the existing cpp towards modern C++ to awoid a >>>>>>>> second lib and generator to maintain. >>>>>>>> >>>>>>>> The cpp_v2 branch from Konrad is a great place to start, the >>>>>>>> modularization and testability is awesome! >>>>>>>> As we decided to base on modern C++ such as C++11, I would like to >>>>>>>> replace the existing ccp lib and generator instead of adding another >>>>>> one. >>>>>>>> I guess this might also enable Thrift on bare metal with C++ compilers. >>>>>>>> >>>>>>>> best! >>>>>>>> -roger >>>>>>>> >>>>>>>> >>>>>>>> Quoting Konrad Grochowski <[email protected]>: >>>>>>>> >>>>>>>> Hi Randy, >>>>>>>>> Do you think we could somehow merge our cpp2 efforts? ( >>>>>>>>> https://github.com/hcorg/thrift/tree/cpp_v2) >>>>>>>>> It's my old branch, had to put it on little hiatus, yet I think some >>>>>>>>> parts of it could be useful. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Konrad >>>>>>>>> >>>>>>>>> W dniu 11.01.2016 o 20:16, Randy Abernethy pisze: >>>>>>>>> >>>>>>>>>> Hi Dane and Tomas, >>>>>>>>>> >>>>>>>>>> Great to hear we have a few people willing to pull the oars. I'll get >>>>>> our >>>>>>>>>> cpp2 lib sanitized this week and post a jira/patch in a few days. >>>>>> Then we >>>>>>>>>> can take it from there. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Randy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jan 11, 2016 at 11:14 AM, Dane Mason <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hey Randy, >>>>>>>>>>> That sounds perfect for our use case. I would love to contribute. >>>>>> Let me >>>>>>>>>>> know when you have more details. >>>>>>>>>>> >>>>>>>>>>> Dane >>>>>>>>>>> >>>>>>>>>>> On Sun, Jan 10, 2016 at 9:44 AM, Randy Abernethy < >>>>>>>>>>> [email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hey Dane, >>>>>>>>>>>> My shop has a C++11 (no boost) language implementation for thrift. >>>>>> We >>>>>>>>>>> have >>>>>>>>>>> >>>>>>>>>>>> only built out the generator (--gen cpp2) TBinaryProtocol, >>>>>>>>>>>> TCompactProtocol, framing and basic socket transports. I have tried >>>>>> to >>>>>>>>>>> get >>>>>>>>>>> >>>>>>>>>>>> some help cleaning this up for public consumption but so far no >>>>>> takers. >>>>>>>>>>>> Also other quarters have threatened to post such a code base which >>>>>> has >>>>>>>>>>>> caused us to hold off (don't want multiple versions of this stuff >>>>>>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>> trunk). If you are willing to contribute I'll try to package things >>>>>> up >>>>>>>>>>> for >>>>>>>>>>> >>>>>>>>>>>> a commit this week so that we can get the community to pitch in and >>>>>>>>>>>> >>>>>>>>>>> finish >>>>>>>>>>> >>>>>>>>>>>> off a basic C++11 lib. Should work great for your purposes (which >>>>>>>>>>>> is >>>>>>>>>>>> exactly what we use it for). >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Randy >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jan 9, 2016 at 6:20 PM, Dane Mason <[email protected]> >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry I should have been more clear. C++ is fine, but the boost >>>>>>>>>>>> dependency >>>>>>>>>>>> >>>>>>>>>>>>> is problematic. >>>>>>>>>>>>> >>>>>>>>>>>>> Dane >>>>>>>>>>>>> >>>>>>>>>>>>> On Saturday, January 9, 2016, Randy Abernethy < >>>>>>>>>>>>> >>>>>>>>>>>> [email protected] >>>>>>>>>>>> wrote: >>>>>>>>>>>>> Do you need a C impel or can you use C++11 on the embedded sys? >>>>>>>>>>>>>> On Saturday, January 9, 2016, Dane Mason <[email protected] >>>>>>>>>>>>>> <javascript:;>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, I'm part of a project that makes heavy use of Thrift and it's >>>>>>>>>>>>>> RPC >>>>>>>>>>>> functionality across Java, C++, and Python. This project now needs >>>>>>>>>>>>>> to >>>>>>>>>>>> incorporate an embedded component with 256kb ram running on a >>>>>>>>>>>>>> CortexM3. >>>>>>>>>>>>> After a bit of research, I've decided that there is no straight >>>>>>>>>>>>>> forward >>>>>>>>>>>>> way >>>>>>>>>>>>>>> of using Thrift in this context out of the box. We are not >>>>>> willing >>>>>>>>>>>>>> to >>>>>>>>>>>> bring >>>>>>>>>>>>>>> GLib in as a dependency, nor are we willing to use C++ and >>>>>>>>>>>>>>> Boost. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> What >>>>>>>>>>>>> we >>>>>>>>>>>>> >>>>>>>>>>>>>> simply need is a way to reuse the binary protocol and most >>>>>>>>>>>>>> importantly, >>>>>>>>>>>>> the >>>>>>>>>>>>>>> IDL used throughout the rest of the project. We are using many >>>>>>>>>>>>>>> >>>>>>>>>>>>>> large >>>>>>>>>>>> structs, so maintaining 4 hand written implementations across our 4 >>>>>>>>>>>>>>> languages doesn't make sense. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some solutions I've considered: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Manually write code serialize and deserialize the thrift >>>>>> binary >>>>>>>>>>>>>>> protocol. >>>>>>>>>>>>>>> - We are dealing with many large structs, and ensuring >>>>>> correctness >>>>>>>>>>>>>> of >>>>>>>>>>>> this >>>>>>>>>>>>>>> handwritten code is tedious and error prone. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Use a JSON protocol and use existing JSON parsers on the C >>>>>> side. >>>>>>>>>>>>>>> - Again error prone, may not be performant enough for our use >>>>>> case. >>>>>>>>>>>>>>> 3. *Possibly *create something like a "TFlatBufferProtocol" (or >>>>>>>>>>>>>>> >>>>>>>>>>>>>> any >>>>>>>>>>>> other >>>>>>>>>>>>>>> Serialization format with an IDL) >>>>>>>>>>>>>>> - I haven't looked into this in depth, it seems messy and hard >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> >>>>>>>>>>>>>> maintain. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'd appreciate any advice you all have to offer here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Dane >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> --- >>>>>>>>> Ta wiadomość została sprawdzona na obecność wirusów przez >>>>>> oprogramowanie >>>>>>>>> antywirusowe Avast. >>>>>>>>> https://www.avast.com/antivirus >>>>>>>>> >>>>>>>> >>>>>>>> >>>> >
