[ https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161613#comment-14161613 ]
Jens Geyer commented on THRIFT-2717: ------------------------------------ {quote} Another idea: current - renamed to c++98 new - just c++ --gen cpp option kept as an alias to --gen c++98 but will issue warning and be removed in some unspecified future and will not be listed in help as available {quote} +1 We should test however on Windows before, the {{++}} signs are not strictly illegal in folder names, but smell very much like problems lurking. {quote} The avoid confused users: add this information to lib/cpp/README.md and lib/c++/README.md {quote} [If you have to explain it, it is bad design|http://www.amazon.com/The-Design-Everyday-Things-Expanded/dp/0465050654]. Furthermore, 80% [will not read the README|http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html] and complain anyway. Having it documented is still a good idea, I just would not rely on it too much. > 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: > * code compatible with old librart (at least for first tests, new lib and > compiler switches can be added later) > * 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)