220 36724 <00d91d4c-4ee7-4dbd-a547-3dd844f5685d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Static analysis and the future of C++ Date: Sat, 20 Jan 2018 08:36:08 -0800 (PST) Lines: 748 Approved: news@gmane.org Message-ID: <00d91d4c-4ee7-4dbd-a547-3dd844f5685d@isocpp.org> 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/mixed; boundary="----=_Part_2493_1727009190.1516466168923" X-Trace: blaine.gmane.org 1516466062 5456 195.159.176.226 (20 Jan 2018 16:34:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Jan 2018 16:34:22 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRB6W7RXJQKGQEUGBOKSI@isocpp.org Sat Jan 20 17:34:18 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecw5n-0000Yu-KB for gclcip-std-proposals@m.gmane.org; Sat, 20 Jan 2018 17:34:08 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id g47sf3374543uad.14 for ; Sat, 20 Jan 2018 08:36:12 -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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=r9vD+NIl//5eX0TsFwBU2pzljJNhd0QLXR0cnMWfFuo=; b=qwuV8mtYgrnx3CzhG+9qlCBuc2eRC896c60x+3zBMue2dD4rkiORAtOm8RBJ4QFNVc HSg3COIrKZd2Z+n9MCXtVePW6OOr9jl3nGGaB6nNEx6zuT57vERZaOHqVB8lhuQxwbSu FoflRtviz9a+dvjUJA/dU6odcq1PMQ7okg+xAGpnmlzWfDlE3CKQeIn4HABuHRwya3sV 1+cfMl0ug9fGUo4B5SKQ0ddSbAlIwezM0hib74wUrvmdRnz50yGxgtJCMpMfR8bHa6XK bPWqTWBkqbrAxjlOoMNXdPoUHS2NBZmUEe06TW4zwvW71CC9KOx++cnhrpSad8b0Fu0W k76g== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=r9vD+NIl//5eX0TsFwBU2pzljJNhd0QLXR0cnMWfFuo=; b=GyRNIc3bKPKzi46xg2bL7JHgYJupPzmzmpu2gVPYFdht5VdlKJBMk+qO6Pgwt8HIyu bmGF0LSZYtEkpTQQv8XqqZsfKG1fSn3UzaoV79Utqq3U1UR4f/6zLQqflG9ZUAEUeiXs 79AmrH2z7eFtfrZxQti1Tw12y3jPP6uFNNDn/Pk4xDQoy8UCEyQ2IUI//ND3MkE1ro/5 CHYg5ffJDEmeqwx4AJnzHCABZGOeYsxikHlBy8UvFONwxCX4MnCF0MGn61vFKvy1NoVF +hmBbg591+9QpRaN47ouWPK9SKwygtTn+ya6wYoHIT6e8gcyu6m1rZEHz0Tur8klWBta QAWg== 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=r9vD+NIl//5eX0TsFwBU2pzljJNhd0QLXR0cnMWfFuo=; b=nx/U32By8y5vsk4kqTULAkj7mnb8dnZpmNX3TxNhw+D1g4cpa5T+ToxvnsZ8PdFNic vsF6cpacpuRu6TG9afGYgljidT4Q8jFhzcAnedOnwOrBVbwFSXdxuKntpx6oq00c7BdU dHeG9QU+2bqXKfVFDUwE99DVjnftdLTp5phDeKBRUUseTmiX+IGiHK26D77KF7Ijw+ls 4EaBiAF/JtJNt+2hduyZ0JY3Re6Ja2IMSEfEVza2Fd4xH/ulupmefBUwbOoEJJrw3zlX xQ6O2Gi7SmxE3LePYh3zQu4Ztle+i+RZ0TxDXL9iDhcycuJOcXkQ0nIJ61ZfLO8gUfTk kU/A== X-Gm-Message-State: AKwxytfmF0xP1JYWXUFRQoK0Pzc3L3sApYwg5jP/yMtAx1hb2Rr6ZwhA 2mRochZtqU8SpfFg5ve6y6HF4g== X-Google-Smtp-Source: AH8x226Ua+6deZwWXJY+mwB//twE8M4ZXcGgGeEIhkLCZlUhop8kipsVrAztyMxFzPj60xMOqs1ICg== X-Received: by 10.31.233.193 with SMTP id g184mr978275vkh.17.1516466171820; Sat, 20 Jan 2018 08:36:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.14.17 with SMTP id g17ls1155314uak.14.gmail; Sat, 20 Jan 2018 08:36:10 -0800 (PST) X-Received: by 10.31.178.206 with SMTP id b197mr196399vkf.11.1516466169643; Sat, 20 Jan 2018 08:36:09 -0800 (PST) In-Reply-To: X-Original-Sender: MihailNajdenov@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:36724 Archived-At: ------=_Part_2493_1727009190.1516466168923 Content-Type: multipart/alternative; boundary="----=_Part_2494_1021269791.1516466168924" ------=_Part_2494_1021269791.1516466168924 Content-Type: text/plain; charset="UTF-8" On Saturday, January 20, 2018 at 4:54:53 PM UTC+2, Richard Hodges wrote: > > > 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). > In any case this does heap allocation for the views (the lambdas, inside the exec class) and presumably threading after that. Both are impossible to track. For both however we have nice tools - shared and week ptr. Which is ironic - the complex code is more safe then the trivial one. Yes you could use the heavyweight tools for simple tasks, but that is not zero overhead any more. Static analysis is the tool to help us with the common, simple, yet (terribly) unsafe tasks, still keeping zero overhead. Having said that, there are scenarios where tracking will not give accurate prediction - the destruction might, for instance, depend upon some real time state. That is the reason, these cannot be errors, only warnings. The compiler should, however, be able to see all paths leading to destruction even the once behind real time check/uncertainty and warn that "it *might *dangle" or that "no one can be certain, even you!". In your example, the compiler should warn it can't predict the observer - has no visibility over its lifetime and/or the observed destruction is behind real time uncertainty. He might even suggest alternative like share/weak ptr, because *observe_ptr was not the right tool in the first place!* The compiler will only reaffirm that fact. > > > > 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-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@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/00d91d4c-4ee7-4dbd-a547-3dd844f5685d%40isocpp.org. ------=_Part_2494_1021269791.1516466168924 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Saturday, January 20, 2018 at 4:54:53 PM UTC+2,= Richard Hodges wrote:
>=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.


auto up =3D s= td::make_unique<Foo>();

auto= p =3D observer_ptr(up.get());
exec.post([p] { somet= hing_with(*p); });=C2=A0 =C2=A0 // A
<= font face=3D"monospace, monospace">exec.post([up =3D std::move(up)] { somet= hing_with(*up); }); // B
<= span style=3D"background-color:transparent;margin:0px;padding:0px;border:0p= x rgb(34,34,34)">
exec.post([p] { something_with(*p= ); });=C2=A0 =C2=A0// C
<= span style=3D"font-size:13px;background-color:transparent;margin:0px;paddin= g:0px;border:0px rgb(34,34,34)">
Assume that B's l= ambda invocation may or may not complete before C's=C2=A0lambda invocation.

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



<= /span>

On 20 January 2018 at 12:12, <mihailn...@gmail.com> wrote:


On Friday, January 19, 2018 at 10:19:40 PM UTC+2, Nicol Bolas wr= ote:
On Friday, Jan= uary 19, 2018 at 7:30:52 AM UTC-5, mihailn...@gmail.com wrote:
Can we "just" = define special behavior of=C2=A0observer_ptr (in debug/= analyze mode) and solve all cases of lifetime monitoring (under the said li= mitations) - 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 rese= t of observ= er_ptr are decorated with something likebehavior of=C2=A0observer_ptr w= ill be enforced by the compiler.

<= /div>
<= span style=3D"display:inline!important;float:none;background-color:transpar= ent;color:rgb(34,34,34);font-family:"Arial","Helvetica"= ,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weigh= t:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inden= t:0px;text-transform:none;white-space:normal;word-spacing:0px">The be= havior, use and definition of observer_ptr are not changed. =C2=A0
=C2=A0

It should also be noted that thi= s 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
{=
=C2=A0 A_view(const A* pa) : _p(pa) {}
=C2=A0 A_view(const A&= ; a) : _p(&a) {}
=C2=A0 A_view(A&& a) : _p(&a) {}

=C2=A0 observer_ptr<const A> _p;<= /span>
};=C2= =A0

observer_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 addres= s, but with a different scope - their dtor, release or reset.=

<= 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">

That is a major difference from lifetime extension - we can = have many-to-one mapping without any semantic or implementation problems.= =C2=A0Lifetime extension does not allow copie= s of a view/ref to extend with the lifetime of the object.
We are also not limited to initialization only - the monitor= ing can (re)start at the call of reset() instead on constructor call only. = Lifetime extension deals with initialization exclusively.=C2=A0


How can perfect forwarding interfere in all this?=C2= =A0


template<typename T, typename ...Args>
auto ini= t(Args&&... arg)
{
=C2=A0 return T(std::forward<Args>(a= rg)...); //< observer_ptr starts monitoring &arg
}

int mai= n()
{
=C2=A0 auto v =3D init<A_view>(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, lifet= ime of A is the same.

If we pass arguments and cre= ate A in init() instead ( return=C2=A0 T(A(std::forward<Args>(arg= )...)); ), then the observ= er_ptr is still created with a valid address,
however, af= ter we return will not be able to use = A_view in any way, including before the ';'.=C2=A0

If both there is no elision and A is created when initializin= g T inside init, then the returned view can be created from a dangling view= ..=C2=A0
We could allow views from dangling views to be created, h= owever=C2=A0no 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.


=


=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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@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 &= 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/00d91d4c-4ee7-4dbd-a547-3dd844f5685d= %40isocpp.org.
------=_Part_2494_1021269791.1516466168924-- ------=_Part_2493_1727009190.1516466168923-- .