220 29889 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: New smart pointer: CopyConstructible and CopyAssignable flavor of unique_ptr Date: Sat, 17 Dec 2016 12:35:03 -0800 (PST) Lines: 206 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_928_236439197.1482006903433" X-Trace: blaine.gmane.org 1482006908 20181 195.159.176.226 (17 Dec 2016 20:35:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 20:35:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB6GC23BAKGQEVMEEDDY@isocpp.org Sat Dec 17 21:35:04 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cILh6-0003oS-TF for gclcip-std-proposals@m.gmane.org; Sat, 17 Dec 2016 21:35:01 +0100 Original-Received: by mail-pg0-f72.google.com with SMTP id a190sf831879pgc.0 for ; Sat, 17 Dec 2016 12:35:05 -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=YEaOvCC+YNblvo9441uuQ70G6ZLS0/5AgORsSRbNa+E=; b=M27lpkpSoOFDZGPC+McgiHLUy58Tmsi/bG7X+jyvScz1ycbTsEvSTnIxeM8Oiu4F4F ONlNJg6IZNheK1KA+x1AvNa8RkzBugtHKobpk6ZLV4RsqavOQzIRSKFoNHKrh3QsIL1V rFQnYW1mhCln3DV1OHAoJCWQgva27XUYZa7dPrHCi8O0MPozhLA1gJFYz9k/D2GD0lwN 5JuIetzlDJPPWWNax3YusahK3w9/4hwtFUzmfkEh1Nz3HFsgmU/vA5xuLunEsZmYESrV WgE3qOMNq9pqfksl8NlvQovvUSI+bbBuhGO5PcRUZLEYnWpX/I8LcMlmBdlGJvleBJBw 3LKA== 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=YEaOvCC+YNblvo9441uuQ70G6ZLS0/5AgORsSRbNa+E=; b=Kzl4yDKwt1BeZ/3+sOhTEqV9nJ4a90n28/jv2bRLZ2dtiHONScJldmbOh4lslo0H2d my0878NQvUVQDI2MhyVmZDBgjGct2HdP6Avi7OzFB68MLjGdgNh0DGNOJ2x1+OEGIwtN YwEmEezFluzPvSDbpI6+/7FPJhRPEmAu3vQlsg+TuV2cTvaZMvSOHMuao0ItNHAlZKvI QykhoVZZUlliTrhQxcFK+9Ujfq7QImgjU3lIEG8a7x/LWisHZceVdhaW9frdBDzZdRKj uT24AJ90Ypmv6KnaA5Ulg92e1wNV2833dpv3dQ1s9idaGIhLmQvdGdWjpxQTgPgx4Exy b4QQ== 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=YEaOvCC+YNblvo9441uuQ70G6ZLS0/5AgORsSRbNa+E=; b=OykZ57IOq6oaObjuSwjZDkVsCr4022DBDD1C63splD3pwNysYGT4u/TOEgNOwVnef4 /WpaJ5LD8DkdBqEr90oxWEC2R/npFhyQLHkN9c9dKO5obcUGr4CQkCoEomtRbqzT7W8S tKAQ7AcL/CoDx0FbfJv7g9ygB53PDivSWPb5GFooBl3XyyRlBdoOpfiysn9Ch5Lml5u/ 1b+RsSSFn2NKLav9bCq9D7MTy8sDKUx9F8mfdzhbuPe9kGVQvazEfCqxztOv95WyN4Iz KL0MYfaCt4Cw47sUnkTDezZZp35+1e8gKfDq3qLs6slvA3CjVxWrufGwahCzr/kolLJl QJfA== X-Gm-Message-State: AIkVDXLrzXRt4PN8Ddng1D7aS0POlQT/pDMvFrrSS//cwKe0WWpb/VQxdwKc2hMmEQltCQ== X-Received: by 10.99.176.69 with SMTP id z5mr658769pgo.82.1482006904762; Sat, 17 Dec 2016 12:35:04 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.45.195 with SMTP id g61ls10622027otb.37.gmail; Sat, 17 Dec 2016 12:35:04 -0800 (PST) X-Received: by 10.157.8.134 with SMTP id 6mr523915otf.17.1482006903976; Sat, 17 Dec 2016 12:35:03 -0800 (PST) In-Reply-To: <20161217192812.GA17421@manuel-ThinkPad-L440.localdomain> X-Original-Sender: jmckesson@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:29889 Archived-At: ------=_Part_928_236439197.1482006903433 Content-Type: multipart/alternative; boundary="----=_Part_929_1421785983.1482006903433" ------=_Part_929_1421785983.1482006903433 Content-Type: text/plain; charset=UTF-8 On Saturday, December 17, 2016 at 2:29:01 PM UTC-5, Manuel Bergler wrote: > > On Sat, Dec 17, 2016 at 10:43:08AM -0800, Nicol Bolas wrote: > > On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel Bergler > wrote: > > > > On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bolas wrote: > > > > > > After all, such copying behavior won't break most standard > library > > types. > > > `vector` will work as expected, as will `any`, > > > `optional`, `variant`, and so forth. > > > > > > > It would certainly work with the STL types, but I'm fairly certain > you > > might get very different results when using these in STL algorithms. > > With some implementations references to the pointees might be > preserved > > since the algorithm doesn't copy the clone_ptr whereas others might > > perform a copy, hence invalidating existing references or at least > > having them point to a different object than the one returned from > the > > algorithm. > > > > Which is no different from passing a value type that gets copied, then > > expecting the copies to be modifying the original value. > > > > 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`. > 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. -- 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/cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org. ------=_Part_929_1421785983.1482006903433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 2:29:01 PM UTC-5, Manuel= Bergler wrote:
On Sat, Dec 17,= 2016 at 10:43:08AM -0800, Nicol Bolas wrote:
> =C2=A0 On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel = Bergler wrote:
>
> =C2=A0 =C2=A0 On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bola= s wrote:
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > =C2=A0 After all, such copying behavior won'= ;t break most standard library
> =C2=A0 =C2=A0 types.
> =C2=A0 =C2=A0 > =C2=A0 `vector<clone_ptr>` will work as e= xpected, as will `any`,
> =C2=A0 =C2=A0 > =C2=A0 `optional<clone_ptr>`, `variant<= ;clone_ptr>`, and so forth.
> =C2=A0 =C2=A0 >
>
> =C2=A0 =C2=A0 It would certainly work with the STL types, but I= 9;m fairly certain you
> =C2=A0 =C2=A0 might get very different results when using these in= STL algorithms.
> =C2=A0 =C2=A0 With some implementations references to the pointees= might be preserved
> =C2=A0 =C2=A0 since the algorithm doesn't copy the clone_ptr w= hereas others might
> =C2=A0 =C2=A0 perform a copy, hence invalidating existing referenc= es or at least
> =C2=A0 =C2=A0 having them point to a different object than the one= returned from the
> =C2=A0 =C2=A0 algorithm.
>
> =C2=A0 Which is no different from passing a value type that gets c= opied, then
> =C2=A0 expecting the copies to be modifying the original value.
> =C2=A0 =C2=A0

