220 34435 <69cdd486-c450-4ed9-a807-f8c5535103e2@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: leni536@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Copy eliding emplacement functions for containers. Date: Wed, 20 Sep 2017 03:23:45 -0700 (PDT) Lines: 303 Approved: news@gmane.org Message-ID: <69cdd486-c450-4ed9-a807-f8c5535103e2@isocpp.org> References: <0144b887-c694-4f3e-b368-32645a1562d9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_26_734800998.1505903025345" X-Trace: blaine.gmane.org 1505903026 1316 195.159.176.226 (20 Sep 2017 10:23:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 20 Sep 2017 10:23:46 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDXJR44QUQHBBMUDRHHAKGQEBNS6DIY@isocpp.org Wed Sep 20 12:23:41 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ducAO-0008TF-Fb for gclcip-std-proposals@m.gmane.org; Wed, 20 Sep 2017 12:23:40 +0200 Original-Received: by mail-pf0-f197.google.com with SMTP id p9sf873641pfd.15 for ; Wed, 20 Sep 2017 03:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=phFNjH+nX96TXpf0xS4HkpJbQpaDWEl1mIcwTAhZWVw=; b=o/2dnZk/4+eJlQ8sO7nKuCZ1SjuJslngQeERvfDipygjm6+egLYS529nBWZbBOoprD EqsM+aM5YG6asfTSdr7rQEC/A9yNeG+/wxgXRcIkRZVdrPGsUQ2GUa+S2RcJgPn6XxUY qSBKfSrsUT+pfKy62xyM7H3y2JorjpAwCZp8xAGJhrgpTDUQEhUrp3a1japllvsemFo8 bpJs94W4stsjucfotzB2FDJq7o2KvIXRdyf6ntBM9Tr7sgv4RjweMF3mdRnic5SFSxGw FhA9Z+M0hCSBZOXVsKWflhwy2+LLdJyhugri9igvBA6Jn4JgDDKopndhf1UPzTzDxZpy VBAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=phFNjH+nX96TXpf0xS4HkpJbQpaDWEl1mIcwTAhZWVw=; b=ZiNzb46v5fuBkUiuO3cckHXvOZRz8LhFKdVbPbwBBu6DDW3mqGwFhmm66wdv3yzYXS aKvbvVFMo65JJldKMjY2gMZCiurMM031EIYqvzFxe4X7RTcTESCmqSQWIh59mxiLlQ87 4G5zskL/pn2OB1q4dYrRjFwCsp90K1ca23dKGDd9NXivhyi+65lnM+6ECfBroSoLxIJS XjceFGXbdaUHd9q4s38Hwc2M9Jsa/pof6PHpaiqJ5ZGPIHBTaexTV6e1jOFbr4HAtpMA IjLM7ZtIzcESiUQrWn2E6OrQ5ljCV/t2Yc9GrMLJV/5m49gIBJ1MlgI6HpkXj5cOiFlN Z1cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=phFNjH+nX96TXpf0xS4HkpJbQpaDWEl1mIcwTAhZWVw=; b=TKW/0L8zmkBG40couAc56DqKOJgUZsp1YduJXj5lq6SM00b+zUMZW6uNuhMJlD0913 ki4wX7RMLhqDefkGh/StNfT5j9OXUcqNc3CBN2rZjjX1FigTLwZcrRRTna7slyRaISWu TiTcqpN9R1xcfNKZOGWZf1V+5yOtiGClvkRgmzyR4R2PKR2ZHSApZoyhMF+B8vVutXWC RCFA1CC0yE3abkalBTQaPhQpG5nc00Swt4qdm2CYls/OKBN/dT30VhJs85lUKfhDdvWs 8LWg0zuLGD3NcCqzT7pBh68vOUyB9VG97vM3RG1GWtmZ9De9cwWVN1V/WXIXN+oXno8Z OnXg== X-Gm-Message-State: AHPjjUh/svOdEDX4r+2WPEfeoY00y1x2xN1AZl8TAqBv7nQPxjkxmZ/O 5tkXgux6ieNbrkOn19SYIZ+xxQ== X-Google-Smtp-Source: AOwi7QBtArvE3wXggHLlrL4d+HWgxsD/YbLkMMk5xq+ctfL7jtBJOrwJTXUWsqsAmMzF+sEMxK5qlQ== X-Received: by 10.99.42.141 with SMTP id q135mr965165pgq.50.1505903027412; Wed, 20 Sep 2017 03:23:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.150.135 with SMTP id y129ls442864iod.32.gmail; Wed, 20 Sep 2017 03:23:46 -0700 (PDT) X-Received: by 10.31.48.2 with SMTP id w2mr17158vkw.2.1505903026008; Wed, 20 Sep 2017 03:23:46 -0700 (PDT) In-Reply-To: X-Original-Sender: leni536@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:34435 Archived-At: ------=_Part_26_734800998.1505903025345 Content-Type: multipart/alternative; boundary="----=_Part_27_1012542137.1505903025347" ------=_Part_27_1012542137.1505903025347 Content-Type: text/plain; charset="UTF-8" On Wednesday, September 20, 2017 at 10:34:13 AM UTC+2, Richard Smith wrote: > > On 19 September 2017 at 09:37, > wrote: > >> Hi, >> >> Guaranteed copy elision in C++17 is pretty great. This way I can simply >> return by value in my factory functions. Basically these factory functions >> act like external constructors (but not perfectly). >> >> #include >> extern widget factory(); >> >> int main() { >> auto w1 = widget{ factory() }; >> auto w2 = new widget{ factory() }; >> auto w3 = std::unique_ptr{new widget{ factory() }}; >> >> return 0; >> } >> >> Basically all three cases have guaranteed copy elision. It would be nice >> if we could put elements from these kind of factory functions into a >> container and eliding copying at the same time. Now the only interface for >> something like this is the emplace* family of functions, but they only work >> with constructors. I suggest a function with the following signature. >> >> //for vector >> template >> reference emplace_back_from_function(Func func, Args... args); >> >> The container then calls placement new inside somewhere: >> new(pos) value_type{ func(std::forward(args)...) }; >> Maybe allocators need an updated interface for it too as placement new >> through the indirection of allocator_traits::construct brakes guaranteed >> copy elision (I think). >> >> This way we could make collections of non-copyable and even non-movable >> types as guaranteed copy elision is allowed for these too. >> >> std::make_shared could have a std::make_shared_from_function counterpart >> too. Maybe there are other parts of the standard library that calls >> constructors of user specified types that could make advantage of this. >> >> Thoughts? >> > > The above design prevents guaranteed copy elision for arguments of 'func'. > Instead, there's an even simpler pattern: > > template > reference emplace_using(Func func); > > ... that simply does "new(pos) value_type(func());" to construct the > value. However, adding one of those per emplace function seems very > heavyweight; it would seem nicer to add a wrapper class template that could > be passed to ordinary emplace functions, eg: > > vec.emplace_back( emplace_using( [&]{ return factory_function(args); } ) ); > > where emplace_with is a type that wraps a function and implicitly calls it > when needed to convert to the return type of the function: > > template struct emplace_using { > Func func; > emplace_using(Func func) : func(std::move(func)) {} > operator decltype(auto)() { return func(); } > }; > This is really great. I was working on something similar but then I bumped into a compiler problem. Clang++ doesn't seem to do guaranteed copy elision when implicit conversion is involved. The following fails to compile on clang++ #include template struct emplace_using { Func func; emplace_using(Func func) : func(std::move(func)) {} operator decltype(auto)() { return func(); } }; struct A { A(const A&) = delete; A(A&&) = delete; }; A Afactory() { return A{}; } int main() { auto ptr = std::make_unique(emplace_using{[]() { return Afactory(); }}); } It complains about calling the deleted move constructor. However on g++ it compiles it without warnings. A similar problem occurs when the move constructor is explicitly delegated from an initializer list. Clang++ supposedly supports guaranteed copy elision and indeed it works for simple cases. > This almost works... the trouble is that perfect forwarding gets in the > way (unsurprisingly, since "perfect" forwarding is imperfect for prvalues). > allocator::construct will do > > new (loc) T(forward(arg)...) > > where we need the argument to the constructor to be a *prvalue* of type T. > Possibly we could modify the construction logic to use a mechanism that > acts like forward for most Ts, but invokes the wrapped function when T > is emplace_using. > I don't fully comprehend the problem described here, but I'm not too experienced with value categories and the quirks of not so perfect forwarding. Maybe some examples could help. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69cdd486-c450-4ed9-a807-f8c5535103e2%40isocpp.org. ------=_Part_27_1012542137.1505903025347 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, September 20, 2017 at 10:34:13 AM UTC+2, Ric= hard Smith wrote:
On 19 September 2017 at 09:37, <len...@gmail.com> wrote:
Hi,

