220 35147 <91fab9b2-fa08-4ee2-b71f-9c7b5c6cc690@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 11:32:41 -0700 (PDT) Lines: 200 Approved: news@gmane.org Message-ID: <91fab9b2-fa08-4ee2-b71f-9c7b5c6cc690@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_7162_1126213429.1509388361835" X-Trace: blaine.gmane.org 1509388368 20242 195.159.176.226 (30 Oct 2017 18:32:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Oct 2017 18:32:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCJLPT5ZVQHBBSXA3XHQKGQELEHF5ZY@isocpp.org Mon Oct 30 19:32:43 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9ErW-00047Q-66 for gclcip-std-proposals@m.gmane.org; Mon, 30 Oct 2017 19:32:38 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id g69sf7283171vke.2 for ; Mon, 30 Oct 2017 11:32:45 -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=HU7EmCxvr8mKWy5gOQkfiFT9LE0w99Ti8+dANR5c814=; b=AB3JUIcni+DtCLRdKKBwePmgCTDBwJX6RDsB0fQgC5A+iM1zKUHmv0m64+gcFQci1A EvtRiFv67OWKRn8ERZqGn7gz7aBg7J2InuzzI2cpz1P7SLlrIELXw6GbghiACRW/idEV RAJw3Rgn7H4HPHc+qAUcFJ0um+YmBZM3Jt0CsM3a1QzsomKANlRHnm81eLDAWJgDffzF /YTwW82ykk1fTox4g7Vtf2lWaoCLPSAF2bye9RuXy9lQTAAShwCg2SEzuU/N5EDWlpFc fFNUnOPIaJHjqJQv97hs3/b207HMwTdODtNuCtqoWprc1vAkvnpATn/Y0e+MIUmHdJ56 GxmA== 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=HU7EmCxvr8mKWy5gOQkfiFT9LE0w99Ti8+dANR5c814=; b=cR60J/6b0/jkeSd44dsdV8CMuFyBsnqRk0TSjFX4oP5W3M7oIWuF9brAPfapiLlGGK ZO4M7ji18wZVqtJeHBYJ1/dWnUf4uke7yGpp+CQ5J00MUk7mQ3igLoXo8ESiVhq4hX9r hX3wVZrD/w7RbSC+O9r/RLYqVjbaLfhoysYvIlsA0EgTTwg5DvKWweHV8JK3a3en2NAt EcsPXbdw0pWGUDRbT5n6yu7BfwGXM5zJxV5UzhkKfPK7fmLP+ZNrYL1bJkiiXqFyuEkf Stiqc0rHxlsNpiKC/52LB1zgDubQc9UFuWkShWIJtrg8FXwiSbdnklZ4BQAK6io5Y4g0 Y2Dw== 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=HU7EmCxvr8mKWy5gOQkfiFT9LE0w99Ti8+dANR5c814=; b=elxqzj+DheY59VUJSbWwHmyei09BhGwHRzXYQdvwBFs3eTGtk3xNnnSo00bYTT/cs6 LUW8hmzzoGriWNpVwJo5VD6CQ8N5/6mQbEs1M8FAbhCe4yt0vcyBIVzUY1zhXFYVM+PS UXBRoh4jsYX/m6G+G5Pcg/lhih0nfRu7EioxncyFMRMaLqF409yI+MwaohrSVr0kG2ey efNhJ+3WxMnfVtck6vop0OMLw4MtqlmkF45Bi+Hq8pM73V4Z7w5rAXLaW1VpiB7MyKk8 u8mkYMu8kJrxbdGZIR/ivjR8tbwPOhJu/1AyqZniYhnSd8bV26+vqGgwWOiO6jvGkGiO tGqA== X-Gm-Message-State: AMCzsaUSiGsmzCWuQHR+dwNgQCJHWDQ/2ulWN19RSguv3LAH1mkgyhWK Kmfse+nf3MVX91/XXKzy8lBvZw== X-Google-Smtp-Source: ABhQp+TK3c9SnX67apUqEUh0TmrwZAKl04lu7DVZska+xpTXfirvGm2k4VsKZxYaKdQKFupUNh7MfA== X-Received: by 10.31.149.16 with SMTP id x16mr9075735vkd.12.1509388363925; Mon, 30 Oct 2017 11:32:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.36.173 with SMTP id 42ls4343348uar.17.gmail; Mon, 30 Oct 2017 11:32:42 -0700 (PDT) X-Received: by 10.31.149.85 with SMTP id x82mr1675563vkd.3.1509388362460; Mon, 30 Oct 2017 11:32: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:35147 Archived-At: ------=_Part_7162_1126213429.1509388361835 Content-Type: multipart/alternative; boundary="----=_Part_7163_1995014264.1509388361836" ------=_Part_7163_1995014264.1509388361836 Content-Type: text/plain; charset="UTF-8" The first approach looks like this (attached). 1. Should I post it as a new topic or continue here? 2. Should I upload it to my hosting (or some preferred one) and post a link or attaching the file is fine? Thanks for your time, Vasilii Babich. On Monday, October 30, 2017 at 8:38:37 PM UTC+4, Nevin ":-)" Liber wrote: > > On Mon, Oct 30, 2017 at 11:05 AM, > wrote: > >> void(?) unique_ptr::emplace(Args &&... args) { *this = >>> make_unique(std::forward(args)...); } >>> void(?) shared_ptr::emplace(Args &&... args) { *this = >>> make_shared(std::forward(args)...); } >>> >> > Thoughts: > > - Neither shared_ptr nor unique_ptr store an allocator, so > shared_ptr::emplace and unique_ptr::emplace are being tied to a particular > allocation scheme. This makes it harder when people refactor code to use > other allocation schemes. > - unique_ptr has a deleter, which may not go along with emplace > calling "new". Will this function still exist if default_delete isn't > being used? > - Unless you templatize it, emplace will not work for polymorphic > types, which IMO is one of the major use cases for unique_ptr (and a less > major one for shared_ptr). > > Note: I'm not saying these are reasons I would vote against such a > proposal; rather, these are things which need to be discussed in the > proposal. > -- > Nevin ":-)" Liber > > +1-847-691-1404 > -- 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/91fab9b2-fa08-4ee2-b71f-9c7b5c6cc690%40isocpp.org. ------=_Part_7163_1995014264.1509388361836 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The first approach looks like this (attached).

