220 36703 article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Static analysis and the future of C++ Date: Thu, 18 Jan 2018 09:25:53 -0800 (PST) Lines: 454 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <6e78f3c4-267d-40c4-bcde-a026e90c3838@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3305_1147788563.1516296353442" X-Trace: blaine.gmane.org 1516296250 23107 195.159.176.226 (18 Jan 2018 17:24:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Jan 2018 17:24:10 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBIVRQPJQKGQESVJU3OY@isocpp.org Thu Jan 18 18:24:06 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecDup-000519-OW for gclcip-std-proposals@m.gmane.org; Thu, 18 Jan 2018 18:23:52 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id q28sf15663528uaa.6 for ; Thu, 18 Jan 2018 09:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=jNZ+gg3SDCzS2WlpUzE8bGaNvg3WrbG0q2VoqxJRYvo=; b=xPzeAhe/GyDTF5SeFi5cX3yyd3GO/cyayMzoModdD3kCRt4MNTfPhvd4IviTVH/7Vp EAEvrdkxkRjm346EkTe61umrqGEsVCNz/y16aN/fBRn1O1p5TP82LgJkXMsafoCetH9F 6oeYdHvVjFTQdG9pJNULeQXAljC0ddONlwmeGPscZrTz8Cd6NQSA0IJC3EQW3saCho2w FnLtXxJlI79Ju3y1YViSTzi5uswPBe8karHa1VMlDgSxQSwSivGTu+74oe417WIeKUff HLn16cZagP71Rv8WyARzE5VQnaZ2odUlfUHCVK4EpFzYfHqWSWQvDQEzXQM+cwokBVdL Jadw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=jNZ+gg3SDCzS2WlpUzE8bGaNvg3WrbG0q2VoqxJRYvo=; b=Lhl9r3lGOjo+rgB1Jf9vMgo9YEMZeR4XUuMjQAtmc6pyZz2yC8YnnFybADdLvaoUHG 0WocAEq4VKJkceBkEtjSmJAChCx0BwJ5xkOA4ns4qxvrLmOih25uQ/tVcJf8DQNMgUlB DakSwRvNF58gGOd0K0dEUa96LJPy25mEm1e1kWecCTwbwZ760a/4VutG+iGPQoTxg80f sC6/0ssYpDtekBuIQTrkhQ8W5seVDEIcoLRHRwldJ9yweOTXOPUXkSQSlKlH4/ySiCKl yXetCmFZqO8SBQlzDQYqpnIKAynKUQUhUE7Yddo7maTR/nHObzBQXYwwAaZdfn36om4b oRBg== 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: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=jNZ+gg3SDCzS2WlpUzE8bGaNvg3WrbG0q2VoqxJRYvo=; b=it//5G3UvmtTZ+Z3MCLSP2EWnL64V9cgAQBPAWTc909rFgI4uU51xOg1ruwL+5cROJ /TQeKGBbitfPbcuuekSPA1mImcEBelFoLcvcvHfwnhb3ILIwjddnoZ0RbT4Fu9cztALr 6NLHXPfOYI6d5DxQAGnUdZaxxbWwFguS3JhbuOmlc/FddYxAlFKHOfISc42zStYyLKdk Aq/b9pj6tPglrXYdSzbXo55e5S5ryy69Iza2FeAPMOzot6T5fCazb5ZIxbE0kFtEh6Wr s+XIJuU8spH9N9K1nKasa/KtteQ0rCKkaY5KchqWfdMw7trFARxsi/Tcij5sg+irtuTR wO1w== X-Gm-Message-State: AKwxytd/SYSIZ3zz274R9gebmBi3uw0WKrTJ/8XfBjlG1r8qXHXmgX6Z dvvhbJL5+TaPn6W/4t7W0KixFg== X-Google-Smtp-Source: ACJfBouPN61xCGr8vN/IiJiv4cQkACTvwO/rVE3En8mAWgK6amS+EiGQx49O2TeG2pCr0LyKOWRYWQ== X-Received: by 10.176.73.200 with SMTP id f8mr3345533uad.19.1516296355675; Thu, 18 Jan 2018 09:25:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.72.37 with SMTP id b34ls3280841uad.13.gmail; Thu, 18 Jan 2018 09:25:54 -0800 (PST) X-Received: by 10.31.48.85 with SMTP id w82mr573599vkw.11.1516296353907; Thu, 18 Jan 2018 09:25:53 -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:36703 Archived-At: ------=_Part_3305_1147788563.1516296353442 Content-Type: multipart/alternative; boundary="----=_Part_3306_1297655227.1516296353443" ------=_Part_3306_1297655227.1516296353443 Content-Type: text/plain; charset="UTF-8" On Thursday, January 18, 2018 at 4:40:58 PM UTC+2, Richard Hodges wrote: > > On the whole I completely agree with you. > > However: > > auto up1 = std::make_unique(5); > auto p = up1.get(); // dependent... > auto up2 = std::move(up1); // ...sort of > This is completely defined as per second suggested declaration of get(). [[dependent_lifetime(*_p)]] T* get() { return _p; } p, still depends on the lifetime of the object returned by the new int(5) call inside make_unique. All the fancy pointers and/or classes we delegate the lifetime of the int to, will not hide *when* the delete on that int is called. If this happens before p is out of scope *and* we try to use p, then we error out. > > std::string_view should never have been implicitly convertible from > std::string. Unhappily, the committee seems to favour encouraging > dangerous coding practices at the moment. > If not with string it will happen with something else - spans, function_view etc - and most of the time it is expected to be able to just call the function the way you normally would. Also, making the conversion explicit buy us too little I think - users will need to create views explicitly and still shoot themselves by using temporal objects. > Consider: > > std::string foo(); > > std::string_view x = foo(); > x.anything(); // boom! > > whereas: > std::string const& x = foo(); // perfectly safe > auto x = foo(); // again, safe > auto&& x = foo(); // yet again > That is why I really hope some work is done to mandate warnings in a well defined manner, instead of waiting the implementations to fill the gap by they own initiative, like always. As said, more views are coming! > > IMHO proliferating reference types in the c++ standard library is a grave > error which will haunt us for years. > I personally like them, because of the abstraction - a base type am guaranteed to be able to convert to. It is really a form of abstract base class, but without all the hierarchy requirements and indirection. Also, a thing like function_view will enable us to finally have functor pointers - cheap almost zero-cost pointers to anything callable, lambda included. There is no alternative to that now - you either must use a template, or commit to a representation (and conversion) to something like std::function or my_function or whatever. > > > > > On 18 January 2018 at 13:35, > wrote: > >> 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! >> >> >> -- >> 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-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> To view this discussion on the web visit >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6e78f3c4-267d-40c4-bcde-a026e90c3838%40isocpp.org >> >> . >> > > -- 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/f9301aab-d8c5-4558-a597-5b3d666c4b11%40isocpp.org. ------=_Part_3306_1297655227.1516296353443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thursday, January 18, 2018 at 4:40:58 PM UTC+2,= Richard Hodges wrote:
On the whole I completely agree with you.

