220 35161 <281e79ef-e1f7-45c2-8b72-ed5c49392180@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 13:17:42 -0700 (PDT) Lines: 137 Approved: news@gmane.org Message-ID: <281e79ef-e1f7-45c2-8b72-ed5c49392180@isocpp.org> References: <58eb77f6-2c2d-4ec1-85f8-08dcfe25a23e@isocpp.org> <8d668562-154e-4d26-9605-2973bb78f699@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2145_1497297990.1509394662096" X-Trace: blaine.gmane.org 1509394681 17433 195.159.176.226 (30 Oct 2017 20:18:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Oct 2017 20:18:01 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCJLPT5ZVQHBBZUR33HQKGQEZY4INAA@isocpp.org Mon Oct 30 21:17:48 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9GV6-0002PX-Qf for gclcip-std-proposals@m.gmane.org; Mon, 30 Oct 2017 21:17:36 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id d12sf7460546vkf.1 for ; Mon, 30 Oct 2017 13:17:44 -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=l+93pKStQ91pFq2FBvUcKGeoIbWcs2JZjNqREZxax/k=; b=qu9u54MhzBVpYczGO/hPSfQXtAmgJKMNKCLarCTboCQz1ZJ8kYriKq7ZyNKD3/NzGI VHVdoFvvSfK69wZaPSG34CqVYeqDfGZe6dPw5x63MVgZ3CzQC1yBDnoe7Z73yhYoDJee jMtVNiTwgPYK0a31ierceuHIhX0px0Wcmb3n+US7yil6TMud4V4tjsburF2/LDl3gjEp 02TqkmlWrMwIogmAAzyxlE+xCq6QfVYa+2aceRNUJTZuJ1/cYKcz5UFtwjwZzK0GdQHZ 58nv9JUzx8MIWr921kedxTGyzoVeVxHzABDq4ypiXvDGGMu7kCik6Vu4xFG3DBlcZn3D fttg== 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=l+93pKStQ91pFq2FBvUcKGeoIbWcs2JZjNqREZxax/k=; b=N/cTTnC/16nK2x9G3XrCJHqGvAJHFGF3ImFIR3uBc78djYSKw9unlhJR6N1TSUudgC noDi3DV54MbZRkVw++glGnNB8QsXbd8cgNzNiZtgMADiKPOAnZgjn/PrTT5a7GlhImz5 Dyh/4whRadTJ2UFYF5n8i7iGW5Us71iia53d+8ilUOP7ynqEhtAZHKm/rPszXR1zjxeH HzcWcywp2JFUzR4WTVr4aKiPTe+qBzKgyjwrDShILXre1NIF+nPK7ev7+POWlQjt5dK7 eaa4H/xq+whZ/zTBc3n9pFMTzeAma0Y7nwb7y7Rj1MgvTCWkCtPji89oj3qC1ekAIbHo kErg== 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=l+93pKStQ91pFq2FBvUcKGeoIbWcs2JZjNqREZxax/k=; b=E0fztMP6xZ5ENGXSL+rI5KQjvspfS/GyCbdPZrKI80nNkrklUA0aOeR3SIbw3InReE IjXK1OBlRBk4hPKjlN6Y/pNpvV0Htxn0rHY5EBKURK3IxT//44+PnlA6XdqUZgx+kg4X T66mS2jYA6vSOKW8K1cjKigwPatWnkA5AUmI89MRkXLDaI+igc+81mP+KkHBuyCkcyQg pkPUlAxnIUQ8Tq6UnsGmQWsAAB/12Nh2o8cTTzqCrQyTk34x67+PSNu4Qn9ckPmtChiZ GXLOXAejvghhcjiBwqH7c4G87pqPX+ImZVZMvljrdCEueiLAELHnMwnk2KQzc9GSH8HF R81w== X-Gm-Message-State: AMCzsaVg4tan09e7NgKzWcWYUBWnhKkjZXJ28ZiUy4Vtpx/E0v5R6AEq Z8p5bmBUBeaFGoBI+H5vNudymA== X-Google-Smtp-Source: ABhQp+RTTAU9p5X9ENoIvBOj3TpWvvbZEgANkFUQptjPAzORIoe6VwqCTYSnPiMilfM+Obh6M/KVOw== X-Received: by 10.31.15.10 with SMTP id 10mr9642512vkp.70.1509394663933; Mon, 30 Oct 2017 13:17:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.54.115 with SMTP id s48ls4673848uad.0.gmail; Mon, 30 Oct 2017 13:17:42 -0700 (PDT) X-Received: by 10.31.137.138 with SMTP id l132mr1693592vkd.14.1509394662562; Mon, 30 Oct 2017 13:17:42 -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:35161 Archived-At: ------=_Part_2145_1497297990.1509394662096 Content-Type: multipart/alternative; boundary="----=_Part_2146_1786969177.1509394662096" ------=_Part_2146_1786969177.1509394662096 Content-Type: text/plain; charset="UTF-8" > But they're not. optional has a copy constructor, deep comparison etc. It just has a similar syntax because (for some reason) it was modelled after a pointer. Even if we're speaking only about similarities in syntax, they're still similarities. Not only operator*(), operator->() and explicit operator bool(), but also reset() member function and make_*(constructor_args) free function. And I see the emplace() method and in place constructors as good candidates for syntax similarities as well. > This in place constructor is exactly what I meant there. My comment is meant to be read as "will you also propose an in-place constructor?" Yes, I think in-place constructor could be a good addition to such proposal. > It doesn't mean that but should you also add a corresponding `operator=`? No, in my opinion assignment is not related to the emplace() function and I do not think it should be added to smart pointers. A case with single-argument emplace() call is just one case of a usual emplace() usage that takes arbitrary number and types of constructor arguments. Assignment a value to a smart pointer will just confuse everyone without adding anything, because "*p = value" syntax doesn't have any problems and is very similar to "p = value" syntax. > I think you are trying to turn smart pointers into indirect I don't think so, indirect solves its own goal of a deep-copyable indirect (possibly polymorphic) value type (being already renamed to polymorphic_value in the reference implementation). All those wrapper classes (optional, shared_ptr, unique_ptr, indirect) serve different goals, but they all can contain a value of the type specified in the template parameter, they all share some of the public interface (like reset() call, like smart pointer semantics, like make_* helpers) - and I think they all should have similar interface to construct a new such value in the most efficient way, in both cases - when constructing a new wrapper object and when changing an existing wrapper object. First can be achieved by in_place constructors, second can be achieved by emplace() call. For shared_ptr make_shared encapsulates the most-used case (not custom allocator), hiding the explicit "new" and "delete" calls. The "emplace" method and in_place constructor achieve the same but with more clear syntax (no repeating of the type name) and possibly more efficient (no move constructor / assigning). For unique_ptr make_unique encapsulates the most-used case (not custom deleter), hiding the explicit "new" and "delete" calls. The same arguments go for "emplace" and in_place constructor here as for shared_ptr. If you use custom deleter, then it is likely you don't need the make function anyway, because the object is likely to be constructed somewhere else, not by a plain "new" call. -- 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/281e79ef-e1f7-45c2-8b72-ed5c49392180%40isocpp.org. ------=_Part_2146_1786969177.1509394662096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> But they're not. optional has a copy constructor,= deep comparison etc.=C2=A0
It just has a similar syntax because (for so= me reason) it was modelled=C2=A0
after a pointer.=C2=A0

