220 36731 <8033786d-9929-47fa-9ddb-d12a47408660@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 08:57:06 -0800 (PST) Lines: 248 Approved: news@gmane.org Message-ID: <8033786d-9929-47fa-9ddb-d12a47408660@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> <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_2316_64331752.1516553826253" X-Trace: blaine.gmane.org 1516553722 6487 195.159.176.226 (21 Jan 2018 16:55:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Jan 2018 16:55:22 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBY4MSPJQKGQEOT2G5BI@isocpp.org Sun Jan 21 17:55:17 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edItc-0000fR-Mu for gclcip-std-proposals@m.gmane.org; Sun, 21 Jan 2018 17:55:04 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id d130sf4052520vkf.6 for ; Sun, 21 Jan 2018 08:57:09 -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=1Qc7z2NamUKToWRQTYmwJImnfAABkF3Y+PmaIS9OvxQ=; b=Dw1ax9dbkZJ5kFKKBURwHgMXiyWgV40/dYfjY9a3djuiHqgAWlW5Ul8/1Kj4TYN1bp ASISWUKKnwX0uCJNlYHvavy37Fw7aQwjcgJabxmUQIqJB+SuS9MF/EyZuPtzb7kSClxs 1NlNy8e9YEuhejKUVPLoHRpF+utLDKYBImjU/Gx7KWIwGVYR3aRyMtyKcCDMz9NsKteP +DRTUeHWWWOnBJt1yM7M2hTZAo2j3YlHypTg3GEDM98BlOYL36OGiKl8pcMihyDr9hbZ DPyE1sZ7amh4TFdc0m2hctgMXeZjuAp+rpNqGJjDHhMYmeDJfcSzi2hmmtJ2ZttYhfma kCTQ== 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=1Qc7z2NamUKToWRQTYmwJImnfAABkF3Y+PmaIS9OvxQ=; b=HvcwrtQMib1KDBJi0/2V/mOYMbXstPqzIPWYNsROQtbyVQ9j5cnzVqMHJHxEgMY61M rc2q593xpQZ4I25CX4bnm+ibxv1kzUBKT7QhJgS5N6z84Wy/RuOK5OKE/YDXu+kJs5hk aB/0y1kMZ8pP4UGXdXz2SDU1Mi0mnrcq5zfQLoUNu0VOD5Mcrpbhmr9SMPzbNr+MTLsB Kmw0jM92/oE+dhvWMCj7PUNWr7QQO842JANWvOLxc4kn+Bab+hMkgyYYCDf9Pp9djEmE 4CDdRSXzQ5lXriIkfZ3jPqagqmPuyOHYuf5UQ1bZh9pno376Xim76p3SkU6SG3c0Ijwj tDAQ== 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=1Qc7z2NamUKToWRQTYmwJImnfAABkF3Y+PmaIS9OvxQ=; b=qaXnbabMlzF0CL77zsjIB3DOd0PpR9bXX2Sx3/oi3nfyMcJjdWJuZ4Q+UcCAoKf+Od G0+VeyfdKt2T1/hrpYWwcyHFEpRPIe5FADZl+b5aFtIb5rIdytQbTFLaW4Tu+44kapIm HI22rv4HATl4JZtW2nRWKINhxHSDWk7UZjtbOykQY4+WS1ZMe/bm1Ajr57SmPSTDXDvl mCGiZy4beVSJmoNIC78BXYc1s5ixs7ymD+gwFGdiBZUfyp8h4CPeg6Rh/klP/4istlwT T4buNULu4NVQpC/jk8dIe3dAoaA3UQozlKZojxkWdcOjgJWJZHTurgw3d7781Ad95fBD /dvA== X-Gm-Message-State: AKwxyte3eECgxaRZ0UtwNwkfQRl6/yf+Y0PDjOBd+yxNUiPT66lBjF8j xcTNmUiqeOGq+4hQ7IoQ7Lj1cw== X-Google-Smtp-Source: AH8x224zkDkc0tX3nOZeX8VNO2eWmBsgDqdBMGGq2beq8tPbO70yGO0vBDAZJDoI0VHdYRxWyGfuSQ== X-Received: by 10.176.24.195 with SMTP id d3mr2708223uah.69.1516553828642; Sun, 21 Jan 2018 08:57:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.41.211 with SMTP id p202ls1401345vkp.17.gmail; Sun, 21 Jan 2018 08:57:07 -0800 (PST) X-Received: by 10.31.168.202 with SMTP id r193mr508943vke.4.1516553826663; Sun, 21 Jan 2018 08:57:06 -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:36731 Archived-At: ------=_Part_2316_64331752.1516553826253 Content-Type: multipart/alternative; boundary="----=_Part_2317_35507188.1516553826254" ------=_Part_2317_35507188.1516553826254 Content-Type: text/plain; charset="UTF-8" On Sunday, January 21, 2018 at 5:03:50 PM UTC+2, Nicol Bolas wrote: > > 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. > Without decoration it will not know to look in that TU. Actually the other way around - TU will be ignored unless a type it exports (or uses) is decorated. Even if all units use an observer pointer, not all pointers or objects will be an observer or decorated. Looking for specific pointers should be faster then looking for all pointers, among a bunch of other things as well. About wishy-washy-ness. The implementers will say what it is feasible, much like it is today with other features. They can also say what is required to improve their work - what sort of decorations, where. Considering C++ already defined an interface to communicate with the implementations - the attributes - I don't see a reason not to use that interface to improve *both *the implementation and the language (as experience, not semantics). But, OK, fine, do not define these in "The C++ standard", define them as part of "C++ Guidelines" - it is, after all, for the correct use of the language. The point is, ignoring and/or not helping the tools is a game where *everybody* loses. -- 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/8033786d-9929-47fa-9ddb-d12a47408660%40isocpp.org. ------=_Part_2317_35507188.1516553826254 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, January 21, 2018 at 5:03:50 PM UTC+2, N= icol Bolas wrote:
On Sunday, January 21, 2018 at 8:44:07 AM UTC-5, mihailn...@gmail.co= m wrote:
On Sun= day, 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
{<= span style=3D"color:#000">
public:
=C2=A0 = A_view(= const A &p= );

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

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

=
A_view v(A= {});

We're not talking about runtime detection here; this is purely compil= e-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 fa= iling me, but what would prevent the compiler seeing in the case when are t= he dtros of both variables called?=C2=A0

<= /div>
In order for the compiler to be able to associate the prvalue tem= porary with `A_view`, it must be able to look at the code and see that `A_v= iew` contains a pointer/reference to that temporary. While the compiler can= see that `A_view`'s constructor is being given a pointer to a temporar= y, 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 dest= ructors are happening. But there is no evident association between these tw= o objects. And without that knowledge, the compiler has no right to declare= that this code is problematic.

This is why you ne= ed the annotation to be part of the declaration. Because the declaration ma= y be the only thing the compiler will ever see.


I see, you mean that only the A_view ctor i= s 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_pt= r is a template already.
Surely it would be a noticeable limitat= ion, but will not make the feature useless.=C2=A0
<= div>
But that wishy-washy-ness is exactly what makes this not= a feature of the standard. It's a compiler tool or a static ana= lysis tool, not something the standard can deal with.

<= div>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 an= alyzing 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 ar= e "observer" types.

<= br>

Without decoration it will not know to look in= that TU. Actually the other way around - TU will be ignored unless a type = it exports (or uses) is decorated. Even if all units use an observer pointe= r, not all pointers or objects will be an observer or decorated.
= Looking for specific pointers should be faster then looking for all pointer= s, among a bunch of other things as well.=C2=A0

About wishy-washy-ness.
The implementers will say w= hat it is feasible, much like it is today with other features. They can als= o say what is required to improve their work - what sort of decorations, wh= ere.=C2=A0
Considering C++ already defined an interface to commun= icate with the implementations - the attributes - I don't see a reason = not to use that interface to improve both the implementation and the= language (as experience, not semantics).

But, OK,= fine, do not define these in "The C++ standard", define them as = part of "C++ Guidelines" - it is, after all, for the corre= ct use of the language.

The point is, ignoring an= d/or not helping the tools is a game where everybody loses.

=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/8033786d-9929-47fa-9ddb-d12a47408660= %40isocpp.org.
------=_Part_2317_35507188.1516553826254-- ------=_Part_2316_64331752.1516553826253-- .