220 36721 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Static analysis and the future of C++ Date: Sat, 20 Jan 2018 15:54:50 +0100 Lines: 674 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <88864914-82a8-4a8b-bda7-cffd38379edf@isocpp.org> <4fa792ec-1f51-4357-a65a-2ce3c10c60c0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114411780b9ee7056336617d" X-Trace: blaine.gmane.org 1516459984 11076 195.159.176.226 (20 Jan 2018 14:53:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Jan 2018 14:53:04 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBPFQRXJQKGQETKTGZAI@isocpp.org Sat Jan 20 15:52:59 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f71.google.com ([209.85.214.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecuVl-0001yD-6w for gclcip-std-proposals@m.gmane.org; Sat, 20 Jan 2018 15:52:49 +0100 Original-Received: by mail-it0-f71.google.com with SMTP id k19sf5074417ita.8 for ; Sat, 20 Jan 2018 06:54:53 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1516460093; cv=pass; d=google.com; s=arc-20160816; b=V9e5fd6If9XzFXrLF9isc1AIA9qUN41hFsoKx9Z9bFOlT/Mku0ZKnsfzwF0t1z4y6k Fb+fQlSYGDiIuOhm0CUmrs1R10fkFz1WplrizaJ/BiGnfQS6gbPfCIUIE3Lk5lJGj9VY sxwJT1cxTTOOkEqnFyhB19QrjTbOXFJulkftZgCd/8EdxTVGCfeNeUVens1oNlQtW1Rd oTf4hYhokP9h6Nece/oOe8w67fIgsxV7S74HYkuvAnXt0sQHX7SR2O3mlDrWuhy2FUh4 DmdZVA3VNHYopraJvQahr17wF8uTO05mCJUiLYu9gpenSWZr/g7ulA18IMzCBm9snPUr c5+A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=yBgsr51cjaCoPAF7JlSU1cZrMA8B5+29ErQz5SDi5ZQ=; b=lFkf4PEE5qXRnlTRaVcU2GEqP+yk0GpK5cf5BYtrrq2Jpjk7r3bE3ZrC8Wpy9bO5ew cvqjiH2mHvN13MmVMXtWCVL6feP+RAm7FFMAW3nJwQSbT+BrgyUMZKvQlxS3IGZFkaPx keBoT6NoEcYFHam9umwOXSnMhO2MFIuw3LeWnagJ0XDfxQrkSvEe4Rsq79oz9JjcoHvw UCL7HwQTNDpBXWcFNElDCwn5jtkuEPfmxMQIz+qwdY4oiUXxq4OhrrfR42Qk13xNQ15j Q9dcrFT1+asxyN/OSgH1Ow5FFqYmtEdgQ+3jWe4WFc6+MuiA3nNEddjM6sBFyyzuAidZ NO9A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oap22XQg; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=yBgsr51cjaCoPAF7JlSU1cZrMA8B5+29ErQz5SDi5ZQ=; b=GwWO6Dl1tQ2GV6ieb5cboJyRY6GUncHXO4twmNx2r14DZYsm5CL0+Z8uRwENBHjvg6 1nxYBSsJZzYwFtY5IFTGVPp8nPPjcPoQ1l5uM5tGi2wYhtFxu4jA/rmoi/UxGEXsVVqE OKUhPfy4pboFPQRJ20OZNnw77+9MqQG30kb7uGfd7T7OaX56o0M/5wSnn1Qcm7lzhbH3 ANXDt5gS3NH1SxN+Flb9lcg1AqQtcq02dLotXQBp88+boNH6b49q5S5slnR7h/HqpjGJ lMWtZbidBMf29L+2NwaSDy1JbV7rJLzROBpo+BnzvpDo/0MzGXKUWQoUkMRRa1/MuVgH +C7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version: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=yBgsr51cjaCoPAF7JlSU1cZrMA8B5+29ErQz5SDi5ZQ=; b=PC1I1iekKIXWe/S3u2ZnN/fucQluIpBZ5XbLGXoELeYVByJoNMU+bCfnjxZ/YGtM7I X7tTRzf/zdtZsWIhCwTrShorZFet/jrYlM6WWzW6hhAGdFXQlukcXqClIr5BokGkHi6v 3hylAAmyi69lfyAcDQCeazRXcU8akBpof/FCSSijy3IBLPwyNBKStmXsesu9YAjq+TlB Uy/bu7VtiMHlbZPHFkYzgYMeZUK+AGv9vhhEHo5a/oo18eu11yZ0c7W3e8oK7Wrc5NPV 9QsutFzmspU4NAtPCm/oaUkjoMpFxD/LNZPJISzhiClq9ah6oxZwQTy2it1NuTMtal5y cJTQ== X-Gm-Message-State: AKwxyte9TGAzfnsaR92U7exXYqlV18STOxRoiUuKJaZtg+xjhlM+O9Ur cl9RgxNSeGcdcOFzOlay7NWeBw== X-Google-Smtp-Source: AH8x224umEUBjJqlIpbvcm43CQdenz7KNvuIPLZWhfq1DeVOa1wWDmAWV0/ZZ0QXSTAtsWO++kasew== X-Received: by 10.107.152.133 with SMTP id a127mr1550888ioe.47.1516460093270; Sat, 20 Jan 2018 06:54:53 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.73.74 with SMTP id z71ls803060ita.6.gmail; Sat, 20 Jan 2018 06:54:51 -0800 (PST) X-Received: by 10.36.77.139 with SMTP id l133mr1720086itb.52.1516460091816; Sat, 20 Jan 2018 06:54:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516460091; cv=none; d=google.com; s=arc-20160816; b=Hr0Lg5iPd2eqm15QQL7ibD5B7VTvYnqaxW3NNMWCw5z6pLZIMluNO0Qnt9yDUPQQgs Hth4ouyQM7CiXPXK8Uoeg/cB4diOZJz6f8uZrc+TnA/Vc7ln0CJHru9SAbj6aCuuZWKl KWlaNjstW7LKtm7GQ2AiTGO5DYCgybs/VYbVAnxwSeVJU7LFy7L6PNEDbI2U/JdZolOT 4pL+5FA0WvutAMYIk8js6iZi2uAg+nEjHuuy66qFKVnhG7cF+Ls539zt2u4A/lBGVDDI fcYBDVXXDVMQ5vY8Hp9clvQYfL3/dqpVwYLc5wd8uLPnZQpHZKat0Xl2zLLbOzHniavp 0WvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=JdZ3Zu7Lsa27XksT4vJFtAITbzva1E/ZyI3HBFTslHA=; b=x2j+2tB52RXUWBA/nxT9xQHlm/qqbNNMICrPL4jo4N8wvrqOREgMY7F/6RKoiSPPLZ itH1lcAdphjp/HsHxiHJPuaIh1nK6d4/v0wkmKEbwSUr5DS4EIm1suVpSDX4pXFDXHOP MWh7dVqmhJQPAMDYLu0I6hU0LthuEMmqL9N81atQTnFePIof8w7lY1FX8RycJmiAm3mW JFGjeGLLpPP/5aVlZvD7YMkCHOvNyatLTX5VxM5MaWdkPTa8e+0MAvEHl4JvF9mw+RHH +olC61wTtuLmJjg1jjnIY1ef53Hbo8CKDo3ifqhkPSvahBzUsbDpRrCFCluL6Q0o8XF6 uwiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oap22XQg; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 135sor1676568ity.23.2018.01.20.06.54.51 for (Google Transport Security); Sat, 20 Jan 2018 06:54:51 -0800 (PST) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.36.26.74 with SMTP id 71mr1879988iti.32.1516460091087; Sat, 20 Jan 2018 06:54:51 -0800 (PST) Original-Received: by 10.2.164.138 with HTTP; Sat, 20 Jan 2018 06:54:50 -0800 (PST) In-Reply-To: <4fa792ec-1f51-4357-a65a-2ce3c10c60c0@isocpp.org> X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oap22XQg; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:36721 Archived-At: --001a114411780b9ee7056336617d Content-Type: text/plain; charset="UTF-8" > Copies of observer_ptr still monitor the same address, but with a different scope - their dtor, release or reset. It would be nice if this were enough. consider auto& exec = some_async_executor(); auto up = std::make_unique(); auto p = observer_ptr(up.get()); exec.post([p] { something_with(*p); }); // A exec.post([up = std::move(up)] { something_with(*up); }); // B exec.post([p] { something_with(*p); }); // C Assume that B's lambda invocation may or may not complete before C's lambda invocation. I can't see how this could be statically analysed. It's an undetectable logic error, since as far as the compiler is concerned, it has no way of knowing that C's p may outlive B's up. Note that at the point of the construction of each of the 3 lambdas, the pointers captured are all valid (except in the crossing case where there is a context switch after the post at B). On 20 January 2018 at 12:12, wrote: > > > On Friday, January 19, 2018 at 10:19:40 PM UTC+2, Nicol Bolas wrote: >> >> On Friday, January 19, 2018 at 7:30:52 AM UTC-5, mihailn...@gmail.com >> wrote: >>> >>> Can we "just" define special behavior of observer_ptr (in debug/analyze >>> mode) and solve all cases of lifetime monitoring (under the said >>> limitations) - from smart pointers to function_view? >>> >> >> That's not "behavior" of the type. There is no actual code in >> `observer_ptr` that does anything you're talking about. It's simply a >> compiler or tool that sees you using this particular type and starts >> looking at things because of it. >> > > If the constructor and reset of observer_ptr are decorated with something > like [[debug:observe_destruction]] the behavior of observer_ptr will be > enforced by the compiler. > > The behavior, use and definition of observer_ptr are not changed. > > >> >> It should also be noted that this still doesn't handle perfect >> forwarding. Not unless it is the caller of the function who wraps the >> parameter in an `observer_ptr`. >> > > class A_view > { > A_view(const A* pa) : _p(pa) {} > A_view(const A& a) : _p(&a) {} > A_view(A&& a) : _p(&a) {} > > observer_ptr _p; > }; > > observer_ptr will monitor addressof(*_p) for ~A() call. The scope of > monitoring is ~observer_ptr() or release() call. > > Copies of observer_ptr still monitor the same address, but with a > different scope - their dtor, release or reset. > > > That is a major difference from lifetime extension - we can have > many-to-one mapping without any semantic or implementation problems. Lifetime > extension does not allow copies of a view/ref to extend with the lifetime > of the object. > We are also not limited to initialization only - the monitoring can > (re)start at the call of reset() instead on constructor call only. Lifetime > extension deals with initialization exclusively. > > > How can perfect forwarding interfere in all this? > > > template > auto init(Args&&... arg) > { > return T(std::forward(arg)...); //< observer_ptr starts monitoring > &arg > } > > int main() > { > auto v = init(A{}); //< both A_view and A allocated. A_view > usable before the ';' when ~A is called > } > > If copy elision does not kick-in nothing changes - copy is safe and > defined, lifetime of A is the same. > > If we pass arguments and create A in init() instead ( return > T(A(std::forward(arg)...)); ), then the observer_ptr is still > created with a valid address, > however, after we return will not be able to use A_view in any way, > including before the ';'. > > If both there is no elision and A is created when initializing T inside > init, then the returned view can be created from a dangling view. > We could allow views from dangling views to be created, however no dtor > will be monitored and all uses of the view will be illegal until > destroyed/reset/release-ed. > We could also issue a warning on coping from dangling view without problem. > > > > > > > -- > 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/4fa792ec-1f51-4357- > a65a-2ce3c10c60c0%40isocpp.org > > . > -- 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/CALvx3hYQHFXi5eRrcdCGEqWj-n4w4NKYDpRx4G_U16i%2B2VS5nQ%40mail.gmail.com. --001a114411780b9ee7056336617d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Copies of=C2=A0observer_ptr still monitor the same address, but with= a different scope - their dtor, release or reset.

