220 36728 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 17:45:37 -0800 (PST) Lines: 139 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_564_341905671.1516499137280" X-Trace: blaine.gmane.org 1516499040 6099 195.159.176.226 (21 Jan 2018 01:44:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Jan 2018 01:44:00 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBQXBR7JQKGQEFEAGGFA@isocpp.org Sun Jan 21 02:43:55 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ed4fY-0000Db-Ed for gclcip-std-proposals@m.gmane.org; Sun, 21 Jan 2018 02:43:36 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id g185sf3435484vkd.2 for ; Sat, 20 Jan 2018 17:45:41 -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=foQ/G9iJyQqcjzhiB45c5sFIRIqhk3/xR+VosiExyKo=; b=r1tqFL7FCewgFOSYfkLFY1H7mhKBlYS37Xsf9V5jDCyNnlUpbIti8/Z0NlAnnhTj5M cM0QnjdDRcbUvHnQYvARtKYNSbKIFcgSy5Oa4tibYQjoG7Vd8TvSxhtj7awmQB4E+1O4 PGKTWhYiUZaNA99hLFd9WAapxMH+BxEVw6WTIpO6yB33p0TcFuZjMC5c0gZMKmwCIZv5 bK5RFXByZh+Ek1Z9VATsC0UEVN2+4WCQMO8jkAmibPby4nat2UYMgWpbvCwbVqzQJ5XT JbEXL8FVETwsbkVdu+sBYMoLB+5o1KsLTo6kN+poDxnXlL1wZpkLNGmv38SaTgoOyEOx xkwQ== 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=foQ/G9iJyQqcjzhiB45c5sFIRIqhk3/xR+VosiExyKo=; b=OF2sZ2OkeHfvCmLPwWv0q/6BUQ61p1cCaL6YpI3IzcoaDix83DNyfyAKIk32J8JJEu vFLUoKCDCZBu1pdx0jIjfiT4Ca8/GWKtNClGDvd1LL1T9Tyc8ngMtIN5OvhXOOXLZYLt JSItplvVGq1Ynje1aR0VloY9oPEF/b2oP2encIOkaloD0kDv7lnc8scu1xGxi8R5N0h/ Rqo8H+ABukfrIxq4VTqXgvaiQ5QolMOUJgVH/mjSBxkf0ZiCGkY70YTIqXZNtZD33dz1 gJyo+EvmPnB5IcVoGrMpUM8OQ1aiq3Y1f7bBALTBHFz7rwpqvWxs0T3g3dtILjt798di AAFw== 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=foQ/G9iJyQqcjzhiB45c5sFIRIqhk3/xR+VosiExyKo=; b=EEDP/1+1iqbroHI+EkjwKEBV6MyyVWrrIkJrXnbP6L40LC3BIY2hVGFFqqN6qkLM9Q hLFSBOi56rmyLB1J/aple43ynrWUA/bZ7P5inMFLjPrb7Sg8l/EYuXHaTPqalJL3Lg2M cKHBb4DtCbjV5NtmUhSM+4SBLkRCEo9pGU5e5ssw+hemSwJGI+9GZ1QyMfS70KCHQnrT +IJaoWTUBbPX1LGLsb3BH5ttLdItAaM5dPjI31cZiAXcQF97reyxrb1Qnsq8OTES45h4 u2y+HSDv9X6Bt5H3JRFJEV36PVjSF3XSZ/U0Wk+hrZ0Y8m94S8gFn+ve75MyX1lsASut 9nzg== X-Gm-Message-State: AKwxytfyTRLNPtc9MXoEcs4tp5GEXVQnvr44ut74JLTJu2E33jSarSLQ TYx3Dmyh7cS3U7N5XmLkC7THvA== X-Google-Smtp-Source: AH8x226zCSj/RtBj/cEGuK7//N2cDHVclG8FVrl99E8p4q80fuNhccFcP8tbdM5vqv1Xps5MfQ+Kbw== X-Received: by 10.159.59.217 with SMTP id y25mr1716454uah.79.1516499139493; Sat, 20 Jan 2018 17:45:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.67.196 with SMTP id q187ls1427002vka.21.gmail; Sat, 20 Jan 2018 17:45:37 -0800 (PST) X-Received: by 10.31.178.206 with SMTP id b197mr309912vkf.11.1516499137877; Sat, 20 Jan 2018 17:45:37 -0800 (PST) In-Reply-To: <73c5d690-f05d-4e72-a685-3c55d8be0f8e@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:36728 Archived-At: ------=_Part_564_341905671.1516499137280 Content-Type: multipart/alternative; boundary="----=_Part_565_1545774573.1516499137280" ------=_Part_565_1545774573.1516499137280 Content-Type: text/plain; charset="UTF-8" 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. -- 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/f8d52182-5aef-476b-b0bb-047843c17e2a%40isocpp.org. ------=_Part_565_1545774573.1516499137280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 wro= te:
...
=

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

class A_vie= w
{<= br>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 abo= ut runtime detection here; this is purely compile-time. And the compiler do= esn'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 prev= ent the compiler seeing in the case when are the dtros of both variables ca= lled?=C2=A0

In order for the co= mpiler 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/refer= ence to that temporary. While the compiler can see that `A_view`'s cons= tructor 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 associa= tes the constructor parameter with that member variable.

Yes, the compiler can see that two destructors are happening. But th= ere is no evident association between these two objects. And without that k= nowledge, the compiler has no right to declare that this code is problemati= c.

This is why you need the annotation to be part = of the declaration. Because the declaration may be the only thing the compi= ler will ever see.

--
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/f8d52182-5aef-476b-b0bb-047843c17e2a= %40isocpp.org.
------=_Part_565_1545774573.1516499137280-- ------=_Part_564_341905671.1516499137280-- .