220 35151 <8d668562-154e-4d26-9605-2973bb78f699@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: antanubis@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Add .emplace() method to std::unique_ptr and std::shared_ptr like it is in std::optional. Date: Mon, 30 Oct 2017 12:01:03 -0700 (PDT) Lines: 275 Approved: news@gmane.org Message-ID: <8d668562-154e-4d26-9605-2973bb78f699@isocpp.org> References: <58eb77f6-2c2d-4ec1-85f8-08dcfe25a23e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7040_1732903010.1509390063817" X-Trace: blaine.gmane.org 1509390068 10366 195.159.176.226 (30 Oct 2017 19:01:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Oct 2017 19:01:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCJLPT5ZVQHBB4HN3XHQKGQENOLLG3I@isocpp.org Mon Oct 30 20:01:01 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9FIw-0001in-Fv for gclcip-std-proposals@m.gmane.org; Mon, 30 Oct 2017 20:00:58 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id f46sf10068155uae.11 for ; Mon, 30 Oct 2017 12:01:06 -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=XgaMcfn683otaKV6alA/OQ4NFYQSK/1k+IDHoPyWKQc=; b=MRnOaxjGtIZh7bvRd4JdPyI0rrfQSS+5DVJrraZqiyXsenlj/8D2KYMCl9+Fqo2VII y8Ez1Sj/jmRRWP0cHZhNCkDRfgz9SRUTjkvAO5njcSIJuM5dwhrsJ+sqi5iICFGhqTsK nZ0hQiLvYMapmIopSZkH6iXplwqXLrDnCcR20yjrXCcUOmsOpfjWzJ8TIZK0OBRVpqaD h4RRO3JYUniaEZo/vJw0I2AOQ5grx+YwRPLWQyQbRkvb3T9SZYnPJlMN83CWkkO7mdB6 JK4qKSeiyyl9HRn0p0LFVEgADrT/PijClGVIzOqhcW6269deMJyu3U2KT9gv2HJMuRr5 87UQ== 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=XgaMcfn683otaKV6alA/OQ4NFYQSK/1k+IDHoPyWKQc=; b=goG2eEmeMB0dqIBAaflk85EV3yXUcEL/Ym6UAHc0ekamxkUfEYpqA7qNbe+edSNXLw 4aEo2aX8gmErXQJPfQfpDuO+Cey5YFoCnPSv6Otcyv1Xee/5fmGH3iS//dwgIRP8CuaG RtNFzcdcucJumTXW2ED7OU9QydT980Ko6kOj+yKqIPrVpkI271itzXJRqv3PkOA3yQ79 tJNOJW+O9x+kNuvxWCKnR4FEpnwpnLOYB9sH02M6BWGZ0Grh4uq+cBngcZ78E9ELDMcV ynxVBncRmkWVI4e/LtIQiNHPqReL9zXBaSiaPSzuXgI0a9Bn8rPGjaJddQSFpFueuEIT 3rhw== 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=XgaMcfn683otaKV6alA/OQ4NFYQSK/1k+IDHoPyWKQc=; b=bUyD8yoKCJug0cS8AAnoEutlBa7zTgnN/JOFT2SO1KtyQIpR2ZeaU7jpiQtoU8n1Tm Zc6DfXh/eLn+jpMxWxRDBb4g8ERIfmE3tZUkLooZcyhdn6BGuDyLQQV8aPVRfnBbe61D cWkdFkh7XuGp7Z5yCzGhG3JUMzbbPG5WPsGlMGPB0LQHxtu7I3bYavMJ84yZwTLUYA04 kEZcA+Tx8Q9OUmQWRy0iN0UEbp28rGfqysJjizcqABVCLZ4Z9BBhMAIjchkUSgecOohV 66+Enn1g9/AdIXZ0FSIBZYDylrLbseZelf7bB0QqsH3INpn7SNvJAXlkif7XUxqN1arU XNhw== X-Gm-Message-State: AMCzsaW1ft+CVFR2tDJTpCXlMeKXGTf9m5N+I2SRL11giebJ8n9xnNS0 64pTdvVsXemOiwPZbY5gI0VPAg== X-Google-Smtp-Source: ABhQp+Q7Vz/4CqpgzHMvKkAbwBNvpofqLpt6+xUl7u4ig5rmz9YvQq8Rb/CSMh4Z6wRXwi6WIDHXHg== X-Received: by 10.31.148.79 with SMTP id w76mr9739899vkd.3.1509390065814; Mon, 30 Oct 2017 12:01:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.115.6 with SMTP id o6ls3581641vkc.14.gmail; Mon, 30 Oct 2017 12:01:04 -0700 (PDT) X-Received: by 10.31.32.204 with SMTP id g195mr1688669vkg.10.1509390064251; Mon, 30 Oct 2017 12:01:04 -0700 (PDT) In-Reply-To: X-Original-Sender: antanubis@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:35151 Archived-At: ------=_Part_7040_1732903010.1509390063817 Content-Type: multipart/alternative; boundary="----=_Part_7041_2085677401.1509390063817" ------=_Part_7041_2085677401.1509390063817 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The smart pointers and optional behave very differently: optional has=20 value semantics, so it makes sense to say "create a new object".=20 I don't think it makes sense to ask the same from unique_ptr.=20 In my experience unique_ptr is quite similar to optional. It is like an optional that doesn't hold the memory while there is no value= =20 in it and that works nicely with forward declarations. > If we have `emplace()` what about a constructor of the same form?=20 Yes, there's make_XXX but with class template argument deduction we=20 don't really want make_XXX anymore. As I understand the smart pointer make_* methods won't go anywhere after=20 the template argument deduction comes in to play because they're not a=20 helper functions for existing constructors of smart pointers. They can=20 replace "make_unique(args)" with "unique_ptr(new T(args))" with=20 returning naked new to the common pattern (which is not looking good) and= =20 they can't replace make_shared at all because of optimized storage used in= =20 make_shared compared to "shared_ptr(new T(args))". If we have emplace() in smart pointers perhaps we also would like to have= =20 in_place constructors for smart pointers similar to optional constructors= =20 with std::in_place. Those constructors would improve the usage of member=20 initialization of smart pointer fields while emplace improves the usage of= =20 assigning of smart pointer variables. This will allow us to use "A::A() := =20 p(in_place, args)" instead of "A::A() : p(make_unique(args))" and=20 "p.emplace(args)" instead of "p =3D make_unique(args)". > If `ptr.emplace(obj)` works, what about `ptr =3D obj`? If you say no to= =20 assignment because it doesn't make sense, why allow emplace? object.emplace(value) doesn't always say "assign this value to that object"= =20 even with exactly one argument. For example std::set has=20 ..emplace(value), but it doesn't allow assigning this value to it. emplace()= =20 methods in all standard classes say something like "create a new object=20 from all those arguments and put it inside" and it works perfectly for both= =20 shared_ptr and unique_ptr. > Why go through all that just to save a `=3D make_unique(blah)`?=20 That's not too much typing.=20 The same can be said about "make_unique", but it was added, because it is a= =20 common pattern and it simplifies the code. "p =3D unique_ptr(new T(args)= )"=20 is more verbose than "p =3D make_unique(args)" which is still unnecessar= y=20 verbose compared to "p.emplace(args)". The amount of typing depends on the= =20 type T. :) If we introduce "auto" to reduce unnecessary typing in favour of= =20 better non-abbreviated type names (even if they're longer) in places where= =20 we have to specify them, I don't see why we won't remove those unneeded=20 type name typings in other common code patterns. On Monday, October 30, 2017 at 10:36:59 PM UTC+4, Jonathan M=C3=BCller wrot= e: > > On 30.10.2017 17:37, Nevin Liber wrote:=20 > > On Mon, Oct 30, 2017 at 11:05 AM, =20 > > >> wrote:=20 > >=20 > > void(?) unique_ptr::emplace(Args &&... args) { *this =3D=20 > > make_unique(std::forward(args)...); }=20 > > void(?) shared_ptr::emplace(Args &&... args) { *this =3D=20 > > make_shared(std::forward(args)...); }=20 > >=20 > >=20 > > Thoughts:=20 > >=20 > > * Neither shared_ptr nor unique_ptr store an allocator, so=20 > > shared_ptr::emplace and unique_ptr::emplace are being tied to a=20 > > particular allocation scheme. This makes it harder when people=20 > > refactor code to use other allocation schemes.=20 > > * unique_ptr has a deleter, which may not go along with emplace=20 > > calling "new". Will this function still exist if default_delete= =20 > > isn't being used?=20 > > * Unless you templatize it, emplace will not work for polymorphic=20 > > types, which IMO is one of the major use cases for unique_ptr (and = a=20 > > less major one for shared_ptr).=20 > >=20 > > Note: I'm not saying these are reasons I would vote against such a=20 > > proposal; rather, these are things which need to be discussed in the=20 > > proposal.=20 > > Furthermore:=20 > > * The smart pointers and optional behave very differently: optional has= =20 > value semantics, so it makes sense to say "create a new object".=20 > I don't think it makes sense to ask the same from unique_ptr.=20 > > * If we have `emplace()` what about a constructor of the same form?=20 > Yes, there's make_XXX but with class template argument deduction we=20 > don't really want make_XXX anymore.=20 > > * If `ptr.emplace(obj)` works, what about `ptr =3D obj`? If you say no to= =20 > assignment because it doesn't make sense, why allow emplace?=20 > > * Why go through all that just to save a `=3D make_unique(blah)`?=20 > That's not too much typing.=20 > > --=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/8d668562-154e-4d26-9605-2973bb78f699%40isocpp.or= g. ------=_Part_7041_2085677401.1509390063817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The smart pointers and optional behave very different= ly: optional has=C2=A0
value semantics, so it makes sense to say "c= reate a new object".=C2=A0
I don't think it makes sense to ask = the same from unique_ptr.=C2=A0

