220 31727 <86aeb556-e0d7-4d68-b553-1b4163461473@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Complexities caused by using unique_ptr and move semantics Date: Fri, 24 Mar 2017 14:57:11 -0700 (PDT) Lines: 360 Approved: news@gmane.org Message-ID: <86aeb556-e0d7-4d68-b553-1b4163461473@isocpp.org> References: <46a85060-631b-49e5-94f3-ab07429d8085@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_856_1014739906.1490392631298" X-Trace: blaine.gmane.org 1490392638 1758 195.159.176.226 (24 Mar 2017 21:57:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Mar 2017 21:57:18 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCDODCNR2QPRBOFM23DAKGQEMAD3EBY@isocpp.org Fri Mar 24 22:57:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crXCl-0007pf-4q for gclcip-std-proposals@m.gmane.org; Fri, 24 Mar 2017 22:57:07 +0100 Original-Received: by mail-yw0-f198.google.com with SMTP id h11sf4660146ywa.5 for ; Fri, 24 Mar 2017 14:57:13 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=EoXg6EeAhOaXnh3E5GI1hH8a/hnvUJ5uXk1w20OPHPs=; b=IpM3KwLdPGgg/7Woxbadma7j2tAEmCiuyE0FK5nHVw0tNf3uOHVr5UJo4ZKUF3ot8z ZxuS1mSTGsUkCfogTm0YSNhxl6Y//CrpaJUfV9ApQ5z28RL7JEjRyCkIz+UiECvN7rq0 ZUScWoP81SOIacq/UPtmlbUz1Re1lPn030woeDyymAfiyLIUGlgZKjgHeveLIDbxPf1W aVgGdyokijuPM/22WSrKUHeCn64hGcxx+VWgQ1y33Sas4TyQ4vd9odwfGvJGLvBcjYUw DeR7lBX1gammp5j0AgqezHA+VU2Nr2a0oCKxyqr/KR3XJyw6clbm+3XG+SpglJfmv0Lq 7GCw== 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=EoXg6EeAhOaXnh3E5GI1hH8a/hnvUJ5uXk1w20OPHPs=; b=qPvH7OL0QE2ho871hN4T8ffRpa7+3/CNbxCDZG8j1yizCrsFmOXj7d5NL6NfCYNmX/ 5jUPrDTCm4HA2aaVX1wcFOukJ6O3BaEmoVR3cidD+bF9Z2n/DztVoQfNWrHSICdvZdlt IMUK8/vGt8qjN15dJmd9EpGA1U7ERoTSTJvCa7xAvF2I45cJ6c+41r1INBuc5iQKkPLM HV7XStzlp2Br5gdWglVudVvovCmisGwWG1/4FnbXD+J8wlIx9ZK3h21NqAaXLidGyd7d m4VfahvopbolNDW2AM6I8fDuDAOKagm33JO0kPVmt1TZF1qYnO+3E8bWH2dt6H2nczF5 eDDQ== 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=EoXg6EeAhOaXnh3E5GI1hH8a/hnvUJ5uXk1w20OPHPs=; b=KwIVNLonOn1XZ/rgwCrKaoKDpj8JIPfRBMTdWa3LPmpZyf8xNLyJ39cZEZUoTX96QX pI9ZPiLXyLMnPuqH6nVxnVliFwYKAAEwEabVVhM59jBmZuc/y7oewY1ywAFoxo9CBBeL 6H1PSgjNhS+rBxIHphBurcyaA9Yi7Uo0+FO8/Uei9XsdJ3wi54bNsmgrQLmF/Yq/E7Iv FQboORfGMh57KMl7L+/gf7jIHewPbf83mAgEs4jMRnRf+z0LykwCyBkwgxi0CY1kELgX XWkAiTUoNU3tdrlOyG3magUIZDPSMWclMjPordGUBS+6KODtA8mx3p96lBWjP0a0f7w6 g8ow== X-Gm-Message-State: AFeK/H0PJIKABB6IPpWkNcw98Uvkwk2OcL+jbj/nEgFbYe+xHVwf+Q9VyIl1JxIX3sPRQg== X-Received: by 10.129.111.65 with SMTP id k62mr3451784ywc.8.1490392632752; Fri, 24 Mar 2017 14:57:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.3 with SMTP id a3ls8169040ota.23.gmail; Fri, 24 Mar 2017 14:57:11 -0700 (PDT) X-Received: by 10.157.15.162 with SMTP id d31mr1035037otd.0.1490392631910; Fri, 24 Mar 2017 14:57:11 -0700 (PDT) In-Reply-To: <46a85060-631b-49e5-94f3-ab07429d8085@isocpp.org> X-Original-Sender: Sean.Middleditch@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:31727 Archived-At: ------=_Part_856_1014739906.1490392631298 Content-Type: multipart/alternative; boundary="----=_Part_857_1938372957.1490392631299" ------=_Part_857_1938372957.1490392631299 Content-Type: text/plain; charset=UTF-8 On Thursday, March 23, 2017 at 9:38:19 AM UTC-7, Matthew Fioravante wrote: > > 1. Its too easy to accidentally use a moved from object by mistake > This is a problem with C++'s move semantics (e.g., non-destructive move and unspecific states). These problems have been discussed plenty of times before, particularly in destructive-move threads. One solution in the works may be contract programming. Some of the proposals allow a function to set a post-condition state on an object which can be verified by a compiler or static analysis in a pre-condition. e.g., unique_ptr might have something like: [[post_condition(src): empty] unique_ptr(unique_ptr&& src); [[pre_condition(this): !empty] unique_ptr::operator->(); Such a setup can further hypothetically address other issues like accidental dereferencing of default-constructed unique_ptrs. As well as a wide host of other issues. > 2. unique_ptr and T* being different types can cause pessimizations > because of language rules. > I personally most see this as a problem caused by a lack of generators, or more specifically at the lack of range concepts (which of course are in the works). You usually don't want to require specifically a vector nor specifically a pointer of any kind. You want to return an object that can be enumerated to produce references to T objects. The vector itself or unique_ptr vs raw pointers is an implementation detail that callers should not have to care about. With range concepts, this all still has to be a template of course, but you don't have to over-worry about the specifics while using the interface. With generators, this can be abstracted without templates (though perhaps at a runtime cost). Basically, you want to write something like: iterable foo::get_things() { return make_iterable(_things, [](auto& p){ return *p; }); } so user code looks unanimously like so: for (auto& val : f.get_things()) do_stuff_with(val); that specific case can be implemented as a set of "mapping_iterator" (an iterator that returns the result of a wrapped iterator filtered through a function) stored in a range, but there'd likely need to be something more general to cover more use cases. I don't know for sure if such functionality is in the ranges ts anywhere, but I'd honestly be surprised if it wasn't. > > Of course its a good thing that these types are different. One is an owner > and one is not. Using a different type means we can enlist the help of the > compiler to enforce correctness. > > Sometimes I have a container with keeps a set of unique_ptrs, and I want > to view that set. > > class OwningContainer { > public: > array_view> getThings() const { return _things; > } > private: > std::vector> _things; > }; > > class NonOwningContainer { > public: > array_view getThings() const { return _things; } > private: > std::vector _things; > }; > > //Out of line function, maybe lives in a 3rd party library. > void f(array_view things); > > void g(const OwningContainer& c){ > f(c.getThings()); //Compiler Error > } > void h(const NonOwningContainer& c) { > f(c.getThings()); //Ok > } > > The getThings() method of OwningContainer and NonOwningContainer methods > have the exact same semantics. We're getting a const view of the stored > thing pointers. The returned objects are even bitwise and machine code > (after optimization) identical, but are "marked up" by the compiler with > different types. > > From the limited perspective of the code calling getThings(), whether or > not the container owns the pointers is an implementation detail. The caller > does not and should not care whether the pointers are stored raw, > unique_ptr. He just wants to view the collection and do something with it. > > The big problem here is that the return types of getThings() are > different. This means that in a generic context, you need to start > introducing templates in order to handle all possible pointer types. Adding > templates complicates the code and slows down compile times. > > Also since const unique_ptr and const T* are semantically and even > bitwise identical, using templates here will unnecessarily bloat your code > with 2 functions that do the exact same thing. This increases your binary > size and puts more pressure on the icache. > > In this example, we must change f() to be a template. Even though the > actual compiled down machine code will be identical. The biggest problem I > have with this example is that the problem comes from artificial language > rules and not physical limits about how hardware and memory works. That > goes against the zero overhead principle of C++. > > In order to avoid making f() a template here, there are a few options > today we can try with OwningContainer: > 1. Return vector by value, doing a copy and memory allocations at > every call. (very slow) > 2. Store a second vector inside OwningContainer, keep it in sync > with the unique_ptr version, and return it in getThings(). (twice memory > usage, slow, complicated, error prone) > 3. Abandon unique_ptr inside of OwningContainer, and go back to manually > managing the memory. (error prone and greatly increases development time) > > Possible solutions to this include: > 1. Add some kind of way to alias a unique_ptr into a T*. Letting me > essentially convert an array_view> to array_view T>. In terms of how the implementation actually works on the machine, this > is a trivial no-op. In terms of language rules its a complete nightmare. > 2. Provide a specialized unique_vector which essentially operates like > vector>, but exposes T* in its const interface. Then we can > construct array_view over vector and unique_vector. Hiding > the ownership implementation details and avoiding the need to for > artificial templates. This would solve the immediate example I've shown, > but I'm not sure if its too specific and leaves out other similar > situations. > > How would you solve these 2 issues? > > Have you seen any other complexities show up in your code from adopting > unique_ptr? > -- 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/86aeb556-e0d7-4d68-b553-1b4163461473%40isocpp.org. ------=_Part_857_1938372957.1490392631299 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, March 23, 2017 at 9:38:19 AM UTC-7, Matthew F= ioravante wrote:
1. Its too easy to accidentally use a moved from object by mistake