It is different.

Consider for example something like

=C2=A0 =C2=A0 my_obj =3D std::accumulate(input.begin(), input.end(), st= d::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=A0some_function);

Afterwards references to my_obj will still be valid and correctly point= to the
modified object.

On the other hand, if you have

=C2=A0 =C2=A0 auto f =3D [&someObj] (auto& acc, auto const&= in) -> decltype(auto) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 acc->doSomethingModifyingThePointee= Obj(in);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 someObj.doSomething(acc) =C2=A0// note I re= ally 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 // so I need to pass in th= e 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 // and not the pointee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::move(acc);
=C2=A0 =C2=A0 };

=C2=A0 =C2=A0 my_clone_ptr =3D 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 stand= ard guarantees that it isn't valid. Your `move(my_clone_ptr)` wi= ll move-construct the `init` parameter of `accumulate`. However, the standa= rd says:

> Computes its result by initializing the accumulator ac= c with the initial value init

This means that it creates a new `T` c= alled `acc`, which is initialized by the `init` value. Therefore, it will i= nitialize `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`.
=C2=A0
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.

--
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/cb822c5c-fc50-48e5-ad60-fdb14580329c= %40isocpp.org.
------=_Part_929_1421785983.1482006903433-- ------=_Part_928_236439197.1482006903433-- .