+1As you may remember I was working on C++11/cpp_v2 gen/lib - https://github.com/hcorg/thrift/tree/cpp_v2 yet I had to put it on a hiatus some time ago... Maybe next month I'll find some time to finish it (I think I was pretty close to 0.0.1 version of complete generator ;) )
-KG W dniu 2015-03-18 o 01:05, Jake Farrell pisze:
+1 Thoughts on cutting the 0.9.3 release so we do not have a long delay between releases again and put this in for a 0.9.4 or we could stop the point releases and go with 1.0 with full c++11, cmake, py3.0, etc. -Jake On Tue, Mar 17, 2015 at 7:41 PM, Roger Meier <ro...@bufferoverflow.ch> wrote:Hi all We had lot of discussions and issues about C++11 support and I think it is time to move the master branch development towards C++11 and set this as a dependency starting wit 0.9.3 of Apache Thrift. reasons to move forward: - no feature show stopper due to C++98 dependency - no backport of patches, it's a nightmare - master branch should focus towards future - evolution of compiler and cpp library - many developers already use C++11 capable compilers - http://cpprocks.com/c11-compiler-support-shootout- visual-studio-gcc-clang-intel/ - gcc support -std=c++11 since version 4.7 see https://gcc.gnu.org/projects/cxx0x.html - clang 3.5 - all recent Linux distros support C++11 - centos 7 uses gcc 4.8.2 - Debian Jessie uses gcc 4.9.2 - Debian Wheezy uses gcc 4.7.2 - RHEL-7.0 uses gcc 4.8.2 - Suse 13.2 uses gcc 4.8.3 - Suse 13.1 uses gcc 4.8.1 - Ubuntu utopic 14.10 uses gcc 4.9.1 - Ubuntu trusty 14.04 LTS uses gcc 4.8.2 - Ubuntu saucy 13.10 uses gcc 4.8.1 - it is 2015 and C++11 is ready to use in the wild - C++11 compilers can easy be installed on older distros - no fork of a C++11 library solution for older environments: - C++98 can be handled on the 0.9.x branch if required - install a more recent compiler - http://www.necessaryandsufficient.net/2014/07/c11-on-centos/ What do you think? all the best! -roger On 17.03.2015 03:49, Randy Abernethy (JIRA) wrote:[ https://issues.apache.org/jira/browse/THRIFT-3043?page= com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel&focusedCommentId=14364464#comment-14364464 ] Randy Abernethy commented on THRIFT-3043: ----------------------------------------- Hey Jens: looks good, many thanks! Hey Roger: I agree, we definitely need a Cpp11 generator and lib ASAP. The only thing I am suggesting is that we keep the IDL compiler source Cpp98 until Cpp11 is ubiquitous. My hope is that we can fork the Cpp98 lib to create a Cpp11 lib and fork the Cpp98 generator to create a Cpp11 generator (which would be written in Cpp98). This way folks can use Cpp11 or Cpp98 in their user code. I think this was the plan arrived at on some other threads. The THeader pull from DJW (https://github.com/apache/ thrift/pull/357.patch) is all lib so should apply fine to a Cpp11 lib fork. The IDL compiler is pretty simple and has no bearing on user code. The path of least resistance there seems to be to keep the source for the IDL compiler in Cpp98. That way it will compile under Cpp11 or Cpp98. Win win. Rewriting the compiler in Cpp11 (or Java or Go) does not seem like a good use of our time and we have precious little of it (as you pointed out on the THeader issue). Most of the Cpp98 breaking patches are due to unsupported variable initialization and the like, seems silly to cut off a large chunk of compatibility we already have in place for trivial stuff like that. go compiler generator uses non C++98 code----------------------------------------- Key: THRIFT-3043 URL: https://issues.apache.org/jira/browse/THRIFT-3043 Project: Thrift Issue Type: Bug Components: Go - Compiler Affects Versions: 0.9.3 Reporter: Randy Abernethy Assignee: Jens Geyer Priority: Blocker Fix For: 0.9.3 Attachments: THRIFT-3043-go-compiler- generator-uses-non-C-98-code.patch go compiler generator uses non C++98 code causing builds to fail in Centos 6 and other environments. ==> default: src/generate/t_go_generator.cc:415: error: in C++98 ���commonInitialisms��� must be initialized by constructor, not by ���{...}��� ==> default: src/generate/t_go_generator.cc:415: error: deducing from brace-enclosed initializer list requires #include <initializer_list> ==> default: src/generate/t_go_generator.cc:415: error: deducing from brace-enclosed initializer list requires #include <initializer_list> ==> default: src/generate/t_go_generator.cc:415: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x ==> default: src/generate/t_go_generator.cc:415: error: no matching function for call to ���std::set<std::basic_string<char, std::char_traits<char>, s td::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std: :char_traits<char>, std::allocator<char> > > >::set(<brace-enclosed initializer list>)��� ==> default: /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../ include/c++/4.4.7/bits/stl_set.h:188: note: candidates are: std::set<_Key, _Compare, _ Alloc>::set(const std::set<_Key, _Compare, _Alloc>&) [with _Key = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, _Compare = s td::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, _Alloc = std::allocator<std::basic_string<char, std::char_traits<ch ar>, std::allocator<char> > >] ==> default: /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../ include/c++/4.4.7/bits/stl_set.h:136: note: std::set<_Key, _Compare, _ Alloc>::set() [with _Key = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, _Compare = std::less<std::basic_string<char, std::c har_traits<char>, std::allocator<char> > >, _Alloc = std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >] ==> default: make[3]: *** [thrift-t_go_generator.o] Error 1 ==> default: make[3]: Leaving directory `/thrift/compiler/cpp' ==> default: make[2]: *** [all] Error 2-- This message was sent by Atlassian JIRA (v6.3.4#6332)
