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 <jensge...@hotmail.com>
To:     "dev@thrift.apache.org" <dev@thrift.apache.org>, 
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: dev@thrift.apache.org
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: 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)
> > > >>
> > >
> > >
> > >
> > >
> > >
> >
>




Reply via email to