It would be nice if this were = enough.

consider

auto& exec =3D some_as= ync_executor();
auto up =3D std::make_unique<Foo>();<= /div>

<= /span>
auto = p =3D observer_ptr(up.get());
exec.post([p] { something_with(*p); })= ;=C2=A0 =C2=A0 // A
exec.post([up = =3D std::move(up)] { something_with(*up); }); // B
= exec.post([p] { something_with(*p); });=C2=A0 =C2=A0// C<= /span>

Assume that B's lambda invocation may or may not complete before= C's=C2=A0lambda invocatio= n.

I can't see how this could be statically = analysed. It's an undetectable logic error, since as far as the compile= r is concerned, it has no way of knowing that C's p may outlive B's up.

Note that = at the point of the construction of each of the 3 lambdas, the pointers cap= tured are all valid (except in the crossing case where there is a context s= witch after the post at B).



On 20 January 2018 at 12:12, <mih= ailnajdenov@gmail.com> wrote:


On Friday, January 19, 2018 at= 10:19:40 PM UTC+2, Nicol Bolas wrote:
On Friday, January 19, 2018 at 7:30:52 AM UTC-5, mih= ailn...@gmail.com wrote:
Can we "just" define special behavior of=C2=A0observer_ptr (in debug/analyze mode) and solve all cases of life= time monitoring (under the said limitations) - from smart pointers to funct= ion_view?

