I compiled the compiler with Visual Studio and had no problems? ________________________________ Von: Ben Craig Gesendet: 19.03.2015 17:46 An: dev@thrift.apache.org 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 <randy.aberne...@gmail.com> To: Jake Farrell <jfarr...@apache.org>, dev@thrift.apache.org, 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" <jfarr...@apache.org> 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 < > randy.aberne...@gmail.com > > 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 <jensge...@hotmail.com> > 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: 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) > > > >> > > > > > > > > > > > > > > > > > >
