[ 
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162028#comment-14162028
 ] 

Randy Abernethy commented on THRIFT-2717:
-----------------------------------------

I think it is important to keep in mind that we are talking about a new Thrift 
C + + API. The fact that C + + 11 will be used (and maybe c + + 14/17/etc.) is 
anecdotal. What matters is that old code will break because we are changing the 
Thrift API. v2 seems pretty natural given this line of thought. 

Anything with a "+" in it would get a strong -1 from me. Non alpha numeric 
characters are problematic in many environments. Even C + + doesn't use them. 
For example the macro __cplusplus, which incidentally has only two legal values 
presently: 199711L and 201103L,  v1 and v2. 

We also need to make sure that Thrift c + + v1 and v2 can run concurrently in 
the same environment. It should therefore be easy to have libthrift.so and 
libthrift2.so (or some such) on the same system without headaches. The names of 
the libs should be easy to predict, making v2 a nice fit.

> 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)

Reply via email to