220 31712 <46a85060-631b-49e5-94f3-ab07429d8085@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Complexities caused by using unique_ptr and move semantics Date: Thu, 23 Mar 2017 09:38:19 -0700 (PDT) Lines: 547 Approved: news@gmane.org Message-ID: <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_184_1227975421.1490287099071" X-Trace: blaine.gmane.org 1490287108 23623 195.159.176.226 (23 Mar 2017 16:38:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Mar 2017 16:38:28 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDELF54RTIGRB67TZ7DAKGQEX6QB4ZY@isocpp.org Thu Mar 23 17:38:23 2017 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 1cr5kd-000584-BE for gclcip-std-proposals@m.gmane.org; Thu, 23 Mar 2017 17:38:15 +0100 Original-Received: by mail-pf0-f198.google.com with SMTP id p189sf318541414pfp.5 for ; Thu, 23 Mar 2017 09:38:21 -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: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=uyxFPkQok43dgAwRGBx9kuL1kE8GNFl/jyUmgfqqmJc=; b=iffhh6wxFJVEkHFXzKEzYXDb5+w185tx0oaDwiXNaR4PaUZcnCicNJv3BbS9AMJUaY txngW/ZaEst0fiS3ksH+UqFTjMgvWTL/QiLLB43C7AkPoy83Y2CfD9YS3XcwJAnc2Jmf eTIVGiV8AOnn6Lbrq3w7kX+N/fJhdxtLbahiZIxI6rRDBf1Hpg/EK9WZbEPyMA9YY7+l 17xJ5pPbk0SMRSGZlaK2URy0xzldFjdo2rVQ8tbv/djEH+z3oFaHwG9VEAscBkcMp065 kEZ+F82aGAsOL2VLLJiCXzUFpLA/EQ0JWpficE0Sar+3szhS52xYgKmgBiLl7tut1jle oupw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id: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=uyxFPkQok43dgAwRGBx9kuL1kE8GNFl/jyUmgfqqmJc=; b=ZcPrKDj3+DFN/3YuderOL8ddG6grX41D0njNu4WEtkqDoahIeSt646U0VdS0+5YHMp oe1SGY2rFxolO8DJW32Vn9lxB1W32S7NkBqi9nrxvL++V4JNj9fKYb9ejwKU5kJk6akD x2aYXNZnJ+Gl+ylo+dh9CZg8Y5UkHYWFRW94yv3fFWyxpdxoNE4K2wc2FstK8mY/j7NC cYwvfLFxd5RZCrkgqikzH2ZxWXd16KCvYMigw2E52oMgYFvmZST7pXBZBPOp+MXx4uex z4GAa63xhZXEtQkiYlQtnMo6Gep3pKdoa966fSSMIdbJiNoAUSz6Vgrho63ZffgzSqxR fwww== 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: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=uyxFPkQok43dgAwRGBx9kuL1kE8GNFl/jyUmgfqqmJc=; b=Oah/3nTc1eWsdgP9Gw9i7Vtzbr1RA75Detvu9Ff1cRJvisVhly/ulfCaK/0ZbLexFu CoNELp1Isk5Lo1oOMzlI8utiC8/ub6vW6DAU8gN+GkN6DSxBRV/dMKsFQtdC93B7HpWW OF3kf2+ml3FD/Y2ksmcGypB9+Nyr43O9BiCrz/1Ad8m4eN0cFxdDh9HasNAszQIx18Vb VYc5lRvsQLX37VLeU4/4+IVlvPN5lauGoY/mwCD4rk6dYm4gawwFibR7LJf6iFScg8G2 hbZlPZbntc6FG3cCRwFOMY1eBULPtrCXouT+aes0Vs1jb27kt929EEGPDJER5sJc2TAm OVaQ== X-Gm-Message-State: AFeK/H1g8t1aQIhY17cqO9okqf+LLEPJiDIAh3e/+YMMSnKkvRIbc2mA1BpBQnJc9O5qkA== X-Received: by 10.99.115.92 with SMTP id d28mr1083942pgn.124.1490287100875; Thu, 23 Mar 2017 09:38:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.33.91 with SMTP id l27ls529573otd.41.gmail; Thu, 23 Mar 2017 09:38:19 -0700 (PDT) X-Received: by 10.157.22.200 with SMTP id s8mr314241ots.16.1490287099713; Thu, 23 Mar 2017 09:38:19 -0700 (PDT) X-Original-Sender: fmatthew5876@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:31712 Archived-At: ------=_Part_184_1227975421.1490287099071 Content-Type: multipart/alternative; boundary="----=_Part_185_1235225468.1490287099072" ------=_Part_185_1235225468.1490287099072 Content-Type: text/plain; charset=UTF-8 I don't have a proposal or a real solution. This is more intended to highlight some of the problems related to unique ownership and move semantics. 1. Its too easy to accidentally use a moved from object by mistake Consider this code: void Container::addThing(unique_ptr p) { this->_things.push_back(std::move(p)); if(logging_enabled) { std::cout << "Added thing " << p->name() << " " << p->foo() << " " << p-> bar() << std::endl; } return; } I've seen this kind of bug many times. Its very easy to write and the compiler provides no help to you. Even better since the bug is hidden when logging is disabled, it could easily pass into production. Its also somewhat of an expert problem when explaining to novices. Now here's an attempt to fix the bug the right way. But we still have a mistake! Again no help from the compiler. Also unless you're really paying attention, a quick skim through the code will likely miss this one. void Container::addThing(unique_ptr p) { auto* pc = p.get(); this->_things.push_back(std::move(p)); if(logging_enabled) { std::cout << "Added thing " << pc->name() << " " << pc->foo() << " " << p ->bar() << std::endl; } return; } After we move p into _things, we never need to touch p again. Unfortunately in this case and many others, we can't really introduce scopes with {} to eliminate p from the local namespace and prevent these kinds of bugs. A possible solution here might be some kind of [[discard]] attribute or a std::move_final() which is std::move() + [[discard]] together. So that the compiler would warn on any use of p after the move. 2. unique_ptr and T* being different types can cause pessimizations because of language rules. 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. 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/46a85060-631b-49e5-94f3-ab07429d8085%40isocpp.org. ------=_Part_185_1235225468.1490287099072 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't have a proposal or a real solution. This is mo= re intended to highlight some of the problems related to unique ownership a= nd move semantics.

