[
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157442#comment-14157442
]
Konrad Grochowski edited comment on THRIFT-2717 at 10/2/14 11:49 PM:
---------------------------------------------------------------------
1. Is there a point in generating C\+\+11 code if it can't be build on given
machine? I think that --gen cpp11 option should be added if compiler's compiler
also supports cpp11. It should be detected at './configure' time. Those who
don't care about C\+\+ version will not gonna notice, those who care will be
able to switch it on after providing proper compiler. I'm not gonna lie: this
opinion is driven by fact, that I already have some lines of C\+\+11 generator
and it uses C\+\+11, a lot ;)
2. I'm trying, but... xxx::optional. It's a great leap forward from __isset,
but std::optional didn't make it to C\+\+14. So I had to stick with
boost::optional. Yet currently it is the only thing used from boost. Also -
places where generated code communicates with current C++ library will use
boost, but I hope to make that a compiler switch when we'll start with new C++
lib. At least I kept compiler code boost free (except for tests), so it still
should be easy to build it on different machines. I was considering unique_ptrs
for optional values, but that just wrong... So we'll have to stick with boost
a little bit more
was (Author: hcorg):
1. Is there a point in generating C++11 code if it can't be build on given
machine? I think that --gen cpp11 option should be added if compiler's compiler
also supports cpp11. It should be detected at './configure' time. Those who
don't care about C++ version will not gonna notice, those who care will be able
to switch it on after providing proper compiler. I'm not gonna lie: this
opinion is driven by fact, that I already have some lines of C++11 generator
and it uses C++11, a lot ;)
2. I'm trying, but... xxx::optional. It's a great leap forward from __isset,
but std::optional didn't make it to C++14. So I had to stick with
boost::optional. Yet currently it is the only thing used from boost. Also -
places where generated code communicates with current C++ library will use
boost, but I hope to make that a compiler switch when we'll start with new C++
lib. At least I kept compiler code boost free (except for tests), so it still
should be easy to build it on different machines. I was considering unique_ptrs
for optional values, but that just wrong... So we'll have to stick with boost
a little bit more
> 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)
