220 36717 <4fa792ec-1f51-4357-a65a-2ce3c10c60c0@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Sat, 20 Jan 2018 03:12:09 -0800 (PST) Lines: 730 Approved: news@gmane.org Message-ID: <4fa792ec-1f51-4357-a65a-2ce3c10c60c0@isocpp.org> References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <88864914-82a8-4a8b-bda7-cffd38379edf@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1839_156315941.1516446729100" X-Trace: blaine.gmane.org 1516446625 24938 195.159.176.226 (20 Jan 2018 11:10:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Jan 2018 11:10:25 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBCWIRTJQKGQE43PPNHQ@isocpp.org Sat Jan 20 12:10:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecr2F-0005SW-HW for gclcip-std-proposals@m.gmane.org; Sat, 20 Jan 2018 12:10:07 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id o13sf2392665vkc.22 for ; Sat, 20 Jan 2018 03:12: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:cc: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=8GK81bJXX+jNk8xkFyJspJkplgOPodNrHkdZGICte14=; b=Lkg/OHiZEkPDWDzdAd1yHXVbxhmuqXfIm3Tj3qH7ezcA1nvyZ4en0f640vcDPEEnVD x3G0o4Zh8D8IhIX5NM3lCx/YFqUyo5JUHUeU4uoVtzQmlOCP7MyODK3AOBUsRZ+W5BTa YDPcfTfwGjFRZrk8jcU1kRgZ+3nAcmE8Fkkk6LkVRYkV2JJ8aXVuzdz+TPpervfc4G9Y cOidQtMdwBqvtPAHiekihivkCVAdb2g4ATQpLz5LeBuh/m6T7CGgXPWCGOJ3DYdNg50s NAoTixyPMAMp28PuxgMwHFrm6fvPLYkAjmoXX7arUqN34/QPQKk00iTPqnv5FqwG/cD4 g0LA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=8GK81bJXX+jNk8xkFyJspJkplgOPodNrHkdZGICte14=; b=bs5GdS5+Iyy/2XGplHiKiB5XbX2Cp0WkW3zF7aRJr6FC/Qzg0QzAR8f3lOdeihvkIY 3bpbs0WsiIgBfAuMwOUUxjiZ+If2Xl5qoFyZLHWWzHvsTv2v/uOMJJ2HZygOBAXaPIf+ pHtXQQCwv4zyYWNoMKxVoWqyLpzXDF+NTLD/aiRWPUizkbAaPNFstCQWLCxTvzJ4kaEz 0SuV8P0L4Y5BvIErjNw7MvYuLFu+1PraPzIE4nua5yIxqF4gBt+VSS9s1n/od/XmfrHd 0BrGwHvUJeaUgt+E9ddEYySlPZ9Z8LutUywL9Z/xK/X5DJrgJcnh285gboYQnf+eNTGq vZfA== 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:cc: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=8GK81bJXX+jNk8xkFyJspJkplgOPodNrHkdZGICte14=; b=Yc0ykSR4C7za90EHEFbrDuG74AXW+GNH0/sy9IK4w2IzeIJNJJRzF/IZLkTxH09C1q 1iLrZzbaxRmgGWgGLYFQm2O5kxNb2NMQmtPxyl7RM2Mu8jDdFNdzd8QKqvBuy9JHRQ0w ucLy99XsLYzfCzBfJoBoPAAW7S/ckM3W8YBdsVQgLWYeBFbIK+cRL4PJysKKVVSr9e3n fRbwspdkf8mdr99Kj/bxGVscb38etf40hPIJYBMnGqEJcdJM+p6Xy6x8H9wrGewXFSSG 3OXQTNknIOdq75uG/f/iOKLkpmljGAFybSjiJ1XiZWQZBa3LKxkYCfwE2ZhuNnmLeSVa jweg== X-Gm-Message-State: AKwxytcuXfC9yhXwhej5cRLMgeTMecBM54NSBobEiGdPVX7TWKNxR+vf B6OKYU7OLTm+Ev5sKr/LPMtJtw== X-Google-Smtp-Source: AH8x225nGX1mfRJnF+s91c+YgLHFJ5KR5ROzG2YpCWJPvTNwnpNCRysnJYtz7nPqoskfNk5/Ps+HWQ== X-Received: by 10.176.71.211 with SMTP id w19mr688248uac.111.1516446731435; Sat, 20 Jan 2018 03:12:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.174.150 with SMTP id x144ls972822vke.2.gmail; Sat, 20 Jan 2018 03:12:10 -0800 (PST) X-Received: by 10.31.168.202 with SMTP id r193mr149936vke.4.1516446729747; Sat, 20 Jan 2018 03:12:09 -0800 (PST) In-Reply-To: <88864914-82a8-4a8b-bda7-cffd38379edf@isocpp.org> 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:36717 Archived-At: ------=_Part_1839_156315941.1516446729100 Content-Type: multipart/alternative; boundary="----=_Part_1840_749971179.1516446729101" ------=_Part_1840_749971179.1516446729101 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_1840_749971179.1516446729101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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.c= om wrote:
= Can we "= ;just" define special behavior of=C2=A0obse= rver_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 construc= tor and reset of observer_ptr are decorated with something like [[debug:observe_destruction]] the=C2=A0behavior of=C2=A0= observer_ptr will be enforced by the compiler.

The behavior, use and definition of observer_ptr are not cha= nged. =C2=A0
=C2=A0

It should = also be noted that this still doesn't handle perfect forwarding. Not un= less it is the caller of the function who wraps the parameter in an `observ= er_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;
}= ;=C2=A0

<= font face=3D"arial,sans-serif">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 m= onitor the same address, but with a different scope - their dtor, release o= r reset.


That is a major difference from lifetime extension - = we can have many-to-one mapping without any semantic or implementation prob= lems.=C2=A0Lifetime extension does not al= low copies of a view/ref to extend with the lifetime of the object.<= /span>
We are also not limited to initializa= tion only - the monitoring can (re)start at the call of reset() instead on = constructor call only. Lifetime extension deals with initialization exclusi= vely.=C2=A0

=

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

<= br>
template<typename T, = typename ...Args>
auto init(Args&&... arg)
{
=C2=A0 ret= urn T(std::forward<Args>(arg)...); //< observer_ptr starts monitor= ing &arg
}

int main()
{
=C2=A0 auto v =3D init<A_vi= ew>(A{}); //< both A_view and A allocated. A_view usable before the &= #39;;' when ~A is called
}

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

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

If both there is no elisio= n and A is created when initializing T inside init, then the returned view = can be created from a dangling view.=C2=A0
We could allow views f= rom dangling views to be created, however=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-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/4fa792ec-1f51-4357-a65a-2ce3c10c60c0= %40isocpp.org.
------=_Part_1840_749971179.1516446729101-- ------=_Part_1839_156315941.1516446729100-- .