C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::construct<T>

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Mon, 2 Dec 2024 10:26:57 +0000
On Sun, 1 Dec 2024 at 19:00, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Would it be affected by the design decision of retiring niebloids?
>
> P3136
>
> https://github.com/cplusplus/papers/issues/1790
>

No, because what Avi showed below is not a niebloid, it's just a function
object. Niebloids are the strange "might be a magical function template or
it might not be" things previously used for specifying constrained algos
such as std::ranges::copy. What has been retired is the "maybe a function
template and maybe not" property. Using function objects (or customization
point objects) to implement operations such as "swap" or "copy" or Avi's
proposed "construct" has not been retired.



>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Avi Kivity via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* So 01.12.2024 19:43
> *Betreff:* Re: [std-proposals] std::construct<T>
> *An:* Andrey Semashev <andrey.semashev_at_[hidden]>;
> std-proposals_at_[hidden];
> *CC:* Avi Kivity <avi_at_[hidden]>;
> On Sun, 2024-12-01 at 21:25 +0300, Andrey Semashev wrote:
> > On December 1, 2024 7:57:45 PM Avi Kivity <avi_at_[hidden]> wrote:
> >
> > > On Sun, 2024-12-01 at 19:11 +0300, Andrey Semashev via Std-
> > > Proposals
> > > wrote:
> > > > On December 1, 2024 6:57:16 PM Avi Kivity via Std-Proposals
> > > > <std-proposals_at_[hidden]> wrote:
> > > >
> > > > > Functions and member functions are invocable, but constructors
> > > > > are
> > > > > not.
> > > > >
> > > > > I propose to add
> > > > >
> > > > > template <typename T, typename... Args>
> > > > > T std::construct(Args&&... args) {
> > > > > return T(std::forward<decltype(Args)>(args)...);
> > > > > }
> > > > >
> > > > > With this, we can pass a constructor where other functions can
> > > > > be
> > > > > passed.
> > > > >
> > > > > // build a callback that creates and returns a Type1 thing
> > > > > std::function<Type1 (Arg3)> make_somthing =
> > > > > std::bind_front(std::construct<Type1>, arg1, std::ref(arg2));
> > > > >
> > > > > // transform a vector of ints to a vector of some other type
> > > > > auto foo = some_container |
> > > > > std::views::transform(std::construct<AnotherType>) |
> > > > > std::ranges::to<std::vector>();
> > > >
> > > > Binding a function pointer is less efficient than a function
> > > > object.
> > >
> > > Typically, inlining will remove the difference.
> >
> > The function pointer must still increase the size of the binder,
> > which may
> > make it too large to fit in e. g. std::function small buffer.
> >
> > And whether the compiler is able to devirtualize the call is more of
> > a
> > question than with a function object with an inline operator().
> >
> > > Or we can make it a
> > > niebloid.
> >
> > Sorry, I don't know what this means.
> >
>
>
> A technique used in std::ranges to avoid such pointers-to-functions.
>
> template <typename T>
> struct _Impl_construct
> template <typename... Args>
> static T operator()(Args... args) { return
> T(std::forward<Args>(args)...); }
> };
>
> template <typename T>
> inline _Impl_construct construct;
>
>
> > >
> > >
> > > > And
> > > > given that lambdas are an easy way to create function objects, I
> > > > don't
> > > > really see the benefits of the proposal.
> > >
> > >
> > > I believe that writing
> > >
> > > std::views::transform(std::construct<AnotherType>)
> > >
> > > is more readable than
> > >
> > > std::views::transform([] (auto&& x) { return
> > > AnotherType<std::forward<decltype(x)>(x); });
> >
> > I think this is not equivalent to the original example. Is
> > AnotherType a
> > template?
> >
>
>
> I mistyped, sorry.
>
>
> std::views::transform([] (auto&& x) { return
> AnotherType(std::forward<decltype(x)>(x)); });
>
>
> The intent is to construct an object of type AnotherType using a single
> parameter of unknown type.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2024-12-02 10:28:15