220 36729 <7ce99930-b0b8-41cc-b3ea-7501e265bb62@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: Sun, 21 Jan 2018 05:44:07 -0800 (PST) Lines: 464 Approved: news@gmane.org Message-ID: <7ce99930-b0b8-41cc-b3ea-7501e265bb62@isocpp.org> References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <88864914-82a8-4a8b-bda7-cffd38379edf@isocpp.org> <4fa792ec-1f51-4357-a65a-2ce3c10c60c0@isocpp.org> <634a78e7-dc92-4f5e-9105-83339a18b579@isocpp.org> <73c5d690-f05d-4e72-a685-3c55d8be0f8e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1851_18905626.1516542247800" X-Trace: blaine.gmane.org 1516542135 26189 195.159.176.226 (21 Jan 2018 13:42:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Jan 2018 13:42:15 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBKNSSLJQKGQEF4DHRDY@isocpp.org Sun Jan 21 14:42:10 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edFss-0006HU-DG for gclcip-std-proposals@m.gmane.org; Sun, 21 Jan 2018 14:42:06 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id q28sf4763011uaa.6 for ; Sun, 21 Jan 2018 05:44:11 -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=ziqz/zlwL0qXNn7NtdjF0RZ+VVu84cLwnL3fwK8I4us=; b=iGG5EX0RtzBL72VGye/Jphg6hYyFL218S7qXYbs/A6gzkPcZV1YDnTnd5vdVrUcLng 9YU+35sobnFg50ksBiWigi4wF7c3ZI9x4JCsv3doujg+7Jqa23GATr/CP6zkLdOoiVbN lJAQ33vE2aCTNP+O+SVd/YWfXP0wvHfmjAC7nYyl8Qw89P1rnfeq01jMZH4zsSqPG4uI VWJLNtZrBueLKj4LH5G2jljGTI9do5kyDjeQzRR7/tHkclXDVFdUpTSkC8I6oTBOUwh9 KOR+hmjnoopf3A4heBCExzVbxhS6ggL4JdxmpAKiDTavbI4vDdM0WqQDmHuoJS0UvxCf //bQ== 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=ziqz/zlwL0qXNn7NtdjF0RZ+VVu84cLwnL3fwK8I4us=; b=vJcvnOuJmJn4u0SvA88rNM/9D00wVoMhKyTr1EvNpoek7dKxa9lpxOoH4rcDJXQABm qnSbOub4m974dMMaf+JjdKWQNDLo6y//IF/10O0JK83JMrQrXDyGhrpst24EDpjrvB5M QkV03W2/4cu5DcnYFMT0N19ir4GayyekXconffbn2HP02vWzhkJvCKQKJS9fPHRuxIaP xXBnM/1Ng7hnLy+drKLVKdwN4O7M0S4ex8gkNwAo2wM1wsxchDPc0EqnGbeRdamCspCy 08tWCo5O6B/Hrrbfn7yuJxQLlzDpuF4UPFADtmVwuNC4rG4zeGs/4ln9VFKfd3+8zyxI qfBg== 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=ziqz/zlwL0qXNn7NtdjF0RZ+VVu84cLwnL3fwK8I4us=; b=tmqLQDDNbrmTXRNeJvMgGHvOZsPMiCRHT004PZR5uvYdIi1R3RO928HVJwqK7Y3yWy WznkS6gSBLUVAeuNmIEWYsaca60p8U9ffJtPw7hR8DAvOyHChtzFL1uzbZ/AJqYCY0BF ASwcpbVi6QmmY5US5K7zkc+eMBgc2pVUr3VdkD+V91KC6z/iutfyCTe/HGnRBtRaMdrk lrQZiffMGLx85VzDSfBzLSMd/YsGU8RJGbpsW4UUWNw3XM8cBNaWxZj2nzyDiRkl/5lR s8PtiNnftaHCvRTEXmULd8k+q7C1Wtb3TAr8Amz2TncSO9I6h5uKNjPiPrLrajCRDVlt FC9A== X-Gm-Message-State: AKwxytcS/lOGCRe6seG13qixhQuUjvmAswgeqCwQDhJbPo4x+LXD4gmH XdHGhaO+p/r4D2Sn3THkLhtzHQ== X-Google-Smtp-Source: AH8x225Osaw9wqRKWSc+Ekt52rbbH6vdRzAVCE49+MSNMG3uJwWA/WZOlNOKSiDuIHeDfNMsUD8xow== X-Received: by 10.31.110.71 with SMTP id j68mr2226269vkc.102.1516542250515; Sun, 21 Jan 2018 05:44:10 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.16.69 with SMTP id g5ls1826976uab.3.gmail; Sun, 21 Jan 2018 05:44:08 -0800 (PST) X-Received: by 10.31.161.69 with SMTP id k66mr472912vke.10.1516542248465; Sun, 21 Jan 2018 05:44:08 -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:36729 Archived-At: ------=_Part_1851_18905626.1516542247800 Content-Type: multipart/alternative; boundary="----=_Part_1852_382242868.1516542247801" ------=_Part_1852_382242868.1516542247801 Content-Type: text/plain; charset="UTF-8" On Sunday, January 21, 2018 at 3:45:37 AM UTC+2, Nicol Bolas wrote: > > On Saturday, January 20, 2018 at 3:25:14 PM UTC-5, mihailn...@gmail.com > wrote: >> >> On Saturday, January 20, 2018 at 9:31:22 PM UTC+2, Nicol Bolas wrote: >>> >>> ... >>>> >>>> >>> 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 have to be more specific, might be my knowledge failing me, but what >> would prevent the compiler seeing in the case when are the dtros of both >> variables called? >> > > In order for the compiler to be able to associate the prvalue temporary > with `A_view`, it must be able to look at the code and see that `A_view` > contains a pointer/reference to that temporary. While the compiler can see > that `A_view`'s constructor is being given a pointer to a temporary, it > does not know what that constructor is doing. It cannot associate the > constructor parameter with `A_view::p_`, because there is no code in this > translation unit that associates the constructor parameter with that member > variable. > > Yes, the compiler can see that two destructors are happening. But there is > no evident association between these two objects. And without that > knowledge, the compiler has no right to declare that this code is > problematic. > > This is why you need the annotation to be part of the declaration. Because > the declaration may be the only thing the compiler will ever see. > I see, you mean that only the A_view ctor is visible as a single function call and nothing beyond that. If that is the case, then both view (its ctor) and observer_ptr must be inlined. Luckily, that covers practically all views and observer_ptr is a template already. Surely it would be a noticeable limitation, but will not make the feature useless. However, that does not have to be the case. I was assuming some sort of "entire program" analysis. In that case the analyzer sees observer_ptr as part of the A_view declaration in the header, then it sees the decorated constructor of observer_ptr, after that it goes and "recompiles" the A_view object file to see how the association is made. As I said, I was assuming "entire program" analysis, because otherwise *copies* of views would be impossible to implement. Not just copies, but code like this void f(observer_ptr

