Boost logo

Boost :

Subject: Re: [boost] Visual Studio 2015 Update 3 has removed std::unary_function and std::binary_function
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-11-05 17:01:17


On 11/05/16 22:21, Marshall Clow wrote:
> ... if you build with /std:c++latest.
>
> See https://svn.boost.org/trac/boost/ticket/12586 for an example.
>
> Other vendors will be removing these types in C++17 mode in the future (or
> at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that)
>
> A quick grep for these terms found 153 instances of "std::unary_function"
> and 118 of "std::binary_function" across several libraries, including
> accumulators, algorithm, config, container, function, gil, graph, icl, mpi,
> msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered,
> utility - and probably others.
>
> I think that we ought to have a boost-wide solution for this (i.e, everyone
> should solve this the same way).
>
> I can think of three possibilities:
> * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation.
> * Since std::unary|binary_function is an empty struct with a set of two (or
> three) typedefs, just define the typedefs everywhere. Note that the
> typedefs (result_type, first_argument_type, second_argument_type) were
> deemed to not be useful in C++17 due to the existence of advanced type
> traits, etc.
> * Define a boost:unary_function and boost::binary_function struct that
> mimics the one that was in namespace std, and change over to use that.
> * Something else.
>
> Comments?

I'm in favor of replacing the structs with typedefs (i.e. option #2).
Although I suspect there are quite a few unmaintained libraries in the
list, so we need someone with wide push permissions. If we agree on this
approach I'm willing to do this for the libraries I have push rights to
(Utility from the list above). For others I can only create PRs.

TR1 could require a special approach, since it is supposed to implement
TR1, and it does have std::unary|binary_function. Maybe, this particular
library should implement those types when they are not available.

I also suspect we won't make the switch all at once, so at least 1.63
may get released with those classes still being used. It would be nice
to mention that in the release notes and say that one has to do -D
RETAIN_REMOVED_STUFF=1 or whatever for now.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk