220 34431 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Copy eliding emplacement functions for containers. Date: Wed, 20 Sep 2017 01:33:49 -0700 Lines: 274 Approved: news@gmane.org Message-ID: 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/alternative; boundary="001a11c034a6f4905b05599ad672" X-Trace: blaine.gmane.org 1505896452 14219 195.159.176.226 (20 Sep 2017 08:34:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 20 Sep 2017 08:34:12 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBBA6QRDHAKGQE4DPZWWY@isocpp.org Wed Sep 20 10:34:07 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duaSL-0003Nn-4j for gclcip-std-proposals@m.gmane.org; Wed, 20 Sep 2017 10:34:05 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id c82sf300240lfc.13 for ; Wed, 20 Sep 2017 01:34:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1505896452; cv=pass; d=google.com; s=arc-20160816; b=Rwo8cUxeNpz9bTvI1cYnA+4oF24TjfYRIajBS44rzlXO9XaWrmuJ2ijjLbIvunRCCL YIdaw7wuJVMOPYLkszUfpsp/1164KbdjlD61mdsbd7oigWXOndpbDrwsAbU2tD/PGa6d Bkf4op+8d7l4UiLOrcxiKqx/DjmE+AZ+RxonGpizxypUXceD/v79/Jk4isHvZYvqqYBH ekAPlVn/wXWV2MMjnxI/Rn9xZcMnmxkoRVCSUrUwHJ4etserH0YevORskxZijA0Ks3e8 ziXgJJXNqLjTxnn3CxCoaeOHHbPisueghagZL/hEAgnVBUy36vXnRuzBFHUUaSNLb2xo M4Sw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=No0ahfEjqwyL6xfTEbkazaBHAWfeWK4ninyuYo9VHGo=; b=t15c2nC2Fz4tITR0UNS0qa6uElmau+HnowxtkAKX9l3QUErKE+yIuBQz7NTyAiu3Kg UeJb/uBMTvkBUjGKSzqSBRUTDAfMIsW1aEAYDRkyPC17oGfyxmfUurmJd/XZroWUz19T Ezwx1CGoJQL4u9qeUR4DzoMnahIPjVls+b7PsD87RO463i2fGDBUegb9r7OslIK7hXbD 1omcbYRYL/2CI/x1tMabbhx1N/4MCVPG64qx262LF5TDpADLEcdNg4tbzGtD+fY51hz/ Rm5zB+WUttCP2shtX64frKaiIKng9/apdXrodLiBqb+6mLHiQM+VteEV3hADbS8vskgU YyLg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=a+/gZVsr; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=No0ahfEjqwyL6xfTEbkazaBHAWfeWK4ninyuYo9VHGo=; b=pSvuxWyQdxxRNevjIB8qN2AQeTeCN2t8FcqSdMv5mD3f271rNuS0kJr6yAbDBNo78w kWWF94ACOdnCLjWyAFvryXsv7EqBFR2u+n9tZ3Njv5Snb1mTqCQgQymCsM2+BvD/shzR czRlTuv7oFBSisCaPE/doUatrBQoZc8MGEkQoYIbXixk4CnZ1wFA4LZ8BBFzjb9EDmMh HH1zhxMq+nKwLfJOOnsTLeQxKcQmRbqu4+zpvUfoONCaixesIgtVo90c5DPQRbTIXaU7 vW+jzP57S2yqNm6WNz35I06snYY4sKcnL8k5PZimL7OPnmhelOqyDkeBNECpnOu5FYNc FKPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=No0ahfEjqwyL6xfTEbkazaBHAWfeWK4ninyuYo9VHGo=; b=qNQFFiCVgEfcEhdl4U9L55LgCgs2HEs/m4yTdBJTYooqZE50uBtCG0YNY2c5bYXxnZ 3sYJ/e4LeofuuPiDuSyhjQgqm0vuPuVKqOA9ZzGpB5csTLjVw6XBxzPYH8kAC5iO7rXD ISw7JHBX8BcKyAxkZhRdjkC+jXzCQRyotGgMDyPI/GO35uZxVWuwTM/OLSTB5ZBHyooT FcDvInQBvx6+3qR1fFitvoLDPc6vS8eCS6J1My1utwV7Q/SSMzAIRl318Uz47mv6f/PL 5iOSm09hR2QKgqcj0vP/bhuhorElzwziMbGX2819mRaelQ/XE3FDiJx8VKjK6/ZIGCQF Tq1Q== X-Gm-Message-State: AHPjjUhFKvcv5DHGqb4iiSvaGS1OicnFZ7DPyRtguWinQaHo741azaMb 7YMZock0GeQ6Jf9WX7CbxJekiQ== X-Google-Smtp-Source: AOwi7QCAPpAQxsBGErWwLyuTwyqRs12wKaCTyDsvaI3eb/kxUfCADOtudL6F0EK8NhCA5G8Knc+vsQ== X-Received: by 10.25.78.196 with SMTP id u65mr128377lfk.4.1505896452758; Wed, 20 Sep 2017 01:34:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.31.138 with SMTP id f132ls303165wmf.14.canary-gmail; Wed, 20 Sep 2017 01:34:11 -0700 (PDT) X-Received: by 10.223.169.247 with SMTP id b110mr575365wrd.31.1505896451205; Wed, 20 Sep 2017 01:34:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505896451; cv=none; d=google.com; s=arc-20160816; b=Ufaz+NdxGhXTeqfOK8/rQiEhPt/mSaMhf9hipDNT7KItbscyZ2veFu5sUtMK31gOo9 1OHo5mhjcJBWy8Mc6LjXuETObsTLgjkqMVyuRNxRjXLlfwOUWX+FQ6l0drmd48Ze3GjQ 6NhqPlN6yHApoKhFjxc8Jtjat5km1+VJwl7qST9+hTkLm+oEXBEZ6giPgeJ7Aa80Lri6 GeDK1qL/V4U1r1ZlRd5lgprhhc05dILr892y6UJbd855V2xyiWBebnTOcCaGpqImDrsY U9cav6fcEi/eMwjOPlflinDX1eu0fZgUiTzZYgXzG/vsn2yive311NwYCzZKy8bSXvHF AYvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=GmgLJQejMVaJUKWAUUnQqxh7QeS89gJypTORMyGCQwA=; b=Vp3zVL4cjf1AMWjyXRk/6OTyYfgnDCnTetnGdjWi/4Fdt+10HxRVf6I6Jgi5MR1UFJ KuHh4Sd7J2Za/0m+pbB+poEII3uYdS5yigc0w3BEyJX2/O6gqIvUiQxwc9+8Sdpp8i6t tsOH1dh+St+vexzFcu8WXJWMuF8ljXeA/sqS1vhxmnSZRTWd8vlafKURZfXYj4upijnZ sdn5GI+45JpvG8UFvAMpCb6sbcmDXI3X2vzknldPm0K9O1fpUxprcBgUgIn9elpWVwGC 6PFsZiLZuTBNP3/PYo5AcoSmMpg1U4JFWMxV8zhQOPW3cI0vVIZSmpJgxAEboJmlWb1A /dIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=a+/gZVsr; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk Original-Received: from uk12.easy-internet.co.uk (uk12.easy-internet.co.uk. [81.27.85.19]) by mx.google.com with ESMTPS id q13si1054867wre.6.2017.09.20.01.34.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 01:34:11 -0700 (PDT) Received-SPF: neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) client-ip=81.27.85.19; Original-Received: from mail-oi0-f42.google.com ([209.85.218.42]:46897) by uk12.easy-internet.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1duaSQ-0006sX-B8 for std-proposals@isocpp.org; Wed, 20 Sep 2017 09:34:10 +0100 Original-Received: by mail-oi0-f42.google.com with SMTP id a74so1566630oib.3 for ; Wed, 20 Sep 2017 01:34:10 -0700 (PDT) X-Received: by 10.202.232.205 with SMTP id f196mr4787398oih.218.1505896449738; Wed, 20 Sep 2017 01:34:09 -0700 (PDT) Original-Received: by 10.74.91.133 with HTTP; Wed, 20 Sep 2017 01:33:49 -0700 (PDT) In-Reply-To: <0144b887-c694-4f3e-b368-32645a1562d9@isocpp.org> X-Gmail-Original-Message-ID: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - uk12.easy-internet.co.uk X-AntiAbuse: Original Domain - isocpp.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - metafoo.co.uk X-Get-Message-Sender-Via: uk12.easy-internet.co.uk: authenticated_id: metafooc/from_h X-Authenticated-Sender: uk12.easy-internet.co.uk: richard@metafoo.co.uk X-Source: X-Source-Args: X-Source-Dir: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=a+/gZVsr; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk 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:34431 Archived-At: --001a11c034a6f4905b05599ad672 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 function= s > act like external constructors (but not perfectly). > > #include > extern widget factory(); > > int main() { > auto w1 =3D widget{ factory() }; > auto w2 =3D new widget{ factory() }; > auto w3 =3D 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 fo= r > something like this is the emplace* family of functions, but they only wo= rk > 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 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. L=C3=A9n=C3=A1rd Szolnoki > > -- > 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/0144b887-c694-4f3e- > b368-32645a1562d9%40isocpp.org > > . > --=20 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 e= mail 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/CAOfiQqn40HxZtT_zCgH2mzNZ-binpgf3%2BuULrZLNVGDmw= YcgSA%40mail.gmail.com. --001a11c034a6f4905b05599ad672 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 1= 9 September 2017 at 09:37, <leni536@gmail.com> wrote:
Hi,
Guaranteed copy elision 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()= ; }
};

This almost works... the tr= ouble is that perfect forwarding gets in the way (unsurprisingly, since &qu= ot;perfect" forwarding is imperfect for prvalues). allocator::construc= t will do

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

where we need the argument to the construct= or to be a *prvalue* of type T. Possibly we could modify the construction l= ogic to use a mechanism that acts like forward<T> for most Ts, but in= vokes the wrapped function when T is emplace_using<Fn>.
L= =C3=A9n=C3=A1rd Szolnoki

--
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-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/0144= b887-c694-4f3e-b368-32645a1562d9%40isocpp.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn40HxZtT= _zCgH2mzNZ-binpgf3%2BuULrZLNVGDmwYcgSA%40mail.gmail.com.
--001a11c034a6f4905b05599ad672-- .