[
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165787#comment-14165787
]
Konrad Grochowski commented on THRIFT-2717:
-------------------------------------------
I know I said we should leave discussion until something is really ready, but I
think I came out with some sort of compromise and I would like to store that
idea somewhere :)
Rationale: I can live with 'v2', just '2' looks awfully strange for me. Adding
"v2" as option to existing generator would be confusing, as different other
options would be available depending on that option.
So, my idea:
{{--gen cpp.v1}} - current, renamed
{{--gen cpp.v2}} - newly developed
{{--gen cpp}} - defaults to v1 but generates warning that will soon
switch/disappear
this should bring focus to "which cpp version is used", yet keeps "cpp" name
more or less untouched.
In future library could be renamed in the same way (as either subdirs cpp/v1
and cpp/v2 or dirs with . in name)
One problem I see now: I'm developing v2 generator in a way it can work with v1
lib. So when v2 lib comes v2 generator will have to get option like "v1
compatible". Or we start develop v2 lib as soon as possible and change v2 gen
now to create code for v2 lib. But developing whole v2 lib may be a little to
much for me alone.
> 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)