= That's not "behavior" of the type. There is no actual code in= `observer_ptr` that does anything you're talking about. It's simpl= y a compiler or tool that sees you using this particular type and starts lo= oking at things because of it.

If the constructor and reset of observer_ptr are decorated with something like<= font face=3D"courier new,monospace"> [[debug:observe_destruction]] t= he=C2=A0beh= avior of=C2=A0observer_ptr will be enforced by the compiler. <= /span>

The behavior, use and definition of observer_pt= r are not changed. =C2=A0
= =C2=A0
<= br>
It should also be noted that this still doesn't handle pe= rfect forwarding. Not unless it is the caller of the function who wraps the= parameter in an `observer_ptr`.

class A_view
{
=C2=A0 A_vi= ew(const A* pa) : _p(pa) {}
=C2=A0 A_view(const A& a) : _p(&a) {}
=C2=A0 A_view(A&& a) : _p(&a) {}
<= div>
=C2=A0 = observer_ptr<const A> _p;
};=C2=A0

obse= rver_ptr will monitor addressof(*_p) for ~A() call. The scope of monitoring= is ~observer_ptr() or release() call.

Copies of=C2=A0observer_ptr still monitor the same address, but with a different scope = - their dtor, release or reset.

That is a major= difference from lifetime extension - we can have many-to-one mapping witho= ut any semantic or implementation problems.=C2=A0Lifetime extension does not allow copies of a view/ref to extend with t= he lifetime of the object.
<= div>We are also not l= imited to initialization only - the monitoring can (re)start at the call of= reset() instead on constructor call only. Lifetime extension deals with in= itialization exclusively.=C2=A0
<= span style=3D"background-color:transparent;border-bottom-color:rgb(34,34,34= );border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34= ,34,34);border-left-style:none;border-left-width:0px;border-right-color:rgb= (34,34,34);border-right-style:none;border-right-width:0px;border-top-color:= rgb(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34,34,34= );display:inline;float:none;font-size:13px;font-style:normal;font-variant:n= ormal;font-weight:400;letter-spacing:normal;margin-bottom:0px;margin-left:0= px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padd= ing-right:0px;padding-top:0px;text-align:left;text-decoration:none;text-ind= ent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<= /span>

