220 29892 article Path: news.gmane.org!.POSTED!not-for-mail From: Jonathan Coe Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: New smart pointer: CopyConstructible and CopyAssignable flavor of unique_ptr Date: Sat, 17 Dec 2016 21:23:29 +0000 Lines: 328 Approved: news@gmane.org Message-ID: References: <3df7e8eb-01a0-7804-f476-504b5a25a9fe@gmail.com> <20161217170428.GA10214@manuel-ThinkPad-L440.localdomain> <20161217171633.4919375.58072.21574@gmail.com> <15884364-3238-41c7-bc5a-aa5595a64ade@isocpp.org> <20161217182130.GA4347@manuel-ThinkPad-L440.localdomain> <5eae5f16-e129-4c95-8001-fc73cc4f3d03@isocpp.org> <20161217192812.GA17421@manuel-ThinkPad-L440.localdomain> <20161217210804.GA10967@manuel-ThinkPad-L440.localdomain> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f403045dd96047ae270543e14cbc X-Trace: blaine.gmane.org 1482009815 3000 195.159.176.226 (17 Dec 2016 21:23:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 21:23:35 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBC2JVFPBRAHBBUWZ23BAKGQEJZE3JWA@isocpp.org Sat Dec 17 22:23:30 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIMRy-00081i-Ua for gclcip-std-proposals@m.gmane.org; Sat, 17 Dec 2016 22:23:27 +0100 Original-Received: by mail-pf0-f198.google.com with SMTP id y68sf173813190pfb.6 for ; Sat, 17 Dec 2016 13:23:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender: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=pReEAs3NpFQ2wm6LZIna3Yhl6GOsvXfInaMgz0oQ68k=; b=YiugZ5vVGj3tUxPPJsoKbmlxchT1DWC3rI/GQ5lOr1MUDKmeqhW8qFnfpqg8XSCNLZ ZE/Xg8o3RRnbzfnw9rCvTtrT8PNl7+KzSXXGsNzZjFuMYfpt7+5qEVwKy+MbkNd8bbCb rudry/6UP2qbTBuSl4hkql9FDcCFkvawj6zNodCdWzVh+QZtEQy88hS5me9Dg30CVF0E 714h4RrwDNP4wXWxoIw6bIFZYJzJPk4Ukzf/6tX4XTXkeQRudOXQmd2e2RrX5PurfZk/ tXlqQC75BF5V+1p8yE41jV2H1AF1E07uprG0nq+5nUE6nkLMpchEw1NNUPQtrqvdXH5l Fabg== X-Gm-Message-State: AKaTC03HlFOvmNeagusl40QWu6Otja3ZXnSHkckiqU+qtS8etzyAp5N+HZ0AkEE757AO0A== X-Received: by 10.98.21.16 with SMTP id 16mr1788428pfv.17.1482009811128; Sat, 17 Dec 2016 13:23:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.29.137 with SMTP id y9ls10582497otd.39.gmail; Sat, 17 Dec 2016 13:23:30 -0800 (PST) X-Received: by 10.159.36.107 with SMTP id 98mr1165019uaq.27.1482009810387; Sat, 17 Dec 2016 13:23:30 -0800 (PST) Original-Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com. [2607:f8b0:400c:c08::235]) by mx.google.com with ESMTPS id s134si3514968vkh.44.2016.12.17.13.23.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Dec 2016 13:23:30 -0800 (PST) Received-SPF: pass (google.com: domain of jonathanbcoe@gmail.com designates 2607:f8b0:400c:c08::235 as permitted sender) client-ip=2607:f8b0:400c:c08::235; Original-Received: by mail-ua0-x235.google.com with SMTP id y13so22875667uay.1 for ; Sat, 17 Dec 2016 13:23:30 -0800 (PST) X-Received: by 10.176.85.24 with SMTP id t24mr8098779uaa.21.1482009810020; Sat, 17 Dec 2016 13:23:30 -0800 (PST) Original-Sender: jonathanbcoe@gmail.com Original-Received: by 10.176.1.242 with HTTP; Sat, 17 Dec 2016 13:23:29 -0800 (PST) In-Reply-To: <20161217210804.GA10967@manuel-ThinkPad-L440.localdomain> X-Original-Sender: jonathanbcoe@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of jonathanbcoe@gmail.com designates 2607:f8b0:400c:c08::235 as permitted sender) smtp.mailfrom=jonathanbcoe@gmail.com; dmarc=fail (p=NONE dis=NONE) header.from=me.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:29892 Archived-At: --f403045dd96047ae270543e14cbc Content-Type: text/plain; charset=UTF-8 On 17 December 2016 at 21:08, Manuel Bergler wrote: > On Sat, Dec 17, 2016 at 12:35:03PM -0800, Nicol Bolas wrote: > >> It is different. >> >> Consider for example something like >> >> my_obj = std::accumulate(input.begin(), input.end(), >> std::move(my_obj), >> some_function); >> >> Afterwards references to my_obj will still be valid and correctly >> point >> to the >> modified object. >> >> On the other hand, if you have >> >> auto f = [&someObj] (auto& acc, auto const& in) -> decltype(auto) >> { >> acc->doSomethingModifyingThePointeeObj(in); >> someObj.doSomething(acc) // note I really want the cloning >> here >> // so I need to pass in the >> clone_ptr >> // and not the pointee >> return std::move(acc); >> }; >> >> my_clone_ptr = std::accumulate(input.begin(), input.end(), >> std::move(my_clone_ptr), f); >> >> now suddenly all references you got by calling `*my_clone_ptr` >> somewhen >> before >> might or might not be invalid, >> >> Actually, the standard guarantees that it isn't valid. Your >> `move(my_clone_ptr)` will move-construct the `init` parameter of >> `accumulate`. However, the standard says: >> >> > Computes its result by initializing the accumulator acc with the >> initial >> value init >> >> This means that it creates a new `T` called `acc`, which is initialized >> by >> the `init` value. Therefore, it will initialize `acc` by copy. `init` >> will >> hold the original pointer until the end of `accumulate`, when it will be >> destroyed. What will be returned is `acc`, which is a copy of `init`. >> >> > > Apparently clang and gcc interpret this differently: They move it into > place due to the std::move (see http://coliru.stacked-crooked. > com/a/cbe39ffef2ebf716). > > So in case of clang/gcc in my example the call to std::accumulate wouldn't > invalidate existing references. But who knows, maybe some implementer of > the standard library will interpret the requirements the same way you did > and actually perform a copy. But only forgetting to `return > std::move(acc);` in the lambda used for `std::accumulate` and using just > `return acc;` results in a copy. > > This is the entire point: When even very experienced people are not able to > predict what will happen, how is this a good feature? It is just too hard > to > use correctly. > > >> even though I moved the original clone_ptr into >> the algorithm to ensure that it doesn't get copied. >> >> Replace `clone_ptr` with `any`. Or `vector`. Many types have this >> problem >> with `accumulate`; I don't see why adding one more will hurt anything. >> > > This is because these types don't act as pointers; you're not supposed to > store references to individual elements of a vector or a std::any, whereas > the interface of this copy_ptr is designed to do exactly that, even though > it is dangerous/unpredictable. > > The only way to get around that issue is to not have additional references > to the pointee, but then there is no need to have the smart pointer > interface and you can just use `indirect`. > > Finishing touches to `polymorphic_value` (formerly know as `indirect`) are being made here https://github.com/jbcoe/polymorphic_value. > >> -- >> 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 [1]std-proposals+unsubscribe@isocpp.org. >> To post to this group, send email to [2]std-proposals@isocpp.org. >> To view this discussion on the web visit >> [3]https://groups.google.com/a/isocpp.org/d/msgid/std-propos >> als/cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org. >> >> References >> >> Visible links >> 1. mailto:std-proposals+unsubscribe@isocpp.org >> 2. mailto:std-proposals@isocpp.org >> 3. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals >> /cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org?utm_ >> medium=email&utm_source=footer >> > > -- > 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/is > ocpp.org/d/msgid/std-proposals/20161217210804.GA10967% > 40manuel-ThinkPad-L440.localdomain. > -- 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/CAAbBDD_eUtvYsPriPV-QSLED4Taxde1ShCMOuqpMm924JGVyzw%40mail.gmail.com. --f403045dd96047ae270543e14cbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 17 December 2016 at 21:08, Manuel Bergler <berglerma@gmail.com> wrote:
On Sat, Dec 17, 2016 at 12:35:03PM -0800, Nicol Bolas wrot= e:
=C2=A0 =C2=A0 It is different.

=C2=A0 =C2=A0 Consider for example something like

=C2=A0 =C2=A0 =C2=A0 =C2=A0 my_obj =3D std::accumulate(input.begin(), input= ..end(),
=C2=A0 =C2=A0 std::move(my_obj),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some_function);

=C2=A0 =C2=A0 Afterwards references to my_obj will still be valid and corre= ctly point
=C2=A0 =C2=A0 to the
=C2=A0 =C2=A0 modified object.

=C2=A0 =C2=A0 On the other hand, if you have

=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto f =3D [&someObj] (auto& acc, auto = const& in) -> decltype(auto) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acc->doSomethingModifyingThePo= inteeObj(in);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 someObj.doSomething(acc) =C2=A0//= note I really want the cloning here
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // so I need to= pass in the clone_ptr
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // and not the = pointee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::move(acc);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 };

=C2=A0 =C2=A0 =C2=A0 =C2=A0 my_clone_ptr =3D std::accumulate(input.begin(),= input.end(),
=C2=A0 =C2=A0 std::move(my_clone_ptr), f);

=C2=A0 =C2=A0 now suddenly all references you got by calling `*my_clone_ptr= ` somewhen
=C2=A0 =C2=A0 before
=C2=A0 =C2=A0 might or might not be invalid,

=C2=A0 Actually, the standard guarantees that it isn't valid. Your
=C2=A0 `move(my_clone_ptr)` will move-construct the `init` parameter of
=C2=A0 `accumulate`. However, the standard says:

=C2=A0 > Computes its result by initializing the accumulator acc with th= e initial
=C2=A0 value init

=C2=A0 This means that it creates a new `T` called `acc`, which is initiali= zed by
=C2=A0 the `init` value. Therefore, it will initialize `acc` by copy. `init= ` will
=C2=A0 hold the original pointer until the end of `accumulate`, when it wil= l be
=C2=A0 destroyed. What will be returned is `acc`, which is a copy of `init`= ..
=C2=A0 =C2=A0

Apparently clang and gcc interpret this differently: They move it into plac= e due to the std::move (see http://coliru.stacke= d-crooked.com/a/cbe39ffef2ebf716).

So in case of clang/gcc in my example the call to std::accumulate wouldn= 9;t invalidate existing references. But who knows, maybe some implementer o= f the standard library will interpret the requirements the same way you did= and actually perform a copy. But only forgetting to `return std::move(acc)= ;` in the lambda used for `std::accumulate` and using just `return acc;` re= sults in a copy.

This is the entire point: When even very experienced people are not able to=
predict what will happen, how is this a good feature? It is just too hard t= o
use correctly.


=C2=A0 =C2=A0 even though I moved the original clone_ptr into
=C2=A0 =C2=A0 the algorithm to ensure that it doesn't get copied.

=C2=A0 Replace `clone_ptr` with `any`. Or `vector`. Many types have this pr= oblem
=C2=A0 with `accumulate`; I don't see why adding one more will hurt any= thing.

 This is because these types don't act as pointers; you're not suppo= sed to store references to individual elements of a vector or a std::any, w= hereas the interface of this copy_ptr is designed to do exactly that, even = though it is dangerous/unpredictable.

The only way to get around that issue is to not have additional references = to the pointee, but then there is no need to have the smart pointer interfa= ce and you can just use `indirect<T>`.


Finishing touches to `polymorphic_valu= e` (formerly know as `indirect`) are being made here https://github.com/jbcoe/polymorphic_value= .

=C2=A0

=C2=A0 --
=C2=A0 You received this message because you are subscribed to the Google G= roups
=C2=A0 "ISO C++ Standard - Future Proposals" group.
=C2=A0 To unsubscribe from this group and stop receiving emails from it, se= nd an
 =C2=A0 email to [1]std-proposals+unsubscribe@isocpp.org.
=C2=A0 To post to this group, send email to [2]std-proposals@isocpp.org.
=C2=A0 To view this discussion on the web visit
 =C2=A0 [3]https://groups.google.com/a/isocpp.org/d/msgid/std= -proposals/cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org.=

References

=C2=A0 Visible links
=C2=A0 1. mailto:std-proposals+unsubscribe@isocpp.org
=C2=A0 2. mailto:std-proposals@isocpp.org
=C2=A0 3. https://grou= ps.google.com/a/isocpp.org/d/msgid/std-proposals/cb822c5c-fc50-48= e5-ad60-fdb14580329c%40isocpp.org?utm_medium=3Demail&utm_sour= ce=3Dfooter

--
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.g= oogle.com/a/isocpp.org/d/msgid/std-proposals/20161217210804.GA109= 67%40manuel-ThinkPad-L440.localdomain.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_eUtvYsPri= PV-QSLED4Taxde1ShCMOuqpMm924JGVyzw%40mail.gmail.com.
--f403045dd96047ae270543e14cbc-- .