Guaranteed copy elis= ion in C++17 is pretty great. This way I=20 can simply return by value in my factory functions. Basically these=20 factory functions act like external constructors (but not perfectly).
#include <memory>
extern widget factory();

int main= () {
=C2=A0 =C2=A0 auto w1 =3D widge= t{ factory() = };
=C2=A0 =C2=A0 auto w2 = =3D new widget{= factory() };
= =C2=A0 =C2=A0 auto w3 = =3D std::unique_ptr= <widget>{new widget{ factory() }};

=C2=A0 =C2=A0 return 0;
}=

Basicall= y all three cases have guaranteed copy elision. It would be nice if we=20 could put elements from these kind of factory functions into a container and eliding copying at the same time. Now the only interface for=20 something like this is the emplace* family of functions, but they only=20 work with constructors. I suggest a function with the following=20 signature.

<= span style=3D"color:rgb(136,0,0)">//for vector
template = <class Func,= class... Args>
reference emplace_back_f= rom_function(Func= func, Args... args);

The container then calls= placement new inside somewhere:
new(pos) v= alue_type{ func(std::forward<A= rgs>(args)...)= };
Maybe allocators need an updated interface for it too as placement new=20 through the indirection of allocator_traits::construct brakes guaranteed copy elision (I think).

This way we could make collections of=20 non-copyable and even non-movable types as guaranteed copy elision is=20 allowed for these too.

