[
https://issues.apache.org/jira/browse/THRIFT-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161819#comment-14161819
]
Konrad Grochowski commented on THRIFT-2717:
-------------------------------------------
[~jensg] thanks for those links - that exactly what I has in mind. We need to
do as much as possible to avoid users confusion, even if it means to force them
(explicitly, not by some note at the end of some file) to do a little work at
some point.
As for {{++}} in Windows - just double checked it, {{#include "c++/test.h"}}
works in MSVC2012 :)
[~henrique] thanks for pointing that discussion. As far as I understood it -
default values for optionals has to be set, if user want to optimize something
it has to clear optional. I like that (if I was present in mentioned discussion
I'd side with Ben ;) ). So that means that current cpp generator does
'something in the middle'. I'll just assign defaults to optionals for now, and
wait for possible {{=?}} evolution :)
> 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)
