220 31746 <0b40f2b6-bb90-4f98-b6fe-cc0ee0e0d76a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Complexities caused by using unique_ptr and move semantics Date: Sat, 25 Mar 2017 10:00:23 -0700 (PDT) Lines: 202 Approved: news@gmane.org Message-ID: <0b40f2b6-bb90-4f98-b6fe-cc0ee0e0d76a@isocpp.org> References: <46a85060-631b-49e5-94f3-ab07429d8085@isocpp.org> <86aeb556-e0d7-4d68-b553-1b4163461473@isocpp.org> <136fc743-bc63-48c8-b1d5-dc4084dd13cf@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2432_1186240992.1490461223763" X-Trace: blaine.gmane.org 1490461237 7985 195.159.176.226 (25 Mar 2017 17:00:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Mar 2017 17:00:37 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDELF54RTIGRBKGE3LDAKGQEVHD7UUA@isocpp.org Sat Mar 25 18:00:31 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crp39-0000Kb-O0 for gclcip-std-proposals@m.gmane.org; Sat, 25 Mar 2017 18:00:24 +0100 Original-Received: by mail-yw0-f199.google.com with SMTP id 203sf27621320ywk.8 for ; Sat, 25 Mar 2017 10:00:25 -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=chxOlI8fHjOuZfiuFtjC8EJ2g2FUSSWNfq6GNhRXxU0=; b=T9BwtkunAo2EZFdW7KA0TOPxe9HStTI/JKdjV7z92U0UFOoLpQIOvnnYkEy5gAFHEY hiHVuRVOC4KEtky9+8KHEFpXOe5m5UREAIn5c51Wy+p1gaVIVZ2EStUxYyUfcRxuGZRG L4GIiKwfI2DyB5boer8El7Q9YcYhOAwTqocwUKd3kckyhrx6R9wXtvVU9aJ4vI8mh09q mNrwJfeiCbNXpj5lyCWYoatafrUVqsOE7cGp9xLkEkvitc764wtHj5zxUGXJ3pe1iqHV ZRrsP4/Z8WJLlPz6r7d2wnPVgaaQllQOGQqWik5IUyxSKfi5JoEjK9cnlXjlLreqikfZ IHVA== 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=chxOlI8fHjOuZfiuFtjC8EJ2g2FUSSWNfq6GNhRXxU0=; b=omdZsA8blxNSHHLrGiaeoRKq+QdMhHj3QXw32J+nNqHxIQ0m6qPVEuiGdlAjCspnkk K/V+S1rCtV7RobANJRys4W+sD15w27rRRtoVJOZGE/71czyIeKS/sG9YFMh4X7bz4xcY Uq6J0nt59Xc35kKfk2a57YfBncWv/9l6+K85PkqHwJEjWSHu3W/SXJjyaRb/893ADnkB OR9NLTgpQOSKl/TV89EEwBKVEKUwdpFLCnHhe+UQzvkcRd0POUdrnvuYF4NNZy+8D1kb biM4Q9ACNRR4vZ6KsOF3H1V2tNuO7l+hAj3qVW/V8If3f5puCWULsYkyV+3v+Rs92wI5 dzQw== 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=chxOlI8fHjOuZfiuFtjC8EJ2g2FUSSWNfq6GNhRXxU0=; b=eiqsF6Csa3sZn+t3zoCM57xHoTICdk438HGvzAs027gNaPGXiBq5DtGEWeTO+sv0C7 AWzG+/AVA3NujmOtETQe5q2fvqjqT1TRmcuzvQUdOrhUlHKMNkKxSEkO7plM5e5ghkCY W8pVBqsFQ55JYZf+dRZmBj6AowXljqyDg3/YWbb6BIsZ/t6+AQBCi8pbPR4CQu6ak93i 5pVCUCJ3/VJ5G7bUpsA5vw91pLNpss2NPENF42dQEhRP+kjTIYNLpcDELvXiWesWkC+h pC1j2VogbsVr6cwxUalU9T/msbhi5x1WTv4v+CG7hX93mFgVMwQQDPTMi1yjH0eLHLS0 20qQ== X-Gm-Message-State: AFeK/H2XBx5lQ7wpILEKL/nUxQckin/K+0LoH22r+ABejRAD9VK3mBnVRWVVxOyIgV7oVg== X-Received: by 10.129.116.85 with SMTP id p82mr4692053ywc.40.1490461225219; Sat, 25 Mar 2017 10:00:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.7.195 with SMTP id 61ls10041822oto.31.gmail; Sat, 25 Mar 2017 10:00:24 -0700 (PDT) X-Received: by 10.157.36.169 with SMTP id z38mr1338126ota.14.1490461224222; Sat, 25 Mar 2017 10:00:24 -0700 (PDT) In-Reply-To: <136fc743-bc63-48c8-b1d5-dc4084dd13cf@isocpp.org> 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:31746 Archived-At: ------=_Part_2432_1186240992.1490461223763 Content-Type: multipart/alternative; boundary="----=_Part_2433_1234684880.1490461223763" ------=_Part_2433_1234684880.1490461223763 Content-Type: text/plain; charset=UTF-8 On Friday, March 24, 2017 at 5:25:51 PM UTC-5, Nicol Bolas wrote: > > On Friday, March 24, 2017 at 5:57:11 PM UTC-4, Sean Middleditch wrote: >> >> 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; }); } >> >> > That's a really bad tradeoff: type-erasing performance plus the cost of > filtering, all just to gain some increased genericity. > > I agree that generic ranges are great and badly needed, but I don't think they apply here. You're actually not gaining anything here doing it this way. You're even losing. The paradigm is backwards (generic outputs instead of inputs). To achieve generic code support, Container only needs to return *something* that looks like a range. The generic caller doesn't care at all what that *something* actually is. An array_view is a range. By returning a very specific range type array_view, you satisfy anyone writing generic code. For free you also satisfy the specific case of someone who is only interested in arrays. You can do everything on an array_view that you can on a generic range. Its easier to debug because you know the actual type returned. By returning a generic object, all you're doing is throwing away useful type information. Lets also not forget the horribly long compiler error messages that will come when this is used wrong. In terms of generic code, its better for inputs to be more generic, and outputs to be more specific (while still fulfilling a generic concept). Generic inputs minimizes the constraints on what I can pass into the API. Specific outputs that match concepts don't provide any limitations, but they can add optimization opportunities and compatibility with other API's which aren't generic. If I don't need the extra information provided by having a specific type, I can just erase it myself when I pass it along to the next generic API. The important point is I had the choice to do the erasure on my end, instead of it being forced upon me by the Container author's getThings(). The great thing about array_view is that it gives you a level of genericity (contiguous ranges), without the heavy handedness of templates. Compile times are fast, no code bloat, out of line compilation. Its also damn efficient. -- 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/0b40f2b6-bb90-4f98-b6fe-cc0ee0e0d76a%40isocpp.org. ------=_Part_2433_1234684880.1490461223763 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, March 24, 2017 at 5:25:51 PM UTC-5, Nic= ol Bolas wrote:
On Friday, March 24, 2017 at 5:57:11 PM UTC-4, Sean Middleditch wrote:
On Thursday, March 23= , 2017 at 9:38:19 AM UTC-7, Matthew Fioravante wrote:
1. Its too easy to accidentally use a mo= ved from object by mistake