In my experience unique_ptr is quite= similar to optional.
It is like an optional that doesn't hold the = memory while there is no value in it and that works nicely with forward dec= larations.

> If we have `emplace()` what about a cons= tructor of the same form?=C2=A0
Yes, there's make_XXX but with class= template argument deduction we=C2=A0
don't really want make_XXX any= more.

As I understand the smart pointer make_* met= hods won't go anywhere after the template argument deduction comes in t= o play because they're not a helper functions for existing constructors= of smart pointers. They can replace "make_unique<T>(args)"= with "unique_ptr(new T(args))" with returning naked new to the c= ommon pattern (which is not looking good) and they can't replace make_s= hared at all because of optimized storage used in make_shared compared to &= quot;shared_ptr(new T(args))".

If we have emp= lace() in smart pointers perhaps we also would like to have in_place constr= uctors for smart pointers similar to optional constructors with std::in_pla= ce. Those constructors would improve the usage of member initialization of = smart pointer fields while emplace improves the usage of assigning of smart= pointer variables. This will allow us to use "A::A() : p(in_place, ar= gs)" instead of "A::A() : p(make_unique<T>(args))" and= "p.emplace(args)" instead of "p =3D make_unique<T>(ar= gs)".

> If `ptr.emplace(obj)` works, what about `ptr = =3D obj`? If you say no to=C2=A0
assignment because it doesn't make = sense, why allow emplace?

