220 36694 <3a7fada1-f9f5-45d0-892f-74ccdf8eac2a@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: Thu, 18 Jan 2018 04:31:52 -0800 (PST) Lines: 3855 Approved: news@gmane.org Message-ID: <3a7fada1-f9f5-45d0-892f-74ccdf8eac2a@isocpp.org> References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2492_1402644001.1516278712798" X-Trace: blaine.gmane.org 1516278625 422 195.159.176.226 (18 Jan 2018 12:30:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Jan 2018 12:30:25 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBONHQLJQKGQEDLWMIAA@isocpp.org Thu Jan 18 13:30:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ec9KJ-0006e2-5z for gclcip-std-proposals@m.gmane.org; Thu, 18 Jan 2018 13:29:51 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id k20sf13019063vki.11 for ; Thu, 18 Jan 2018 04:31:55 -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=fSP3vnVOfSDFp+yTdG1q6Z6iJqcpy9qMiZ2IcHjqlr4=; b=EA7a7hXWS14p7FNNa49QebfH7Ag5JIuvLQfNgt2/zXHlk73ec8UfZec0Wi7OicYOVG JTxxDbUsOCFYrUf3ArCUbbDfoa7fdNQiHdoO3gz1Ih9BRJaDGecHVHZV0T+fB27zJrTh HVIyAODT3jXdvDLYS673zBoisNQo300wSHudRmcG7IKVdsgGPXGEwiWmBmk5i0I77MBp +3ANOl0v+47K6K4fHIpKzoonQ6Jb9MOXIMcNh1xapMAIFd9NJPnFZfW+8KPdjxJKbl87 D5SZ19eE5YBG/qNmcopiTyWipDWHlyllaLNtnzt8f4h1VlsN+30dE0nSSkYu8rzsmBcY knwQ== 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=fSP3vnVOfSDFp+yTdG1q6Z6iJqcpy9qMiZ2IcHjqlr4=; b=eGSwbpGhLMklyX7ZZ/k3z8sT+rrFkkopRBbn4EVh8tJm2Wh/wahqykeyMh5YuCy0vz K3ssnF1BOUKUr7FJgam+WWS9iK893Wl07q364CR0tApiGb5EAphWJVIZRspfwSOTQGyy w72QmhcfwAQ24QeC7pP13DuM4OiyKK/Vy6Bd1qdhzSp3R/CoxB2XwNSovXCabg43Ekvd jFGZkDWqKLRIlHzhStP6qLBoNxWffDS8smqDXtoqmaf5Gl4dxoSXaDEEXfmkcGbtLeRd FmQAihDyMl3eWbN+r/X1JgKUypVYu/WBTOL1Y+gZ6kKAvERK4IeHTHkbFFwDOXaPVKmx S7NA== 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=fSP3vnVOfSDFp+yTdG1q6Z6iJqcpy9qMiZ2IcHjqlr4=; b=pRQaZgjveOHA+kv4VvABDgO5Y2Uq+qUZG/SfGFtX7E9fCMokwl8IW60HMj68Q43Je+ cSkrtp6KGV1H2tXUIEHKSGeBf52/SzU0ykVAe4+nBZc1oohsGr9pFuGZqxHiXv5pdpq+ fCePjg1w+U9VPeHqACvbXwZQmY2x2BF7xyKBUlvgMjdppa1DEDdaFawwa7i8dfPbb61u BhObdUxc/BWKN52YMlUIT6S0mwSMT7mNJntLuGFceDOOGAxZX+SF0c5O/grtctPT4LQv Q5ILwgtotXqrGFh2squAwDKHZGoAgL50hF75x8eCfrEzGElJvD0w6ZV2KNTBsM1w8YII 6K+Q== X-Gm-Message-State: AKwxytew6mk8UfMS72v4HcL7h6tfKa4/oKfp+kOXrb6aVdsl1PuWuz8v 8qclWqjuwYFAuuu+VaZ7H61/Rg== X-Google-Smtp-Source: ACJfBouq/L74n2EP4BxgTW71a8bl5M4gNyROg2e/iUhxoHGyewGziPc98W1HEkQG2DPXZf8JXkcc4g== X-Received: by 10.176.30.66 with SMTP id n2mr3214567uak.118.1516278715110; Thu, 18 Jan 2018 04:31:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.39.74 with SMTP id a68ls3068037uaa.5.gmail; Thu, 18 Jan 2018 04:31:53 -0800 (PST) X-Received: by 10.31.115.5 with SMTP id o5mr393638vkc.12.1516278713335; Thu, 18 Jan 2018 04:31:53 -0800 (PST) In-Reply-To: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> 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:36694 Archived-At: ------=_Part_2492_1402644001.1516278712798 Content-Type: multipart/alternative; boundary="----=_Part_2493_1779585719.1516278712802" ------=_Part_2493_1779585719.1516278712802 Content-Type: text/plain; charset="UTF-8" For the sake of completeness, in cases when the viewed class creates the view, then the && overload should be marked as [[dependent_lifetime]] class string { ... [[dependent_lifetime]] operator string_view() && { return {c_str(), size()}; } //< (probably not the correct place to set the attribute, but you get the idea) }; Now the returned value (the variable created from it) depends on the lifetime of *this and should not be used after *this is dtor is called. *Further investigation * Consider that case: void f() { string_view v; if(const auto str = getString(); str == "something") { v = str; } * // 'v' is either empty or dangles!* } The above mistake can happen even to an experienced programmer (if he is used to ref-counted strings for instance). People learning C++ and junior developers are basically guaranteed to fall in there at some point. Here it is *painfully* obvious the compiler knows the right usage - he just keeps it shut! We *should* be able to make him speak. BTW, that is an interesting case, as it is not about initialization, but assignment. However, does it matter? It is still clear the scope of tracking - from assignment tor dtor. Even if we have a more involved case void f( string_view& v) { if(const auto str = getString(); str == "something") { v = str; } } int main() { string_view& v; f(v); return 0; } The compiler still knows all that is needed, doesn't it? As long as the view is an automatic variable the compiler can always detected if, during its lifetime, it is used after the pointed-to dtor is called. Isn't that *always* the case? Isn't that that case *even if* the pointed-to is heap allocated? o_view v = o_p->getView(); The compiler can *still* tell if *o_p is destroyed before v is destroyed. Am I mistaken here? Considering view classes are 99.9% of the time used as automatic variables, there is no good reason for them to be unsafe. (Or maybe there is, I might be missing something) And lets talk copies. Nothing is actually preventing this tracking to work for copies of the view as well - the rules are exactly the same - if before view.~view() there is a call to object.~object() there should be no view,access(). How many views are, it does not matter at all as long as they are automatic. It also does not matter if ~object() was called by the compiler (automatic), the user (delete p_object;) or by a ref counted shared_ptr! With that in mind. void f(view vb) //< by copy { destroy_b_unknowingly(); vb.use(); //< warning, dtor of b was called already } Even further investigation template class unique_ptr { ... [[dependent_lifetime]] T* get() { return _p; } ... T* _p; }; Now the variable of type T* is a view to the unique_ptr. If ~unique_ptr() is called before the (automatic) T* variable, created/assigned by get, goes out of scope, it will be an error to use that variable. But, lets take this to the next level: template class unique_ptr { ... [[dependent_lifetime(*_p)]] T* get() { return _p; } ... T* _p; }; Now it is an error to use T* after ~T(), and ~T(), can come from any place - shared_ptr, manual delete, another, moved into unique_ptr. Everywhere. And the rules are still the same - no use of this T* variable, after a ~T(), until this T* variable goes out of scope ("as if" it has a dtor called). The relationship is still b/w an automatic variable and a dtor call. Am I fooling myself here? Isn't that mighty useful? Isn't that all implementable today? What is the harm - it does not even writes off lifetime extension and what not - it just reinforces safe use of the language, the way this language is right now. No new semantics, no new rules! (Arguably, no new tooling) -- 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/3a7fada1-f9f5-45d0-892f-74ccdf8eac2a%40isocpp.org. ------=_Part_2493_1779585719.1516278712802 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the sake of completeness, in cases when the viewed cla= ss creates the view, then the && overload should be marked as [[dep= endent_lifetime]]=C2=A0

