[ https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143816#comment-14143816 ]
Konrad Grochowski commented on THRIFT-2717: ------------------------------------------- as for 'genuine value': * boost::optional is much more convenient to use that _ _ issets _ _ * _ _ issets _ _ violate C++ standard (all identifiers starting with double underscore should be reserved for internal compiler use) * move semantics is more natural than returning via reference * currently generated headers include a lot from thrift, when they shouldn't. in my last job we've created whole 'translation' framework just to detach from thrift generated types and their headers. * unit tests for all parts of generator. many generator parts could be reused in other generators. as for boost vs. std - I'll double check what is available where. I know that folks asks for complete removal of boost, to ease build environment setup. Still - a lot of people use boost and keeping it, even as just an option, would allow bigger audience to use C++11 generator. When new generator is ready converting library to '"c++11 and boost free" should be next natural step, but I do not think that making all changes at one is a good idea. Using new generator with old library will be a great test for new generator. With TDD approach and a lot of tests adding a switch to use std instead of boost (or other way around) will be quite easy. > C++11 generator > --------------- > > Key: THRIFT-2717 > URL: https://issues.apache.org/jira/browse/THRIFT-2717 > Project: Thrift > Issue Type: New Feature > Components: C++ - Compiler > Reporter: Konrad Grochowski > > instead of adding another set of options to 'old' cpp generator I've started > creating new one in: > https://github.com/hcorg/thrift/tree/cpp11_generator > using old as an reference > main goals: > * no more ugly {{__isset}} structure -> boost::optional for optional values > * as a result - no more {{__}} in names, which violates C++ standard > * all generation code will have own unit tests (TDD used wherever possible) > * generated types headers independent from Thrift header, to allow other > layers of application using generated types without dependency leaks > * each type will generate own header/cpp file - easier for user to include > only used parts. > * unordered map/sets > * returning using move semantics, no more ugly 'return via output parameter' > (still possible as option thou - sometimes it's needed for performance) > * async client using boost::future > * enum classes > * initializer lists for constants (maybe) > I'm aiming in C++11 subset available in gcc 4.8 and MSVC 2013 > currently I have only complete enum generation, but work is in progress > all comments etc are very welcome :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)