Even if w= e're speaking only about similarities in syntax, they're still simi= larities. Not only operator*(), operator->() and explicit operator bool(= ), but also reset() member function and make_*<T>(constructor_args) f= ree function. And I see the emplace() method and in place constructors as g= ood candidates for syntax similarities as well.

> Thi= s in place constructor is exactly what I meant there.=C2=A0
My comment i= s meant to be read as "will you also propose an in-place=C2=A0
cons= tructor?"=C2=A0

Yes, I think in-place constru= ctor could be a good addition to such proposal.

&g= t; It doesn't mean that but should you also add a corresponding `operat= or=3D`?=C2=A0

No, in my opinion assignment is not = related to the emplace() function and I do not think it should be added to = smart pointers. A case with single-argument emplace() call is just one case= of a usual emplace() usage that takes arbitrary number and types of constr= uctor arguments. Assignment a value to a smart pointer will just confuse ev= eryone without adding anything, because "*p =3D value" syntax doe= sn't have any problems and is very similar to "p =3D value" s= yntax.

> I think you are trying to turn smart pointers into indir= ect<T>

I don't think so, indirect<T&g= t; solves its own goal of a deep-copyable indirect (possibly polymorphic) v= alue type (being already renamed to polymorphic_value in the reference impl= ementation).

All those wrapper classes (optional, = shared_ptr, unique_ptr, indirect) serve different goals, but they all can c= ontain a value of the type specified in the template parameter, they all sh= are some of the public interface (like reset() call, like smart pointer sem= antics, like make_* helpers) - and I think they all should have similar int= erface to construct a new such value in the most efficient way, in both cas= es - when constructing a new wrapper object and when changing an existing w= rapper object. First can be achieved by in_place constructors, second can b= e achieved by emplace() call.

For shared_ptr make_= shared encapsulates the most-used case (not custom allocator), hiding the e= xplicit "new" and "delete" calls. The "emplace&quo= t; method and in_place constructor achieve the same but with more clear syn= tax (no repeating of the type name) and possibly more efficient (no move co= nstructor / assigning).

For unique_ptr make_unique= encapsulates the most-used case (not custom deleter), hiding the explicit = "new" and "delete" calls. The same arguments go for &qu= ot;emplace" and in_place constructor here as for shared_ptr. If you us= e custom deleter, then it is likely you don't need the make function an= yway, because the object is likely to be constructed somewhere else, not by= a plain "new" call.

--
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/281e79ef-e1f7-45c2-8b72-ed5c49392180= %40isocpp.org.
------=_Part_2146_1786969177.1509394662096-- ------=_Part_2145_1497297990.1509394662096-- .