What about mingw?
________________________________
Von: Roger Meier
Gesendet: 18.03.2015 00:44
An: Randy Abernethy (JIRA); dev@thrift.apache.org
Betreff: [DISCUSS] let's switch to C++11 (was Re: [jira] [Commented]
(THRIFT-3043) go compiler generator uses non C++98 code)
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)
>