1. Should I post it as a new topic or continue here?

=
2. Should I upload it to my hosting (or some preferred one) and = post a link or attaching the file is fine?

Thanks for your time,
Vasilii Babich.

On Monday, October 30, 2017 at 8:38:37 PM UTC= +4, Nevin ":-)" Liber wrote:
On Mon, Oct 30, 2017 at 11:05 AM, <
void(?) unique_ptr<T>::e= mplace(Args &&... args) { *this =3D make_unique<T>(std::forwa= rd<Args>(args)...); }
void(?) shared_ptr<T>::emp= lace(Args &&... args) { *this =3D make_shared<T>(std::forward= <Args>(args)...); }

Thoughts:
  • Neither shared_ptr no= r unique_ptr store an allocator, so shared_ptr::emplace and unique_ptr::emp= lace are being tied to a particular allocation scheme.=C2=A0 This makes it = harder when people refactor code to use other allocation schemes.
  • u= nique_ptr has a deleter, which may not go along with emplace calling "= new".=C2=A0 Will this function still exist if default_delete<T> = isn't being used?
  • Unless you templatize it, emplace will no= t work for polymorphic types, which IMO is one of the major use cases for u= nique_ptr (and a less major one for shared_ptr).
Note: =C2=A0= I'm not saying these are reasons I would vote against such a proposal; = rather, these are things which need to be discussed in the proposal.
<= /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/91fab9b2-fa08-4ee2-b71f-9c7b5c6cc690= %40isocpp.org.
------=_Part_7163_1995014264.1509388361836-- ------=_Part_7162_1126213429.1509388361835 Content-Type: text/plain; charset=US-ASCII; name=smart_pointer_emplace_1.txt Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=smart_pointer_emplace_1.txt X-Attachment-Id: db5c7a59-f8b5-4b7d-a676-4b7ebbe8c7f1 Content-ID: Date: 2017-10-30 Reply-to: Vasilii Babich Adding Emplace functions for shared_ptr / unique_ptr I. Introduction This is a proposal to add emplace functions for standard owning shared pointers shared_ptr and unique_ptr as a clean way of constructing a new object that is owned by a given smart pointer similarly to the emplace function in optional. II. Motivation A common case of creating new smart pointer values is to create a new object owned by an existing smart pointer variable whose type is exactly the type used in the smart pointer. Currently "p = make_unique(args)" approach is peferred. While it eliminates one type name T from the naive approach "p = unique_ptr(new T(args))" it is still unnecessary verbose, because the information about the type could be known from the pointer type itself. The proposed way of dealing with this task is to write "p.emplace(args)". The same goes for shared_ptr. III. Impact On the Standard This proposal is library extension. It proposes adding a member function template to two standard library classes, shared_ptr and unique_ptr. It does not require any changes in the core language, and it has been implemented in standard C++. The proposal does not depend on any library extensions. IV. Design Decisions * The proposed library extension will improve the case of constructing the object of the exact pointed type, the mentioned "p = make_unique(args)" and "p = make_shared(args)". * It will not improve the case of using custom allocators in shared_ptr. A special "emplace_allocate(alloc, args)" method may be considered as a simplified version of "p = allocate_shared(alloc, args)". * It will not improve the case of using custom deleter in unique_ptr. The same goes for make_unique function, which is used to simplify the most common use case of creating a unique_ptr. * It will not improve the case of creating an object of a derived type to be owned by a smart pointer to the base class. In this case make_unique and make_shared are still the best option, since no unnecessary repeating is done in the code, because the desired type of the object is not known anywhere else. The polymorphic usage of shared_ptr and unique_ptr (having a base class smart pointer that points to a derived class object) is clearly distinct from the value-type usage. The proposal improves the visual difference for this two types of usage. In the value-type usage there is no reason to prefer "= make_shared" and "= make_unique" over emplace. In polymorphic usage nothing changes and there is no reason to prefer emplace over make_* or even no way to use it. * The proposed extension is consistent with optional emplace member function which simplifies the case "o = make_optional(args)" to "o.emplace(args)". * The return type is suggested to be the reference to the smart pointer itself. This goes well if we look at the "p.emplace(args)" as a simplified syntax for "p = make_unique(args)". Another aproach would be to return the reference to newly created object like optional::emplace does. This will be consistent with the optional, but this can't be done consistently for unique_ptr and proposed emplace(size_t n) function, because we can't get a reference to the array we hold, this unique_ptr doesn't have dereference operator. V. Technical Specifications Proposal: * Add a modifier member function template shared_ptr& shared_ptr::emplace(Args&&... args); which effect is equivalent to *this = make_shared(args...) * Add a modifier member function for non-array types T template unique_ptr& unique_ptr::emplace(Args&&... args); which effect is equivalent to *this = make_unique(args...) * Add a modifier member function for unknown-bound array types T unique_ptr& unique_ptr::emplace(size_t n); which effect is equivalent to *this = make_unique(n); * Add a member function for known-bound array types T template unspecified unique_ptr::emplace(Args&&...) = delete; ------=_Part_7162_1126213429.1509388361835-- .