220 29835 <2298fa65-32bb-435a-a486-c7e000267c11@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: alexandre.isoard@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: New smart pointer: CopyConstructible and CopyAssignable flavor of unique_ptr Date: Fri, 16 Dec 2016 06:22:10 -0800 (PST) Lines: 157 Approved: news@gmane.org Message-ID: <2298fa65-32bb-435a-a486-c7e000267c11@isocpp.org> References: <13702f32-32c2-447f-9996-3624fd678675@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_720_1868468284.1481898130784" X-Trace: blaine.gmane.org 1481898141 3493 195.159.176.226 (16 Dec 2016 14:22:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 14:22:21 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDXMXE5S7EMRBE7RZ7BAKGQETVA66QQ@isocpp.org Fri Dec 16 15:22:16 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHtOh-0007T2-Sv for gclcip-std-proposals@m.gmane.org; Fri, 16 Dec 2016 15:22:08 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id q197sf147570426oic.7 for ; Fri, 16 Dec 2016 06:22:12 -0800 (PST) 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=svGSR5qOBwPrYuEYU8CiLRRw2o+TYGoHH7UdhFfQ3p8=; b=UPbM2kc0TkLCm1fOR0KjmjDKIlqHg2f6LhjXV00lp8CmpZzk3GfhDHeoLVOqbWFCF4 C7/UrP2sL3qW3oSa1hFlroIXf8xXoqkQtnO/QXUdZ/0Sscn4oJrYfxmElHRdq7FhtJWa 6ffT6bZEu+wrdzpargrxNMD7p0rAEGLXJZe/6wBpTuhz/J1IGJDrRXkypse43wdARaDQ qZbjSUpMy/AOfhXqCQljAiwxNgtoKU6zk2vXMmIerTutssJmzTcaq0tu5wdPHFGRFcZO RzZMDIucNnvsBR+c2x8u51hok7ktjkrX0rKODa+7natncLdWI+6QtatEd/LwlUwVpMwX 69WQ== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=svGSR5qOBwPrYuEYU8CiLRRw2o+TYGoHH7UdhFfQ3p8=; b=UWlSG7SzJ0QBKD5d2aPnc8ZaMwwA257UeHYef2/S0Z5bZWdTaNVswHIDJGgVPEk4h8 dDrKvXgEvsU+Hwca5El+THsoB3CxacZKc+Zyf57c/WZDZIQrgUDDA5JY+gHijvvKK1jp FNxyksRXBdx+LDRvcre3zjBkhKr4qx/zW2VZXsO/AHniIUczzHoJS9sq8CrAEx+iUj01 MfYHvBwx9hTIUajG9XlCJPxbZFzrAOUIJsmSVeyVaWtOubkIX+20Aj4THSThodVqeOCB oQLqIAo6fcR9Ooltaf7WYrnU/Y+IJjthtyBSfy6XXZxP64yByCyUccSlpN+Dx5UWy96B ktwQ== 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=svGSR5qOBwPrYuEYU8CiLRRw2o+TYGoHH7UdhFfQ3p8=; b=uGClqylqeQXEAdfMI6YuWsQvIGiT1cfrwPpwEiKIUEgeKcsYLVKVrFm+6URvUhsjrS JbTKePHHuiI6rGu+c+z5ow1eq7LgYJ5mOkHTSo0pmEE/Kz6qlqiL8VQw8IAhz2f5GEtW NGBogVlA1HkZA1lLo3i39mNPsW5cyEiyQ7WjGrRB/1j8w/E49EQEaVpHK7NtHY5zotwx CwUhEV1H73OgHy2oel1w+7svFi8yo2G/ktmb+/g5WsWsTgoJQrzGZ5kgNNyBCvQ5vEEk QK45BCzZZSeh2sem6s6psNfgv3uWzGVfoPN4wRZG08kg8mxR7RdRWZNw0JvVEt7yqJBj dzUw== X-Gm-Message-State: AKaTC03j/1bHLamjZaWiN7rLG7Zc+aBXkw59+gnvTZ3luPs9rgk3COnY5ltbOGsZK8Ds1g== X-Received: by 10.157.4.119 with SMTP id 110mr765424otc.119.1481898132038; Fri, 16 Dec 2016 06:22:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.29.137 with SMTP id y9ls8046189otd.39.gmail; Fri, 16 Dec 2016 06:22:11 -0800 (PST) X-Received: by 10.157.39.129 with SMTP id c1mr130977otb.15.1481898131159; Fri, 16 Dec 2016 06:22:11 -0800 (PST) In-Reply-To: X-Original-Sender: alexandre.isoard@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:29835 Archived-At: ------=_Part_720_1868468284.1481898130784 Content-Type: multipart/alternative; boundary="----=_Part_721_1303644550.1481898130784" ------=_Part_721_1303644550.1481898130784 Content-Type: text/plain; charset=UTF-8 On Friday, December 16, 2016 at 11:40:56 AM UTC, Ville Voutilainen wrote: > > On 16 December 2016 at 13:32, > > wrote: > > std::copy_ptr is a smart pointer that owns and manages another object > > There is ongoing work in the area, in > http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0201r1.pdf > which originally was closer to a cloning pointer than a polymorphic > value. The paper author has told me that > he thinks it's a good idea to propose both a cloning pointer and a > polymorphic value, and that he plans to > do just that in the future. > Thank you. This seems indeed a good plan. To add some precisions: - std::copy_ptr would perform a deep copy even when copying from a const std::copy_ptr into a const std::copy_ptr. That is: const std::copy_ptr x(foo); const std::copy_ptr y(x); Would end up with two copies of foo. Else when they go out of scope a double free would occur. By the way, here is a example use case that I needed recently: I am wrapping an external C library which has the following particularities: - All the objects are opaque pointers - All objects have deep-copy functions and deleters. - Most of its functions free their arguments and allocate their results Behind the hood it uses copy-on-write to make copy cheap and it sometimes recycle one of its argument when the returned object has the same structure (to avoid a free and a malloc). (but that is semantically identical to an actual copy and an actual free) What I do is that I wrap those objects into a copy_ptr and provide the custom copy and custom deleter. This allows me to do the following: copy_ptr do_something(copy_ptr a, copy_ptr b) { return make_copy(obj_do_something(a.release(), b.release()); } Where obj_do_something is the C function, and do_something is the C++ wrapper. This handle nicely the case where we don't want a spurious copy: For example: a = do_something(std::move(a), b); Will deep-copy b, then move a, compute and move it back to a. This provides a move-semantic aware wrapper that handle all the allocation for free and do not perform spurious copies. -- 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/2298fa65-32bb-435a-a486-c7e000267c11%40isocpp.org. ------=_Part_721_1303644550.1481898130784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, December 16, 2016 at 11:40:56 AM UTC, V= ille Voutilainen wrote:
On 16 D= ecember 2016 at 13:32, =C2=A0<alexandr...@gmail.com> wrote:
> std::copy_ptr is a smart pointer that owns and manages another obj= ect