pv) { kill_p_by_accident(); //< some function using p, not in the TU // warn of using pv after potential kill } The quotes in "entire program" are important. The whole point of decorations is to have *targeted *analysis - real "entire program" analysis are too slow and too noisy. If the analyzer have all the source, to all the translation units, *and* knows what to look for, then it *should* be able to do reasonably fast and reasonably accurate predictions. I am not insisting of "entire program", though, just speculating what would be possible and useful! I would be happy with *anything, *any scaled back version of this (or something similar), because now, out of the box, we have *nothing**.* And what we have, the external tools, have to do a ton of guess work simply because C++ deliberately ignores their existence. -- 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/7ce99930-b0b8-41cc-b3ea-7501e265bb62%40isocpp.org. ------=_Part_1852_382242868.1516542247801 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Sunday, January 21, 2018 at 3:45:37 AM UTC+2, N= icol Bolas wrote:
On Saturday, January 20, 2018 at 3:25:14 PM UTC-5, mihailn...@gmail.= com wrote:
On S= aturday, January 20, 2018 at 9:31:22 PM UTC+2, Nicol Bolas wrote:
...

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

class A_view
<= span style=3D"color:#660">{
public:
=C2=A0 A_view= (const = A &= p);
=
private:
=C2=A0 observer_ptr<A> p_;
};

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

=
A_= view v(= A{});

We're not talking about runtime de= tection here; this is purely compile-time. And the compiler doesn't nec= essarily see everything. If `A_view` is in another translation unit that is= n't visible to static analysis, this doesn't work.

You have to be more s= pecific, might be my knowledge failing me, but what would prevent the compi= ler seeing in the case when are the dtros of both variables called?=C2=A0

In order for the compiler to be = able to associate the prvalue temporary with `A_view`, it must be able to l= ook at the code and see that `A_view` contains a pointer/reference to that = temporary. While the compiler can see that `A_view`'s constructor is be= ing given a pointer to a temporary, it does not know what that constructor = is doing. It cannot associate the constructor parameter with `A_view::p_`, = because there is no code in this translation unit that associates the const= ructor parameter with that member variable.

Yes, t= he compiler can see that two destructors are happening. But there is no evi= dent association between these two objects. And without that knowledge, the= compiler has no right to declare that this code is problematic.
=
This is why you need the annotation to be part of the declar= ation. Because the declaration may be the only thing the compiler will ever= see.


I see, you= mean that only the A_view ctor is visible as a single function call and no= thing beyond that.

If that is the case, then both = view (its ctor) and observer_ptr must be inlined. Luckily, that covers prac= tically all views and observer_ptr is a template already.
Surely= it would be a noticeable limitation, but will not make the feature useless= ..=C2=A0



However, tha= t does not have to be the case. I was assuming some sort of "entire pr= ogram" analysis.

In that case the analyzer sees observer_ptr as part of the A_view dec= laration in the header, then it sees the decorated constructor of observer_ptr,
after that it goes and "recompiles" the A_view object fi= le to see how the association is made.

As I= said, I was assuming "entire program" analysis, because otherwis= e copies of views would be im= possible to implement.

Not just copies, but code like this=

void f(observer_pt= r<P> pv)
{
=C2=A0 kill_p_by_accident(); //< some f= unction using p, not in the TU

=C2=A0// warn of using pv after potential kill
}=


The quotes in "ent= ire program" are important. The whole point of decorations is to have = targeted analysis - real "entire program" analysis are too= slow and too noisy.

If the analyzer have all the = source, to all the translation units, and knows what to look for, th= en it should be able to do reasonably fast and reasonably accurate p= redictions.



I am not= insisting of "entire program", though, just speculating what wou= ld be possible and useful!

I would be happy with = anything, any scaled back version of this (or something similar), be= cause now, out of the box, we have nothing.
And wha= t we have, the external tools, have to do a ton of guess work simply becaus= e C++ deliberately ignores their existence.

=C2=A0
=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/7ce99930-b0b8-41cc-b3ea-7501e265bb62= %40isocpp.org.
------=_Part_1852_382242868.1516542247801-- ------=_Part_1851_18905626.1516542247800-- .