class string
{
=C2=A0 ...
=C2=A0 [[dependent_lifetime]] operator string_view() && { return {c_s= tr(), size()}; } //< = (probably not the correct place to set the attribute, but you get the idea)=
};

Now the returned value = (the variable created from it) depends on the lifetime of *this and should = not be used after *this is dtor is called.=C2=A0



Fu= rther investigation=C2=A0


Consider that case:

void f()
{
=C2= =A0 string_view v;
=C2=A0
=C2=A0if(const auto str =3D getString= (); str =3D=3D "something")
=C2=A0{
=C2=A0 =C2=A0 v =3D str;
= =C2=A0}
=C2=A0=C2=A0
=C2=A0// 'v' is either empty or dangles!
}

The above mistake can happen even to an ex= perienced programmer (if he is used to ref-counted strings for instance). P= eople learning C++ and junior developers are basically guaranteed to fall i= n there at some point.

Here it is painfully obvious the compiler knows the r= ight usage - he just keeps it shut! We should be able to make him speak.

BTW, that = is an interesting case, as it is not about initialization, but assignment. = However, does it matter? It is still clear the scope of tracking - from ass= ignment tor dtor.

Even if we have a more involved cas= e

void f( string_vi= ew& v)
{=
=C2=A0if(const auto str =3D getString();= str =3D=3D "something")
=C2=A0{
<= span style=3D"background-color: transparent; border-bottom-color: rgb(34, 3= 4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o= utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im= age-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34)= ; border-left-style: none; border-left-width: 0px; border-right-color: rgb(= 34, 34, 34); border-right-style: none; border-right-width: 0px; border-top-= color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; colo= r: rgb(34, 34, 34); display: inline; float: none; font-family: courier new;= font-size: 13px; font-style: normal; font-variant: normal; font-weight: 40= 0; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-rig= ht: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0p= x; padding-right: 0px; padding-top: 0px; text-align: left; text-decoration:= none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0= px; white-space: normal; word-spacing: 0px;">=C2=A0 =C2=A0 v = =3D str;
=C2=A0}
}

