Our company policy is to follow Microsoft with regard to supported Windows
versions, and we made good experiences with that approach.
That means to deprecate and mentally prepare to drop WinXP in near future. It
does not imply taking any action immediately, but as soon as WinXP
compatibility hinders us in any way it's time to drop it.
Have fun,
JensG
----- Ursprüngliche Nachricht -----
Von: Ben Craig
Gesendet: 18.03.2015 21:22
An: dev@thrift.apache.org
Betreff: Re: AW: [DISCUSS] let's switch to C++11 (was Re: [jira] [Commented]
(THRIFT-3043) go compiler generator uses non C++98 code)
I am interested in seeing a more complete proposal. I think that this
could lead to a more useful declaration of platform support.
Here are some of the questions that need to be answered:
What compilers will be supported for the thrift compiler?
Mostly unanswered so far, but hints at supporting anything
reasonably C++98 / C++03 compliant.
What compilers will be supported for the C++ library?
GCC answer seems to be 4.7+, with the --std=c++11.
No current answer for Clang / XCode or MSVC.
What OSes will be supported for the C++ library? This is closely related
to the compiler support, as it isn't very nice to claim support for an OS
where you can't get a supported compiler.
Linux OSes with gcc 4.7 support...
CentOS / RHEL 7
Debian 7.0+ (Wheezy) +
Suse 12.2 +
Ubuntu 12.10+ (quantal)
Ubuntu 14.04+ LTS (trusty)
Implicitly NOT SUPPORTED
CentOS / RHEL 6 (gcc 4.4)
Ubuntu 12.04 LTS (precise) (gcc 4.6)
Which OSX, iOS and Android versions?
Which Windows versions? Is Thrift going to drop WinXP?
What will be done about the boost dependency?
Are we going to have a migration path away from boost, or is there
going to be a clean break?
From: Roger Meier <ro...@bufferoverflow.ch>
To: dev@thrift.apache.org,
Date: 03/18/2015 05:28 AM
Subject: Re: AW: [DISCUSS] let's switch to C++11 (was Re: [jira]
[Commented] (THRIFT-3043) go compiler generator uses non C++98 code)
I just installed latest mingw for Windows from
http://sourceforge.net/projects/mingw-w64/
gcc.exe --version
gcc.exe (i686-posix-dwarf-rev1, Built by MinGW-W64 project) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
and on Debian Jessie we have gcc 4.9.1
see https://packages.debian.org/jessie/g++-mingw-w64-x86-64
Quoting Jens Geyer <jensge...@hotmail.com>:
> 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)
>>
