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