[
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157484#comment-14157484
]
Randy Abernethy commented on THRIFT-2717:
-----------------------------------------
Hey Konrad,
First, if you finish it cheers will go up no matter what.
On 1, as long as the compiler builds on Cpp98 (without user intervention) I
think that addresses the concern. We just need to make it clear that the rest
of us not working on the Cpp11 gen need to stay in cave man mode for a couple
years.
On 2, I think that requiring Boost just to supply boost::optional is a trade
which will amortize negatively. It is a slippery slope. Why not just create a
local implementation of boost::optional (thrift::optional, I know where you can
get the source ;-). Then we can can swap it when optional arrives in Cpp, and
we never opened the Boost door. Some C++11 shops don't use Boost. Are we going
to deny them this awesome new feature because of Boost::optional?
As serendipity might have it, I am, right this moment, trying to build the
current trunk with the Vagrantfile but the make check is failing due to missing
libboost-system-dev, etc... It is a slippery slope.
> 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)