object.emplace(value) do= esn't always say "assign this value to that object" even with= exactly one argument. For example std::set<T> has .emplace(value), b= ut it doesn't allow assigning this value to it. emplace() methods in al= l standard classes say something like "create a new object from all th= ose arguments and put it inside" and it works perfectly for both share= d_ptr and unique_ptr.

> Why go through all that= just to save a `=3D make_unique<T>(blah)`?=C2=A0
That's not t= oo much typing.=C2=A0

The same can be said about &= quot;make_unique", but it was added, because it is a common pattern an= d it simplifies the code. "p =3D unique_ptr<T>(new T(args))"= ; is more verbose than "p =3D make_unique<T>(args)" which i= s still unnecessary verbose compared to "p.emplace(args)". The am= ount of typing depends on the type T. :) If we introduce "auto" t= o reduce unnecessary typing in favour of better non-abbreviated type names = (even if they're longer) in places where we have to specify them, I don= 't see why we won't remove those unneeded type name typings in othe= r common code patterns.

On Monday, October 30, 2017 at 10:36:= 59 PM UTC+4, Jonathan M=C3=BCller wrote:
On 30.10.2017 17:37, Nevin Liber wrote:
> On Mon, Oct 30, 2017 at 11:05 AM, <anta...@gmail.com=20
> <mailto:anta...@gmail.com>> wrote:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 void(?) unique_ptr<T>::emplace(A= rgs &&... args) { *this =3D
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 make_unique<T>(std::forward<<= wbr>Args>(args)...); }
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 void(?) shared_ptr<T>::emplace(A= rgs &&... args) { *this =3D
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 make_shared<T>(std::forward<<= wbr>Args>(args)...); }
>=20
>=20
> Thoughts:
>=20
> =C2=A0 * Neither shared_ptr nor unique_ptr store an allocator, so
> =C2=A0 =C2=A0 shared_ptr::emplace and unique_ptr::emplace are bein= g tied to a
> =C2=A0 =C2=A0 particular allocation scheme.=C2=A0 This makes it ha= rder when people
> =C2=A0 =C2=A0 refactor code to use other allocation schemes.
> =C2=A0 * unique_ptr has a deleter, which may not go along with emp= lace
> =C2=A0 =C2=A0 calling "new".=C2=A0 Will this function st= ill exist if default_delete<T>
> =C2=A0 =C2=A0 isn't being used?
> =C2=A0 * Unless you templatize it, emplace will not work for polym= orphic
> =C2=A0 =C2=A0 types, which IMO is one of the major use cases for u= nique_ptr (and a
> =C2=A0 =C2=A0 less major one for shared_ptr).
>=20
> Note: =C2=A0I'm not saying these are reasons I would vote agai= nst such a=20
> proposal; rather, these are things which need to be discussed in t= he=20
> proposal.

Furthermore:

* The smart pointers and optional behave very differently: optional has= =20
value semantics, so it makes sense to say "create a new object&quo= t;.
I don't think it makes sense to ask the same from unique_ptr.

* If we have `emplace()` what about a constructor of the same form?
Yes, there's make_XXX but with class template argument deduction we= =20
don't really want make_XXX anymore.

* If `ptr.emplace(obj)` works, what about `ptr =3D obj`? If you say no = to=20
assignment because it doesn't make sense, why allow emplace?

* Why go through all that just to save a `=3D make_unique<T>(blah= )`?=20
That's not too much typing.

--
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/8d668562-154e-4d26-9605-2973bb78f699= %40isocpp.org.
------=_Part_7041_2085677401.1509390063817-- ------=_Part_7040_1732903010.1509390063817-- .