How can perfec= t forwarding interfere in all this?=C2=A0


template<ty= pename T, typename ...Args>
auto init(Args&&... arg){
=C2=A0 return T(std::forward<Args>(arg)...); //< observer_p= tr starts monitoring &arg
}

int main()
{
=C2=A0 auto v= =3D init<A_view>(A{}); //< both A_view and A allocated. A_view us= able before the ';' when ~A is called
}

If copy elision does not kick-in = nothing changes - copy is safe and defined, lifetime of A is the same.

If we pass arguments and create A in init() instead ( = return=C2=A0 T(A(std::forward<Args>(arg)...)); ), the= n the observer_ptr is still cre= ated with a valid address,
however, after we return will not be = able to use A_view in any way, = including before the ';'.=C2= =A0

If both th= ere is no elision and A is created when initializing T inside init, then th= e returned view can be created from a dangling view.=C2=A0
We cou= ld allow views from dangling views to be created, however=C2=A0no dtor will be monito= red and all uses of the view will be illegal until destroyed/reset/r= elease-ed.
We could also issue a warning on coping from dangling= view without problem.




=C2= =A0

--
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.google.com/a/isocpp.org/d/msgid/std-proposals/4fa7= 92ec-1f51-4357-a65a-2ce3c10c60c0%40isocpp.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYQHFXi5e= RrcdCGEqWj-n4w4NKYDpRx4G_U16i%2B2VS5nQ%40mail.gmail.com.
--001a114411780b9ee7056336617d-- .