int main()=
{
=C2=A0string_view& v= ;
=C2=A0f(v);

=C2=A0return 0;<= /div>
}


=
Isn't t= hat always the case? Isn't= that that case even if the=C2= =A0pointed-to is heap al= located?=C2=A0

o_view v =3D o_p->getView();
=
The compil= er can still tell if *o_p is d= estroyed before v is destroyed. Am I mistaken here?=C2=A0

Considering view classes are 99.9% of the time used as automatic vari= ables, there is no good reason for them to be unsafe. =

(Or maybe there is, I might be miss= ing something)

= =
And lets talk copies.

=
Nothing is actually preventing this tracking to work for copies o= f the view as well - the rules are exactly the same - if before view.~view(= ) there is a call to object.~object() there should be no view,access().

How many views are, it does not matter at all as long as= they are automatic.

It also does not matter if ~obje= ct() was called by the compiler (automatic), the user (delete p_object;) or= by a ref counted shared_ptr!


With that i= n mind.

void f(view<B> vb) //< by copy
<= div style=3D"background-color: transparent; border-bottom-color: rgb(34, 34= , 34); border-bottom-style: none; border-bottom-width: 0px; border-image-ou= tset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-ima= ge-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34);= border-left-style: none; border-left-width: 0px; border-right-color: rgb(3= 4, 34, 34); border-right-style: none; border-right-width: 0px; border-top-c= olor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color= : rgb(34, 34, 34); font-size: 13px; font-variant: normal; letter-spacing: n= ormal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top:= 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0p= x; padding-top: 0px; text-align: left; text-indent: 0px; text-transform: no= ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;= ">{
=C2=A0=C2=A0 destroy_b_unknowingly();

=C2= =A0 vb.use(); //< warning, dtor of b was called already
}
=



Even further investigation
<= div style=3D"background-color: transparent; border-bottom-color: rgb(34, 34= , 34); border-bottom-style: none; border-bottom-width: 0px; border-image-ou= tset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-ima= ge-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34);= border-left-style: none; border-left-width: 0px; border-right-color: rgb(3= 4, 34, 34); border-right-style: none; border-right-width: 0px; border-top-c= olor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color= : rgb(34, 34, 34); font-size: 13px; font-variant: normal; letter-spacing: n= ormal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top:= 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0p= x; padding-top: 0px; text-align: left; text-indent: 0px; text-transform: no= ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;= ">
template<class T>
class unique_ptr
{
=C2=A0 ...
=C2=A0=C2=A0 [[dependen= t_lifetime]] T* get() { return _p; }
=C2=A0 ...
=C2= =A0 T* _p;
};
=

Now the variable of type T* is a view to the unique_ptr. If ~= unique_ptr() is called before the (automatic) T* variable, created/assigned= by get, goes out of scope, it will be an error to use that variable.=C2=A0=


But, lets take this to the next level:

template<class T>
class unique_ptr
{
= =C2=A0 ...
=C2=A0=C2=A0 [[dependent_lifetime(*_p)]] T* get() { return _p; }
=C2=A0 ...
=C2=A0 T* _p;
};
<= i>

Now it is an error to use T* after ~T(), and ~T(),=C2=A0 can come from a= ny place - shared_ptr, manual delete, another, moved into unique_ptr. Every= where.

And the rules are still the same - no use o= f this T* variable, after a ~T(), until this T* variable goes out of scope = ("as if" it has a dtor called).=C2=A0

Th= e relationship is still b/w an automatic variable and a dtor call.=C2=A0



Am I fooling myself he= re? Isn't that mighty useful? Isn't that all implementable today? What is = the harm - it does not even writes off lifetime extension and what not - it= just reinforces safe use of the language, the way this language is right n= ow.

No new semantics, no new rules! (Arguably, no= new tooling)




--
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/3a7fada1-f9f5-45d0-892f-74ccdf8eac2a= %40isocpp.org.
------=_Part_2493_1779585719.1516278712802-- ------=_Part_2492_1402644001.1516278712798-- .