This i= s a problem with C++'s move semantics (e.g., non-destructive move and u= nspecific states). These problems have been discussed plenty of times befor= e, particularly in destructive-move threads.

One s= olution in the works may be contract programming. Some of the proposals all= ow a function to set a post-condition state on an object which can be verif= ied by a compiler or static analysis in a pre-condition. e.g., unique_ptr m= ight have something like:

=C2=A0 [[post_condition(= src): empty]
=C2=A0 unique_ptr(unique_ptr&& src);

=C2=A0 [[pre_condition(this): !empty]
=C2=A0 un= ique_ptr::operator->();

Such a setup can furthe= r hypothetically address other issues like accidental dereferencing of defa= ult-constructed unique_ptrs. As well as a wide host of other issues.
<= div>=C2=A0
2. unique_ptr<T> and T* being different types can cause pessimizat= ions 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 th= e works).

You usually don't want to require sp= ecifically a vector nor specifically a pointer of any kind. You want to ret= urn an object that can be enumerated to produce references to T objects. Th= e vector itself or unique_ptr vs raw pointers is an implementation detail t= hat callers should not have to care about.

With ra= nge concepts, this all still has to be a template of course, but you don= 9;t have to over-worry about the specifics while using the interface.
=

With generators, this can be abstracted without templat= es (though perhaps at a runtime cost).

Basically, = you want to write something like:

=C2=A0 iterable&= lt;T&> foo::get_things() { return make_iterable(_things, [](auto&= ; p){ return *p; }); }


That's a really bad tradeoff: type-erasing performance plus = the cost of filtering, all just to gain some increased genericity.

=

I agree that generic ranges are great and= badly needed, but I don't think they apply here.

You're act= ually not gaining anything here doing it this way. You're even losing. = The paradigm is backwards (generic outputs instead of inputs).

To ac= hieve generic code support, Container only needs to return *something* that= looks like a range. The generic caller doesn't care at all what that *= something* actually is. An array_view<T> is a range. By returning a v= ery specific range type array_view<T>, you satisfy anyone writing gen= eric code. For free you also satisfy the specific case of someone who is on= ly interested in arrays. You can do everything on an array_view<T> th= at you can on a generic range. Its easier to debug because you know the act= ual type returned. By returning a generic object, all you're doing is t= hrowing away useful type information. Lets also not forget the horribly lon= g compiler error messages that will come when this is used wrong.

In terms of g= eneric code, its better for inputs to be more generic, and outputs to be mo= re specific (while still fulfilling a generic concept). Generic inputs mini= mizes the constraints on what I can pass into the API. Specific outputs tha= t match concepts don't provide any limitations, but they can add optimi= zation opportunities and compatibility with other API's which aren'= t generic. If I don't need the extra information provided by hav= ing a specific type, I can just erase it myself=C2=A0 when I pass it along = to the next generic API. The important point is I had the choice to do the = erasure on my end, instead of it being forced upon me by the Container auth= or's getThings().

The great thing about array_view<T> is t= hat it gives you a level of genericity (contiguous ranges), without the hea= vy handedness of templates. Compile times are fast, no code bloat, out of l= ine compilation. Its also damn efficient.

--
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/0b40f2b6-bb90-4f98-b6fe-cc0ee0e0d76a= %40isocpp.org.
------=_Part_2433_1234684880.1490461223763-- ------=_Part_2432_1186240992.1490461223763-- .