[
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161215#comment-14161215
]
Konrad Grochowski commented on THRIFT-2717:
-------------------------------------------
Yes, but nobody is using cpp2 as a name ;) (especially that some count c\+\+01
as standard)
I was not proposing changing what --gen cpp does but to remove it completely
(or mark deprecated). Because if we now add any suffix to cpp then we'll have
to add more and more, make it cpp14 or cpp3 or cpp17.
By removing --gen cpp I mean only command line option - compiler should be
kept, but it now reserves good name forcing future version too look as "not
default". Considering that C\+\+ is now moving forward we should make space for
that.
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
> 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)