1. Its too easy to accidentally use a= moved from object by mistake

Consider this code:<= /div>

=
void Co= ntainer::<= /span>addThing(unique_ptr<Thing> p) {
=C2=A0 this->= ;_things.push_back(std::move(p));<= br>=C2=A0 = if(= logging_enabled) {
=C2=A0 =C2=A0std::cout << "Added thing " << p->name()= <<<= /span> " "= << p->foo() << &= quot; " <<= ; p= ->bar() << std::endl;
=C2=A0 }
=C2= =A0 return= ;
}

I've seen this kind of bug many ti= mes. Its very easy to write and the compiler provides no help to you. Even = better since the bug is hidden when logging is disabled, it could easily pa= ss into production. Its also somewhat of an expert problem when explaining = to novices.

Now here's an attempt to fix the b= ug the right way. But we still have a mistake! Again no help from the compi= ler. Also unless you're really paying attention, a quick skim through t= he code will likely miss this one.

void Container::addThing(unique_ptr<Thing> p= ) {
=C2=A0 auto* pc =3D p.get();
=C2=A0 this->_things.push_back(std::move(p));
=C2=A0 if(logging_enabled) {
=C2=A0 =C2=A0std::cout << "Added thing " << pc-&= gt;name() << " " << pc->foo() <&= lt; " " << p->bar() << std::e= ndl;
=C2=A0 }
=C2=A0 return;
}

After we move p into _things, we never n= eed to touch p again. Unfortunately in this case and many others, we can= 9;t really introduce scopes with {} to eliminate p from the local namespace= and prevent these kinds of bugs.=C2=A0

A possible solution here might be some kind of [[disca= rd]] attribute or a std::move_final() which is std::move() + [[discard]] to= gether. So that the compiler would warn on any use of p after the move.=C2= =A0


2. unique_ptr<T> and T* being diff= erent types can cause pessimizations because of language rules.
<= br>
Of course its a good thing that these types are different. On= e is an owner and one is not. Using a different type means we can enlist th= e help of the compiler to enforce correctness.

Som= etimes I have a container with keeps a set of unique_ptrs, and I want to vi= ew that set.

class OwningContainer {<= br>=C2=A0p= ublic:
=C2=A0 array_view<const unique_ptr<Thing>= ;> getT= hings() const { return _things; }
=C2=A0private:
=C2=A0 std::vector<unique_ptr<Thing>> _things;
};

c= lass NonOwningContai= ner {
=C2=A0public:
=C2=A0 array_view<<= /span>const Thing*> getThings() const { return<= /span> _things; }
=C2=A0private:
=C2=A0 std::vector<Thing*>= _things;<= /span>
= };

//Out of line function, may= be lives in a 3rd party library.
void f(array= _view<<= /span>const Thing*> things);

void g(const OwningC= ontainer&a= mp; c){
=C2=A0 f(c.getThings()); //Compiler Error
}
= void h(const NonOwningContainer& c) {
=C2=A0 f(= c.<= span style=3D"color: #000;" class=3D"styled-by-prettify">getThings()); //Ok
}

The getThings()= method of OwningContainer and NonOwningContainer methods have the exact sa= me 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 ty= pes.

From the limited perspective of the code call= ing getThings(), whether or not the container owns the pointers is an imple= mentation detail. The caller does not and should not care whether the point= ers are stored raw, unique_ptr. He just wants to view the collection and do= something with it.

The big problem here is that t= he return types of getThings() are different. This means that in a generic = context, you need to start introducing templates in order to handle all pos= sible pointer types. Adding templates complicates the code and slows down c= ompile times.

Also since const unique_ptr<T>= 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 i= cache.

In this example, we must change f() to be a= template. Even though the actual compiled down machine code will be identi= cal. 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 a= re a few options today we can try with OwningContainer:
1. Return= vector<Thing*> by value, doing a copy and memory allocations at ever= y call. (very slow)
2. Store a second vector<Thing*> inside= OwningContainer, keep it in sync with the unique_ptr version, and return i= t in getThings(). (twice memory usage, slow, complicated, error prone)
3. Abandon unique_ptr inside of OwningContainer, and go back to manua= lly managing the memory. (error prone and greatly increases development tim= e)

Possible solutions to this include:
1= .. Add some kind of way to alias a unique_ptr<T> into a T*. Letting me= essentially convert an array_view<const unique_ptr<T>> to arra= y_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 com= plete nightmare.
2. Provide a specialized unique_vector<T*>= which essentially operates like vector<unique_ptr<T>>, but exp= oses T* in its const interface. Then we can construct array_view<const T= > over vector<T> and unique_vector<T>. Hiding the ownership = implementation details and avoiding the need to for artificial templates. = =C2=A0This would solve the immediate example I've shown, but I'm no= t sure if its too specific and leaves out other similar situations.

How would you solve these 2 issues?

<= div>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 &= 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/46a85060-631b-49e5-94f3-ab07429d8085= %40isocpp.org.
------=_Part_185_1235225468.1490287099072-- ------=_Part_184_1227975421.1490287099071-- .