Boost logo

Boost :

Subject: Re: [boost] Visual Studio 2015 Update 3 has removed std::unary_function and std::binary_function
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-11-05 23:56:17


On 11/5/2016 10:52 PM, Marshall Clow wrote:
> On Sat, Nov 5, 2016 at 5:38 PM, Edward Diener <eldiener_at_[hidden]>
> wrote:
>
>> On 11/5/2016 3:21 PM, 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.
>>>
>>
>> What do you mean by "define the typedefs everywhere" ?
>>
>
> Everywhere we derive from std::unary_function or std::binary_function,
> manually define "result_type", "first_argument_type", etc.
>
> Like this:
>
> Change:
>
> template<typename T>
> struct plus: binary_function<T, T, T>
> {
> T operator() (const T& x, const T& y) { return x + y }
> };
>
> to:
>
> template<typename T>
> struct plus
> {
> typedef T first_argument_type;
> typedef T second_argument_type;
> typedef T result_type;
> T operator() (const T& x, const T& y) { return x + y }
> };

Thanks ! Sounds like the obvious choice.

>
>
> -- Marshall


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