There is ongoing work in the area, in
http://open-std.org= /JTC1/SC22/WG21/docs/papers/2016/p0201r1.pdf
which originally was closer to a cloning pointer than a polymorphic
value. The paper author has told me that
he thinks it's a good idea to propose both a cloning pointer and a
polymorphic value, and that he plans to
do just that in the future.

Thank you. This seems indeed a good pl= an.

To add some precisions:
  • std:= :copy_ptr would perform a deep copy even when copying from a const std::cop= y_ptr into a const std::copy_ptr.
That is:

const std::copy_ptr<T*> x(foo);
const std:= :copy_ptr<T*> y(x);

Would end up with two co= pies of foo. Else when they go out of scope a double free would occur.


By the way, here is a example use case = that I needed recently:

I am wrapping an external = C library which has the following particularities:
  • All th= e objects are opaque pointers
  • All objects have deep-copy functions = and deleters.
  • Most of its functions free their arguments and alloca= te their results
Behind the hood it uses copy-on-write to mak= e copy cheap and it sometimes recycle one of its argument when the returned= object has the same structure (to avoid a free and a malloc). (but that is= semantically identical to an actual copy and an actual free)

What I do is that I wrap those objects into a copy_ptr an= d provide the custom copy and custom deleter. This allows me to do the foll= owing:

copy_ptr<obj> do_something(copy_ptr&l= t;obj> a, copy_ptr<obj> b) {
=C2=A0 =C2=A0 return make_c= opy(obj_do_something(a.release(), b.release());
}

Where obj_do_something is the C function, and do_something is the C++ wr= apper.
This handle nicely the case where we don't want a spur= ious copy:

For example:

a= =3D do_something(std::move(a), b);

Will deep-copy= b, then move a, compute and move it back to a.

Th= is provides a move-semantic aware wrapper that handle all the allocation fo= r free and do not perform spurious copies.

--
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/2298fa65-32bb-435a-a486-c7e000267c11= %40isocpp.org.
------=_Part_721_1303644550.1481898130784-- ------=_Part_720_1868468284.1481898130784-- .