220 36726 <634a78e7-dc92-4f5e-9105-83339a18b579@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Sat, 20 Jan 2018 11:31:21 -0800 (PST) Lines: 261 Approved: news@gmane.org Message-ID: <634a78e7-dc92-4f5e-9105-83339a18b579@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_3058_1799439253.1516476681966" X-Trace: blaine.gmane.org 1516476570 25695 195.159.176.226 (20 Jan 2018 19:29:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Jan 2018 19:29:30 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBC5SR3JQKGQE6LCTTII@isocpp.org Sat Jan 20 20:29:25 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecypM-00065I-Mc for gclcip-std-proposals@m.gmane.org; Sat, 20 Jan 2018 20:29:20 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id g9sf3578005ual.8 for ; Sat, 20 Jan 2018 11:31:25 -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=tR3vL9rURz2dzoPyyl6A47GzV2FIPc566VirErjD1OY=; b=TYtVobxVJUAc6MrTvOw9WRD/tlkKzlYejA7ay3UrNYuEAx7caHzRSw3rmveMqnBB4X o9QXFSna4XLN6wrO10Y5XMjpvaxtFxdTtYXEhE2uFcYDZpPOQcUrIzXBulh04mzIsKle GDS3fBwLzEhtXhPk5XwDvNBhemJDp4pgv+YowFd8hDC2nuedjiobr1OTa2EDvEKfCbne C4qXBNmHJRPzAjbqXSixB9CDFiiqLKi5VfVmbO8bOG9yLov90YX7DzS+BP3ti3aZrVIM SC9fjb73kGN8KbF8WeVHu/cuKfYxRhlyjFm0FququTf3W+nkaQf+1RLwnmvfddZ7lxAv rl7Q== 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=tR3vL9rURz2dzoPyyl6A47GzV2FIPc566VirErjD1OY=; b=TwVj0u3BNH7CA/b0nyXPF1CWBvSjHFbpVt/oX+dVL+1TnhrGNc4i3CP+x3IW5HZp6d Rp6AJMkdbPu2w0vWNeSa0P6olShGbv52xtA25cRiH1v6Sg4Q6knjXKfHwR+wTpn4IVPy USF5XAZdvRPNsVi7nnkPIYXJ8RnMF7Z6CNzeKPNt4zZ1H2+vzlyilREVvKfgoeEH0mio N3igQvrHq3rpSFivAly3LiOp6TgdEAt6I8ywKlZ1PGpFIqDbU5GOThtofXsD5Xa1n1eH JIossicROsoZIL5DU/0NPSLzO9oKDLAvAchKbGNFXacVrUxSSrvTFYkLNFBN+I1DFMLE 1cPQ== 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=tR3vL9rURz2dzoPyyl6A47GzV2FIPc566VirErjD1OY=; b=ac6kfxywRN8TtbOyoa53jaY9u/FBiArtgSmOoJKbQsDYJMtwwSP5VZfSAVudAp6cXN fVKXLMCIQ7UVXcvF/O0YRSLkk4M8j61oW+nPw+1RJ1nLb0F5VHmaIp1ytf7XCPhMZfet y2wMCFh/Wkn7t2JDaDPBeIW+sWJC0s5/wuW2GwTCgB3jQpyQOkcgWrleB5lCfSvpZtKb UIOSjQv4iTOg0Up9nIzDcgzaTsi0uiYzF/CZZPtO8PuIE2dPk6EJzUUi2QL1sMDB8lXL Bfp4YIjqsAS0ZCYJ2pPcIFY7smZaksI4GiW6G76SLbo9RuFyt9FEkk5OJzfm5ydzce3C KFeg== X-Gm-Message-State: AKwxytcKLBx02JzYesNxUWOtyEmlrKaWZhcgxolGThBE1uodESjDsFeC TTmETLcPZXPtSPBRP4uqptBkGQ== X-Google-Smtp-Source: AH8x224QdAgLF55qmMOCMm5bm3guPDJkpjcDLSW2WZhP4kUxgdGMUZ/oCTWfiD/59H0O0LAdbGQTMw== X-Received: by 10.176.72.138 with SMTP id x10mr1370617uac.83.1516476684689; Sat, 20 Jan 2018 11:31:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.158.3 with SMTP id h3ls1050870vke.11.gmail; Sat, 20 Jan 2018 11:31:23 -0800 (PST) X-Received: by 10.31.178.206 with SMTP id b197mr239608vkf.11.1516476682617; Sat, 20 Jan 2018 11:31:22 -0800 (PST) In-Reply-To: <4fa792ec-1f51-4357-a65a-2ce3c10c60c0@isocpp.org> X-Original-Sender: jmckesson@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:36726 Archived-At: ------=_Part_3058_1799439253.1516476681966 Content-Type: multipart/alternative; boundary="----=_Part_3059_105007333.1516476681966" ------=_Part_3059_105007333.1516476681966 Content-Type: text/plain; charset="UTF-8" On Saturday, January 20, 2018 at 6:12:09 AM UTC-5, mihailn...@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, 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. > How would it know? If all the compiler in that translation unit sees is: class A_view { public: A_view(const A &p); private: observer_ptr p_; }; How could the compiler* possibly* know that this code is invalid: A_view v(A{}); We're not talking about runtime detection here; this is purely compile-time. And the compiler doesn't necessarily see everything. If `A_view` is in another translation unit that isn't visible to static analysis, this doesn't work. -- 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/634a78e7-dc92-4f5e-9105-83339a18b579%40isocpp.org. ------=_Part_3059_105007333.1516476681966 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, January 20, 2018 at 6:12:09 AM UTC-5, mihailn= ....@gmail.com wrote:


