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