std::make_shared could have a=20 std::make_shared_from_function counterpart too. Maybe there are other=20 parts of the standard library that calls constructors of user specified=20 types that could make advantage of this.

Thoughts?

The above design prevents guaranteed copy elision = for arguments of 'func'. Instead, there's an even simpler patte= rn:

template<typename Func>
refere= nce emplace_using(Func func);

... that simply does= "new(pos) value_type(func());" to construct the value. However, = adding one of those per emplace function seems very heavyweight; it would s= eem nicer to add a wrapper class template that could be passed to ordinary = emplace functions, eg:

vec.emplace_back( emplace_u= sing( [&]{ return factory_function(args); } ) );

where emplace_with is a type that wraps a function and implicitly calls = it when needed to convert to the return type of the function:
template<typename Func> struct emplace_using {
=
=C2=A0 Func func;
=C2=A0 emplace_using(Func func) : func(std= ::move(func)) {}
=C2=A0 operator decltype(auto)() { return func()= ; }
};

<= div>This is really great. I was working on something similar but then I bum= ped into a compiler problem. Clang++ doesn't seem to do guaranteed copy= elision when implicit conversion is involved. The following fails to compi= le on clang++

#include <memory>

templ= ate <typename Func>
struct emplace_using {
=C2=A0=C2=A0=C2=A0 F= unc func;
=C2=A0=C2=A0=C2=A0 emplace_using(Func func) : func(std::move(f= unc)) {}
=C2=A0=C2=A0=C2=A0 operator decltype(auto)() { return func(); }=
};

struct A {
=C2=A0=C2=A0=C2=A0 A(const A&) =3D delete;<= br>=C2=A0=C2=A0=C2=A0 A(A&&) =3D delete;
};

A Afactory() = { return A{}; }

int main() {
=C2=A0=C2=A0=C2=A0 auto ptr =3D
= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 std::make_unique<A>(emplace_usi= ng{[]() { return Afactory(); }});
}

It c= omplains about calling the deleted move constructor. However on g++ it comp= iles it without warnings. A similar problem occurs when the move constructo= r is explicitly delegated from an initializer list. Clang++ supposedly supp= orts guaranteed copy elision and indeed it works for simple cases.
=C2=A0
This almost works... the trouble = is that perfect forwarding gets in the way (unsurprisingly, since "per= fect" forwarding is imperfect for prvalues). allocator::construct will= do

=C2=A0 new (loc) T(forward<Arg>(arg)...)=

where we need the argument to the constructor to = be a *prvalue* of type T. Possibly we could modify the construction logic t= o use a mechanism that acts like forward<T> for most Ts, but invokes = the wrapped function when T is emplace_using<Fn>.

I don't fully comprehend the probl= em described here, but I'm not too experienced with value categories an= d the quirks of not so perfect forwarding. Maybe some examples could help.<= /div>

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/69cdd486-c450-4ed9-a807-f8c5535103e2= %40isocpp.org.
------=_Part_27_1012542137.1505903025347-- ------=_Part_26_734800998.1505903025345-- .