Howev= er:

auto up1 = =3D std::make_unique<int>(5);
auto p =3D up1.get();=C2=A0 =C2=A0// dependent...
auto up2 =3D std::move(up1);=C2= =A0 // ...sort of

This i= s completely defined as per second suggested declaration of get().

[[dependent_lifetim= e(*_p)]] T* get() { return _p; }

p, stil= l depends on the lifetime of the object returned by the new int(5) call inside make_unique.=C2=A0

All the fancy pointers and/or classes we delegate t= he lifetime of the int to, will= not hide when the delete on that int is called. If this happens before p is out of scope and we try to use p, then we error out.

=C2=A0

std::string_view should never have been implici= tly convertible from std::string= .. Unhappily, the committee seems to favour encouraging dangerous coding pra= ctices at the moment.

If not w= ith string it will happen with something else - spans, function_view etc - = and most of the time it is expected to be able to just call the function th= e way you normally would.=C2=A0

Also, making the c= onversion explicit buy us too little I think - users will need to create vi= ews explicitly and still shoot themselves by using temporal objects.=C2=A0<= /div>
=C2=A0
Consider:

std::string foo();

std::strin= g_view x =3D foo();
x.= anything(); // boom!

whereas:
std::string const& x =3D foo();=C2=A0 = // perfectly safe
auto= x =3D foo(); // again, safe
auto&& x =3D foo(); // yet again