This is a problem with C++'s move = semantics (e.g., non-destructive move and unspecific states). These problem= s have been discussed plenty of times before, particularly in destructive-m= ove threads.

One solution in the works may be cont= ract programming. Some of the proposals allow a function to set a post-cond= ition state on an object which can be verified by a compiler or static anal= ysis in a pre-condition. e.g., unique_ptr might have something like:
<= div>
=C2=A0 [[post_condition(src): empty]
=C2=A0 un= ique_ptr(unique_ptr&& src);

=C2=A0 [[pre_c= ondition(this): !empty]
=C2=A0 unique_ptr::operator->();
=

Such a setup can further hypothetically address other i= ssues like accidental dereferencing of default-constructed unique_ptrs. As = well as a wide host of other issues.
=C2=A0
2. unique_ptr<T> a= nd T* being different types can cause pessimizations because of language ru= les.

I personally most see this= as a problem caused by a lack of generators, or more specifically at the l= ack of range concepts (which of course are in the works).

You usually don't want to require specifically a vector nor spe= cifically a pointer of any kind. You want to return an object that can be e= numerated to produce references to T objects. The vector itself or unique_p= tr vs raw pointers is an implementation detail that callers should not have= to care about.

With range concepts, this all stil= l has to be a template of course, but you don't have to over-worry abou= t the specifics while using the interface.

With ge= nerators, this can be abstracted without templates (though perhaps at a run= time cost).

Basically, you want to write something= like:

=C2=A0 iterable<T&> foo::get_thin= gs() { return make_iterable(_things, [](auto& p){ return *p; }); }
<= /div>

so user code looks unanimously like so:
=
=C2=A0 for (auto& val : f.get_things())
=C2=A0= =C2=A0do_stuff_with(val);

that specific case can = be implemented as a set of "mapping_iterator" (an iterator that r= eturns the result of a wrapped iterator filtered through a function) stored= in a range, but there'd likely need to be something more general to co= ver more use cases.

I don't know for sure if s= uch functionality is in the ranges ts anywhere, but I'd honestly be sur= prised if it wasn't.
=C2=A0

Of course its a good = thing that these types are different. One is an owner and one is not. Using= a different type means we can enlist the help of the compiler to enforce c= orrectness.

Sometimes I have a container with keep= s a set of unique_ptrs, and I want to view that set.

= class <= span style=3D"color:#606">OwningContainer= {
= =C2=A0public:
=C2=A0 array_view<const unique_ptr<Thing>><= span style=3D"color:#000"> getThings() const { return _things;= }
=C2=A0private:
=C2= =A0 std::vector<unique_ptr<Thing>> _things;
};

class NonOwningContai= ner {
=C2=A0public:
=C2=A0 array= _view<const Thing*> getThings() const { return _things; }
=C2=A0private:
=C2=A0 std<= span style=3D"color:#660">::vector= <Thing*> _thing= s;
<= /span>};
//Out of line function, maybe lives in = a 3rd party library.
void f(array_view<const Thing*> things<= span style=3D"color:#660">);

void g(const= OwningContain= er&= c){=C2=A0 f(c.ge= tThings()); //Compiler Error
}
void h(const NonOwningContainer& c) {
=C2=A0 f(c.getThings());<= span style=3D"color:#000"> //Ok
}

The getThings() method of OwningContainer and NonOwningCo= ntainer methods have the exact same semantics. We're getting a const vi= ew of the stored thing pointers. The returned objects are even bitwise and = machine code (after optimization) identical, but are "marked up" = by the compiler with different types.

From the lim= ited perspective of the code calling getThings(), whether or not the contai= ner owns the pointers is an implementation detail. The caller does not and = should not care whether the pointers are stored raw, unique_ptr. He just wa= nts to view the collection and do something with it.

The big problem here is that the return types of getThings() are differe= nt. This means that in a generic context, you need to start introducing tem= plates in order to handle all possible pointer types. Adding templates comp= licates the code and slows down compile times.

Als= o since const unique_ptr<T> and const T* are semantically and even bi= twise identical, using templates here will unnecessarily bloat your code wi= th 2 functions that do the exact same thing. This increases your binary siz= e and puts more pressure on the icache.

In this ex= ample, we must change f() to be a template. Even though the actual compiled= down machine code will be identical. The biggest problem I have with this = example is that the problem comes from artificial language rules and not ph= ysical limits about how hardware and memory works. That goes against the ze= ro overhead principle of C++.

In order to avoid ma= king f() a template here, there are a few options today we can try with Own= ingContainer:
1. Return vector<Thing*> by value, doing a co= py and memory allocations at every call. (very slow)
2. Store a s= econd vector<Thing*> inside OwningContainer, keep it in sync with the= unique_ptr version, and return it in getThings(). (twice memory usage, slo= w, complicated, error prone)
3. Abandon unique_ptr inside of Owni= ngContainer, and go back to manually managing the memory. (error prone and = greatly increases development time)

Possible solut= ions to this include:
1. Add some kind of way to alias a unique_p= tr<T> into a T*. Letting me essentially convert an array_view<cons= t unique_ptr<T>> to array_view<const T>. In terms of how the= implementation actually works on the machine, this is a trivial no-op. In = terms of language rules its a complete nightmare.
2. Provide a sp= ecialized unique_vector<T*> which essentially operates like vector<= ;unique_ptr<T>>, but exposes T* in its const interface. Then we ca= n construct array_view<const T> over vector<T> and unique_vecto= r<T>. Hiding the ownership implementation details and avoiding the ne= ed to for artificial templates. =C2=A0This would solve the immediate exampl= e I've shown, but I'm not sure if its too specific and leaves out o= ther similar situations.

How would you solve these= 2 issues?

Have you seen any other complexities sh= ow up in your code from adopting unique_ptr?

--
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/86aeb556-e0d7-4d68-b553-1b4163461473= %40isocpp.org.
------=_Part_857_1938372957.1490392631299-- ------=_Part_856_1014739906.1490392631298-- .