[PATCH] D36049: [Resubmitted] Remove uses of deprecated std::unary_function, binary_function, and pointer_to_unary_function.

Brent Lewis via llvm-commits llvm-commits at lists.llvm.org
Sat Aug 12 12:17:52 PDT 2017


This was authored to address CMake build failure in Visual C++ 2017 with
/std:c++latest.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Aug 8, 2017 at 4:39 PM, Justin Bogner <mail at justinbogner.com> wrote:

> David Blaikie <dblaikie at gmail.com> writes:
> > On Thu, Aug 3, 2017 at 11:23 AM Justin Bogner via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> >
> >> David Blaikie via Phabricator <reviews at reviews.llvm.org> writes:
> >> > dblaikie added inline comments.
> >> >
> >> > ================
> >> > Comment at: include/llvm/ADT/STLExtras.h:61-62
> >> > +struct identity {
> >> > +  using argument_type = Ty;
> >> > +  using result_type = Ty;
> >> > +
> >> > ----------------
> >> > Should these changes be adding all these typedefs? I assume the reason
> >> > std::unary_function et. al. are deprecated is that callers should
> >> > likely be using decltype & similar things to work here instead?
> >>
> >> IIUC the intent of deprecating these wasn't to get rid of the typedefs,
> >> but instead to discourage things from saying they operate specifically
> >> on a unary_function. Ie, it's better if some algorithm depends (in a
> >> SFINAE way) on the type defining an argument_type and result_type rather
> >> than on the type being isa-unary_function.
> >>
> >
> > Got a reference? That would seem somewhat surprising to me.
>
> I can't seem to find where I got this from. Maybe I misremembered or
> made it up.
>
> > All the things in the standard library that used to derive from
> > std::binary_function, etc, no longer do so and do not provide the
> typedefs.
> > So any adapter we have that depends on the typedef is not going to work
> > with the standard ones (std::plus<T> - to take a simple example) - nor
> any
> > others likely to be written in the future. The typedefs as a means to
> > interoperate with functors seems to have been removed/deprecated - so it
> > doesn't look to me like removing the type but keeping the typedefs
> achieves
> > so much of the point the standard was making of removing the types.
>
> Interestingly, while std::unary_function and friends were deprecated in
> C++11, the typedefs were not deprecated then. It's only C++17 that
> deprecates the typedefs (and also removes the function binder classes).
> So uses that depend on the typedefs will certainly work in any standard
> up to and including C++17 (even for std::plus), but not necessarily in
> future standards.
>
> TLDR, I agree that it looks like they're removing the typedefs
> completely going forward, and it makes sense for us to follow suit.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170812/6705adfb/attachment.html>


More information about the llvm-commits mailing list