+1 for C++11 on master and for upcoming releases

Quoting Chet Murthy <murthy.c...@gmail.com>:

I would be happy to port tests from boost-test to googletest -- and in the
process, we could arrange for running tests in parallel, e.g. the
cross-test.  I've found that googetest is much more ..... helpful for
debugging.  I'd also vote for (in the C++ code) putting in glog support,
for similar reasons.

On Fri, Dec 22, 2017 at 6:41 PM, Ben Craig <ben.cr...@gmail.com> wrote:

The main source of work on the Thrift side will be porting the tests.  Many
of them are based on boost test right now.

I'm generally fine with the idea, just be aware that this is a breaking
change, though the break will often be easily dealt with by users
(replacing std with boost).

If you want to be super nice to our users, you could provide a #define to
switch between boost:: and std::.

On Fri, Dec 22, 2017 at 3:14 PM, James E. King, III <jk...@apache.org>
wrote:

> A pull request was submitted recently that is a work in progress to move
> away from Boost.  This is something the team has expressed a desire for
in
> the past (although as a maintainer of two boost libraries it makes me
sad!)
> as will will reduce project dependencies.
>
> https://github.com/apache/thrift/pull/1448
>
> This work would be GREATLY simplified if we came to a decision to name
> 0.11.0 as the last version that will support C++03, and the next release
> will require C++11 and would not use boost in generated or library code.
> I'm not sure I would be okay with such a decision, but I'm floating the
> idea out there for general comment from anyone and everyone.
>
> This would probably force people up to gcc-4.8 or gcc-4.9 at a minimum on
> Unix, not sure which version of clang (maybe 3.4?), and I believe we
might
> need to require Visual Studio 2013 or later, depending on how much C++11
we
> use it could go up to 2015.
>
> Libraries in Boost could be quite useful in the future, for example
> boost::asio and boost::beast.  If we disconnect from boost completely
then
> we would not have access to these.  I suppose we could make them optional
> servers or transports that would need to be enabled at build time, and if
> enabled at build time would require boost, so perhaps I'm just being
> paranoid there.
>
> Thanks,
>
> Jim
>



Reply via email to