That is why I really hope some work is done to mand= ate warnings in a well defined manner, instead of waiting the implementatio= ns to fill the gap by they own initiative, like always.=C2=A0
As said, more views are coming!
=C2=A0

IMHO proliferating reference types in the c++ standard library is= a grave error which will haunt us for years.

I personally like them, because of the abstraction - = a base type am guaranteed to be able to convert to. It is really a form of = abstract base class, but without all the hierarchy requirements and indirec= tion.

Also, a thing like function_view will enable= us to finally have functor pointers - cheap almost zero-cost pointers to a= nything callable, lambda included.

There is no alt= ernative to that now - you either must use a template, or commit to a repre= sentation (and conversion) to something like std::function or my_function o= r whatever.=C2=A0
=C2=A0




On 18 January 2018 at 13:35, <mihailn...@gmail.co= m> wrote:
=
For the sake of completeness, in cases when the viewed class= creates the view, then the && overload should be marked as [[depen= dent_lifetime]]

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

Now the retu= rned 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()
= {
=C2=A0 string_view v;
=C2=A0
=C2=A0if(const auto str =3D getStri= ng(); str =3D=3D "something")
=C2=A0{
=C2=A0=C2=A0=C2=A0 v = =3D str;
=C2=A0}
=C2=A0
=C2=A0// 'v' is either empty or d= angles!
}

The above mistake can happen even to an experienced programme= r (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 poi= nt.

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

BTW, that is an interesting cas= e, as it is not about initialization, but assignment. However, does it matt= er? It is still clear the scope of tracking - from assignment tor dtor.

Even if we have a more involved case

void f( string_vi= ew& v)
{
=C2=A0if(const auto str =3D getString(); str =3D= =3D "something")
=C2=A0{
=C2=A0=C2=A0=C2=A0 v =3D str;
= =C2=A0}
}
i= nt main()
{
=C2=A0string_view& v;
=C2=A0f(v);
=C2=A0return 0;
}

The compiler st= ill knows all that is needed, doesn't it? As long as the view is an aut= omatic variable the compiler can always detected if, during its lifetime, i= t is used after the pointed-to dtor is called.
Isn't that alw= ays the case? Isn't that that case even if the pointed-to is heap alloc= ated?

o_view= v =3D o_p->getView();

The compiler can still tell if *o_p is destroyed= before v is destroyed. Am I mistaken here?

Consi= dering view classes are 99.9% of the time used as automatic variables, ther= e is no good reason for them to be unsafe.

(Or ma= ybe there is, I might be missing something)

And lets talk copies.

Nothing is actua= lly preventing this tracking to work for copies of the view as well - the r= ules are exactly the same - if before view.~view() there is a call to objec= t.~object() there should be no view,access().
How many views are= , it does not matter at all as long as they are automatic.
It al= so 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.

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

Even further= investigation

template<class T>
class unique_ptr
{
=C2=A0 ...=
=C2=A0 [[dependent_lifetime]] T* get() { return _p; }
=C2=A0 ...
= =C2=A0 T* _p;
};
<= /font>
Now the variable of type T* is a view to the unique_ptr. If ~uniq= ue_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 T>
class unique_ptr=
{
=C2=A0 ...
=C2=A0 [[dependent_lifetime(*_p)]] T* get() { return= _p; }
=C2=A0 ...
=C2=A0 T* _p;
};

Now it is an error to use T* a= fter ~T(), and ~T(),=C2=A0 can come from any place - shared_ptr, manual del= ete, another, moved into unique_ptr. Everywhere.
And the rules ar= e 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. <= /div>

Am I fooling myself here? Isn't that mighty us= eful? 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 semanti= cs, no new rules!


--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
 To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/6e78f3c4-267d-40c4-bcde-= a026e90c3838%40isocpp.org.

--
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/f9301aab-d8c5-4558-a597-5b3d666c4b11= %40isocpp.org.
------=_Part_3306_1297655227.1516296353443-- ------=_Part_3305_1147788563.1516296353442-- .