220 36730 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: Sun, 21 Jan 2018 07:03:50 -0800 (PST) Lines: 186 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> <634a78e7-dc92-4f5e-9105-83339a18b579@isocpp.org> <73c5d690-f05d-4e72-a685-3c55d8be0f8e@isocpp.org> <7ce99930-b0b8-41cc-b3ea-7501e265bb62@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1984_1120087284.1516547030674" X-Trace: blaine.gmane.org 1516546943 22566 195.159.176.226 (21 Jan 2018 15:02:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Jan 2018 15:02:23 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBV6XSLJQKGQEUMCNMJY@isocpp.org Sun Jan 21 16:02: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 1edH80-0003sy-W7 for gclcip-std-proposals@m.gmane.org; Sun, 21 Jan 2018 16:01:49 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id 1sf506369uas.23 for ; Sun, 21 Jan 2018 07:03:53 -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=qmY5DvtRGqNJ8kQCNPGwJlb5aeZSsE/SWEGgaKmljZE=; b=0l+xP9YNAIQHdGkv/uBYBst2tfxlsDmsmwUgQR40PQBG3p+yj2Tbfby8HFlXxsoQKa klTbOeF5sOIoreZWAGO6V3R9xW0NKtmpf5f9BHDMpUrFp7wRQCsBKdR9eg9FnUfdzRkn MECoa0EncwRyFaoTOfl77f90PupxeJt2JJm8i2ehAUuEK2UTVe3mYqd4YCok0ZDS9a1V d37Hvgr7QmpXuSCuVT/MUAR6Fuf85i8MUVVIvJ/3tuK3ZQeCkqRfShTnfc+Ztk6Je3BX 2jgwoSk8uUIkvdYyx5fH48L29P70gtizZ1CYc3RNd0xIRrCswkkdO3ohMmzsx5dle/2L 3XsA== 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=qmY5DvtRGqNJ8kQCNPGwJlb5aeZSsE/SWEGgaKmljZE=; b=GBJ/aH8H+Y+mt5BE5EzKLoeSDhvMgyc+1+tTVvQ379+p70iTc5I+iG2eNUFHBrtjOC 2IwN5tFc1aJ+Sg053ODG3NwCmTDHheruaMbD+nj+3n8hpuP7YtfqQUX25/f4NvNCbaj+ DJf3wBGHV/I5euvJdpwoUNER0Z8Z/M/IYE8hFn+iiuNBEoZn55pVXW3Qfg2iUrkBk1IN XMxb8VaNEnam7ZVIsBgwQ31qwtz2SECNDjz4/NUdwH2J8NLpF/85aq091adQQTAnIF5M bWFAZEDxsQFx8Aa30+cpcN4ktlRH2RW0X/3mGi7NGWKQ6zs8obNvtUqQ77w0xRuF7Zz3 HCXg== 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=qmY5DvtRGqNJ8kQCNPGwJlb5aeZSsE/SWEGgaKmljZE=; b=H2Mt3TFp6LUEusXhxC02ogwM4DryQhYm4c4oUJv0dM5g4PnBy4XA9q+tJYucqkb31o DtsOo39hV+oyJLMb9aKvbdb3l3+2NsVE2tdCXo+mTwMFTXyJB+iJ2A2Om3fZj/uZTUJ1 pwCR0/FObj9yV3HlXBSa2q1noZTWYGN1aqi/PWAWZ09PA6P1rxCIVP3XpBAhR1hmNa3E fCwZ7TaI3znygolucckF4pjH+FKwtn67vExakYy7h5+FRIvZ6GEjgcn46cd452U5VVY6 5KgpRlBj+opOSJkgOYPurM7dagE/QGlvcQAGAS9ykJnt8S+VQjDENrsyJSW/84xwu+1W RLKw== X-Gm-Message-State: AKwxytcGC8F3GFZrgSUWRbro1w3vA/liNCIs0Yg2bAcZxCT+CSuCmzXt DnUzpDI6LRF4LDfSAMZc0cwNtw== X-Google-Smtp-Source: AH8x2258joCGjKxxRaInMkmMqZDKBNRB3qaw4v/BMDA7K3IXwY9+F2otMrDYLNhXNQcYQ16kTSkbOg== X-Received: by 10.31.162.79 with SMTP id l76mr1988465vke.68.1516547033090; Sun, 21 Jan 2018 07:03:53 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.81.71 with SMTP id f7ls196833uaa.17.gmail; Sun, 21 Jan 2018 07:03:51 -0800 (PST) X-Received: by 10.31.160.5 with SMTP id j5mr487981vke.6.1516547031325; Sun, 21 Jan 2018 07:03:51 -0800 (PST) In-Reply-To: <7ce99930-b0b8-41cc-b3ea-7501e265bb62@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:36730 Archived-At: ------=_Part_1984_1120087284.1516547030674 Content-Type: multipart/alternative; boundary="----=_Part_1985_1183044891.1516547030674" ------=_Part_1985_1183044891.1516547030674 Content-Type: text/plain; charset="UTF-8" On Sunday, January 21, 2018 at 8:44:07 AM UTC-5, mihailn...@gmail.com wrote: > > 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. > But that wishy-washy-ness is exactly what makes this not a feature* of the standard*. It's a compiler tool or a static analysis tool, not something the standard can deal with. And quite frankly, if you have a static analysis tool that can do whole-program analysis, I'd bet that it could be smart enough to figure out that `observer_ptr` is not destroying the pointer it's given just by analyzing its member functions. So you don't even need that attribute to tell such a tool what's going on; just let it figure out which types are "observer" types. -- 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/f84c0f99-1ce6-493b-b7fc-3a643648c607%40isocpp.org. ------=_Part_1985_1183044891.1516547030674 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, January 21, 2018 at 8:44:07 AM UTC-5, mihailn..= ..@gmail.com wrote:
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 kno= w? If all the compiler in that translation unit sees is:

class<= /span> A_view
{
public:
=C2=A0 A_view(const A &p);

private:
=C2=A0 observer_ptr&= lt;A>= ; p_;
};

How could the compiler possib= ly 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 everythin= g. If `A_view` is in another translation unit that isn't visible to sta= tic analysis, this doesn't work.

You have to be more specific, might be my k= nowledge failing me, but what would prevent the compiler 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 look at the code and se= e that `A_view` contains a pointer/reference to that temporary. While the c= ompiler 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 as= sociate the constructor parameter with `A_view::p_`, because there is no co= de in this translation unit that associates the constructor parameter with = that member variable.

Yes, the compiler can see th= at two destructors are happening. But there is no evident association betwe= en 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 dec= laration 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 ob= server_ptr must be inlined. Luckily, that covers practically all views and = observer_ptr is a template already.
Surely it would be a noticea= ble limitation, but will not make the feature useless.=C2=A0

But that wishy-washy-ness is exactly what mak= es this not a feature of the standard. It's a compiler tool or a= static analysis tool, not something the standard can deal with.
=
And quite frankly, if you have a static analysis tool that c= an do whole-program analysis, I'd bet that it could be smart enough to = figure out that `observer_ptr` is not destroying the pointer it's given= just by analyzing its member functions. So you don't even need that at= tribute to tell such a tool what's going on; just let it figure out whi= ch types are "observer" types.

--
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/f84c0f99-1ce6-493b-b7fc-3a643648c607= %40isocpp.org.
------=_Part_1985_1183044891.1516547030674-- ------=_Part_1984_1120087284.1516547030674-- .