Is this discussion about compiler or/and cpp library ? When speaking of the compiler code, it should not be much of a problem to drop old compilers, because it's not linked to users' code.
I believe ongoing serious consideration is for cpp lib and generated C++ code. It is definitely mandatory for fbthrift merge and IMO benefit would be huge. Even their cpp (not cpp2) has many useful features that are not merged. I think there's at least 3 ways to start C++11 on cpp and generated C++. A: 0.x.x branch for c++98 and 1.x.x for c++11 It would seem really strange for all the other languages than cpp. B. Drop some versions of compilers on next release or after 0.9.3 Assuming you cannot drop VC++ even for a while, VC++ can be a constant source of headaches. C++11 of VC++ is not really for OSS cross-platform development. If a patch contributor doesn't have Windows, and when valid C++11 code doesn't compile for VC++ due to, say, initializer_list "partial" support, it's tricky to work around. Another example is rvalue reference "partial" support. VC++2013 doesn't generate default move constructor/assignment operator while only supports move semantics. Consequence of this is, in its ideal cases, explicit move constructors and assignment operators surrounded by "#ifdef _MSC_VER". In a worse case, a good performance improvement patch turns into performance regression on Windows. C. the separate cpp_v2 directory idea Here's my two cents. * Every current user is covered * C++ standard compliant * VC++ 2015 or 2017 or I don't know will be added to cpp_v2 support list later * Great for fbthrift merge and starting cost is arguably low On Sat, Mar 21, 2015 at 1:35 AM, Ben Craig <[email protected]> wrote: > Here is a useful poll from the wxwidgets team from a few months back: > http://wxwidgets.blogspot.com/2014/08/msvs-versions-poll-results.html > > I know that current Thrift doesn't work with VC6 or VC7, and I don't think > it works with VC8. I believe Thrift currently works with VC9 though (it > has in the recent past at least). VC6-VC8 account for 6% of that chart. > VC9 is 16.6%. If we required VC12 / Visual Studio 2013, we would go from > supporting 94% of Windows devs to supporting 38.8% of Windows devs. > > Now, those numbers are a bit out of date (Aug 16, 2014), and we can't be > shackled by the users that hang back forever. Also, the wxWidgets Windows > user base may not be representative of the Thrift Windows user base. 94% > to 38.8% is still a really steep drop-off though. If we only require > VC10, then we still support 77.3% of Windows devs. We don't get a whole > lot of C++11 for that upgrade though, and what we get isn't actually > standards compliant. > > > > From: Jens Geyer <[email protected]> > To: "[email protected]" <[email protected]>, > Date: 03/20/2015 03:12 AM > Subject: AW: AW: [DISCUSS] let's switch to C++11 (was Re: [jira] > [Commented] (THRIFT-3043) go compiler generator uses non C++98 code) > > > > Forget it ... maybe I should read everything before I start to answer. It > was of course 2013 > ________________________________ > Von: Jens Geyer > Gesendet: 20.03.2015 09:09 > An: [email protected] > Betreff: AW: AW: [DISCUSS] let's switch to C++11 (was Re: [jira] > [Commented] (THRIFT-3043) go compiler generator uses non C++98 code) > > I compiled the compiler with Visual Studio and had no problems? > ________________________________ > Von: Ben Craig > Gesendet: 19.03.2015 17:46 > An: [email protected] > Cc: Jake Farrell > 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 didn't mention this in my last post, but one of the other troubles with > C++11 is figuring out which subset of C++11, and effectively communicating > that information. Suppose we support gcc 4.7+ and Visual Studio 2012+. > Visual Studio 2012 doesn't support braced initialization. It doesn't > support non-static data member initialization in class declarations. Both > of those features were used in THRIFT-3043. > > Now, those features are supported in Visual Studio 2013... but VS 2013 had > really nasty bugs involving braced initialization and non-static data > member initialization. > > > http://blogs.msdn.com/b/vcblog/archive/2014/06/09/bugs-fixed-in-the-spring-update.aspx > > > http://blogs.msdn.com/b/vcblog/archive/2014/08/04/bugs-fixed-in-visual-studio-2013-update-3.aspx > > > This is one of the reasons we need to know all the compilers we will > support, instead of just hand-waving around the problem. > > > From: Randy Abernethy <[email protected]> > To: Jake Farrell <[email protected]>, [email protected], > Date: 03/19/2015 11: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) > > > > +1 for Ubuntu 14.04 docker as reference platform > On Mar 19, 2015 9:15 AM, "Jake Farrell" <[email protected]> wrote: > > > The Vagrantfile was created initially to be a copy of what jenkins had > and > > mirrored our system test env. My goal with the Dockerfiles has been to > > create just that, a set env that is guaranteed to build and test from. > The > > Ubuntu Dockerfile is what will be used on jenkins soon for the main > system > > and should be considered the reference platform. I'm working on fixing > the > > couple issues raised in THRIFT-3042 for the containers now > > > > -Jake > > > > On Thu, Mar 19, 2015 at 12:00 PM, Randy Abernethy < > > [email protected] > > > wrote: > > > > > I think Jens makes a good point +1. We need to clearly communicate > this > > > stuff, this should be front page news on the web site with a plan and > > > milestones when a consensus develops. > > > > > > I also think we should deal with Cpp for users (lib/cpp and generator > > > output) separate from the compiler source (compiler/cpp/src). They are > > not > > > really linked. The compiler just happens to be written in Cpp. It > could > > > just as easily (and might have been better) written in C. There are > many > > > people who use Apache Thrift who don't care at all about C++, using > > thrift > > > to build systems with Java, Node, Python, etc. I would be ok with > > changing > > > the compiler source language to Cpp11 if there was a benefit. Is > there? > > > Perhaps pulling from fbthrift is motivation. Would like to hear what > > others > > > think. All of the compiler patches I have reverted to Cpp98 in the > last > > > year have been fairly trivial and easily changed to C++98 (again > > > communications either way cpp98 or cpp11 needs to be clear). > > > > > > I also think this would be a good juncture to clearly communicate a > > > reference platform. We would like to build everywhere but we need to > > start > > > by building somewhere. We need a repeatable way all Committers/Users > can > > > build/test the platform such that when it doesn't build on that > platform > > > everyone agrees there is a problem to address as a blocker. This will > > make > > > Jenkins and other CI actually meaningful. This is the #1 productivity > > > change in practice we could make in my view. > > > > > > > > > On Thu, Mar 19, 2015 at 1:13 AM, Jens Geyer <[email protected]> > > wrote: > > > > > > > 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: [email protected] > > > > 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 <[email protected]> > > > > To: [email protected], > > > > 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 <[email protected]>: > > > > > > > > > What about mingw? > > > > > ________________________________ > > > > > Von: Roger Meier > > > > > Gesendet: 18.03.2015 00:44 > > > > > An: Randy Abernethy (JIRA); [email protected] > > > > > 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) > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