On Friday, January 19, 2018 at 10:19:40 PM UTC+2, Nicol Bo= las wrote:
On Frida= y, January 19, 2018 at 7:30:52 AM UTC-5, mihailn...@gmail.com wrote:=
Can we "just" <= /span>define special behavior of=C2=A0observer_ptr (in = debug/analyze mode) and solve all cases of lifetime monitoring (under the s= aid limitations) - from smart pointers to function_view?

That's not "behavio= r" of the type. There is no actual code in `observer_ptr` that does an= ything you're talking about. It's simply a compiler or tool that se= es you using this particular type and starts looking at things because of i= t.

If the constructor and reset= of observe= r_ptr are decorated with something like [[debug:observe_destruction]] the=C2=A0behavior of=C2=A0observer_ptr wi= ll be enforced by the compiler.

The beh= avior, use and definition of observer_ptr are not changed. =C2=A0
=C2=A0

It should also be noted that this sti= ll doesn't handle perfect forwarding. Not unless it is the caller of th= e function who wraps the parameter in an `observer_ptr`.

class A_view=
{
<= font face=3D"courier new,monospace">=C2=A0 A_view(const A* pa) : _p(pa) {}
=C2=A0 A_view(const A& a) : _p(&a= mp;a) {}
A_view(A&& a) : _p(&a) {}

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

observer_ptr will monitor addressof(*_p) for ~A() call.

How would it know? If all the= compiler in that translation unit sees is:

class A_view
{
p= ublic:
=C2=A0 A_v= iew(const A &p);

private:
=C2=A0 observer_ptr<A> p_;
};

How could the compiler possibly know th= at this code is invalid:

A_v= iew v(A{});

We're not talking about runtime detection here; this is pure= ly compile-time. And the compiler doesn't necessarily see everything. I= f `A_view` is in another translation unit that isn't visible to static = analysis, this doesn't work.

--
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/634a78e7-dc92-4f5e-9105-83339a18b579= %40isocpp.org.
------=_Part_3059_105007333.1516476681966-- ------=_Part_3058_1799439253.1516476681966-- .