220 36714 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: Fri, 19 Jan 2018 04:30:52 -0800 (PST) Lines: 260 Approved: news@gmane.org Message-ID: 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_5866_1096684638.1516365052739" X-Trace: blaine.gmane.org 1516364950 31597 195.159.176.226 (19 Jan 2018 12:29:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2018 12:29:10 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRB7OJQ7JQKGQEY7MJXCA@isocpp.org Fri Jan 19 13:29:06 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 1ecVmt-00071r-FE for gclcip-std-proposals@m.gmane.org; Fri, 19 Jan 2018 13:28:51 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id q68sf814955vkb.7 for ; Fri, 19 Jan 2018 04:30: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=h7bHBsCo1S+Jc4SgFduPQ3fIFfuHtuALU5qy7jO0lRg=; b=D85fli28EWgeQidrnFqSW/aBuyahpq/HlXggk9F2eb7WPmP85ZobezstWQViOS8pLk imR5xQMO5RTwoQJnLedub02Wv/SA8789jlpxu/8eskeBDlEZ5LWgToWtvxJFnJMVTpcZ cK1pMjghEuuZC7Ybqs2FGrXhMzXE0Fj93z1s3uIfGYDpD01FLECTvLsCk7BnyBKcymVh oDnpbvW2L9AOz/I7djrdrwaafE7Y+KPgVk53157q3fIEWJ8KbNzJpWCbQU6WkCLj3tUH G1SU7UrHows9BukgyTpE8tG+BkG22MUD/AIZVCS8KZYm/3MYQlDxIUrcmd4nnwfMuIiP NqYg== 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=h7bHBsCo1S+Jc4SgFduPQ3fIFfuHtuALU5qy7jO0lRg=; b=uHKkgngSOeZQAvkIRSDWh5mRmiI/PqM8BRDEZOGCduFL2tFieDq7gaCILZ683m6KDo UbR+lzLB2HCEUnFWDp6v+o/Rg4/5LLrvyCo5ZnjchxN5SKtDpP2TgNo/DR7TzmY3mL13 u4cdGCH3rGKKsTDZNH9QFL96c04XAxYU5244AIgqHPGBBUmDw7cJczHx2SWr8eM1j8xy noYyC6KO6gZLudttNjC9g/iOcXf5Fr1DpEEugb/tc3CBSeEeFUKvbXYbhTqcVxU3A6la e+9dX7gWYFw9MvDPyWIEi7196dAb2miwy2DlWQNaxJPl/nDvM2yfGeiSsZNlzeG2jvLZ VpNA== 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=h7bHBsCo1S+Jc4SgFduPQ3fIFfuHtuALU5qy7jO0lRg=; b=Ey+lnjkySuUlBImWU9Oyti5cUG3Yl/g3JcVGvqBO3ukHIESmarv1kHQoPCtNJwndod tLk57MaimyoBnrYZBuIYwoebumJi1sGSWsA2/t2vwcDRE19t35LLDEaaiLX1eRcA8s6/ qFq8lRImgHjuJgT6rQ58MBiu635KeePAJE+h7cDHrRJwe1ETuvFcFzc94D7sWeRhuAGX e9ycfTNR6hhi6Z5ToPl2XhZoDQIpqSe1xPJYAL6yAXf9PliCxbcCIV8cW3pzIVmIASdo jiXVRUvNGYCmwNi1j+3/szak06O50H5vJJTDgIhx5MYYoIvV1yrDilUG7C+zcw5QSn1L nzvg== X-Gm-Message-State: AKwxyteJ/ApZA8phErkQAJhVuiOdV7ArhTglKcqN6xtOd6mAtLcJZsiU HcT0xBlVwmPIglRTLee5W0Ixkw== X-Google-Smtp-Source: ACJfBou1E2DmneOhTMwRhS6MNY9J90MUJtPE8uEe363KCrYa1Nt5sjZuQI7bOJBZGUga4injc9sGlA== X-Received: by 10.176.72.207 with SMTP id y15mr4719747uac.16.1516365055062; Fri, 19 Jan 2018 04:30:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.156.200 with SMTP id f191ls283859vke.16.gmail; Fri, 19 Jan 2018 04:30:53 -0800 (PST) X-Received: by 10.31.168.202 with SMTP id r193mr829458vke.4.1516365053226; Fri, 19 Jan 2018 04:30: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:36714 Archived-At: ------=_Part_5866_1096684638.1516365052739 Content-Type: multipart/alternative; boundary="----=_Part_5867_532900526.1516365052740" ------=_Part_5867_532900526.1516365052740 Content-Type: text/plain; charset="UTF-8" I just realized this could make *observer_ptr* finally useful. Once decorated it will *actually observe* the dtor/free of the original object is called and warn uses after that. Observation will be compile-time static analysis, active only in debug mode and/or a compiler flag. It will *not* work for heap allocated observers or observers members of heap allocated object and in case the original object is destroyed in a different thread. Still, it would be infinitely more useful then today, because it not only reinforces semantics, but *help us write correct code.* If someone writes correct code, then it should be opt-out (the attribute should be in a namespace 'debug' or 'analyze'). No need to pay the compile time price if your code is right. However verification should be "one click away" and targeted (no wide guess by the analyzer what "correct" is). Now lets consider something interesting. std::string str = "good"; std::string_view v = str; str += "or not"; // bad things waiting to happen That case is not solved neither by my original suggestion nor the life extension proposal! Both are concerned by the lifetime of the holding object and not what the object holds, however views are most of the time about internal representation, not the object itself (function_view is major exception). Views about the object themselves are pointers and references - we have them already. Interestingly this case is *trivially solved* by a the improved observer_ptr. class string_view { ... void friendly_func() { /*does not use _p*/ } std::observer_ptr _p; ... }; class string { operator string_view () const { return {c_str(), size()}; } }; Note, string does not need attribute decorations any more! Also note, now we can call view.friendly_func(), without a warning, even when the observed object is destroyed. (not sure how usefully this is, just an observation) Needless to say, the original example case *should* be now solved as after the addition the compiler/analyzer should detect that the original string must be relocated and observer_ptr will dangle. Interestingly - Is there something besides observer_ptr actually needed? Can we "just" define special behavior of observer_ptr (in debug/analyze mode) and solve all cases of lifetime monitoring (under the said limitations) - from smart pointers to function_view? -- 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/a395ffbf-fc53-4288-b1ca-f559e1703eac%40isocpp.org. ------=_Part_5867_532900526.1516365052740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just realized this could make observer_ptr f= inally useful.

Once decorated it will actually = observe the dtor/free of the original object is called and warn uses af= ter that.

Observation will be compile-time static= analysis, active only in debug mode and/or a compiler flag.
It = will not work for heap allocated observers or observers members of h= eap allocated object and in case the original object is destroyed in a diff= erent thread.=C2=A0

Still, it would be infinitely = more useful then today, because it not only reinforces semantics, but he= lp us write correct code.

If someone wr= ites correct code, t= hen it should be opt-out (the attribute should be in a namespace 'debug= ' or 'analyze'). No need to pay the compile time price if your = code is right.
However verification should be "one click aw= ay" and targeted (no wide guess by the analyzer what "correct&quo= t; is).


Now lets consider something= interesting.

std::string str =3D "good";
std::string_view v =3D str;

str +=3D = "or not";

=
// bad things waiting to happen

That case is not solved neither by my original suggestion= nor the life extension proposal!
Both are concerned by the lifetime of the holding object and not wh= at the object holds, however views are most of the time about internal repr= esentation, not the object itself (function_view is major exception).
Views about the object themselves are pointers and references -= we have them already.

Interestingly this case is = trivially solved by a the improved observer_ptr.

class string_view
{
=C2=A0 ...
=C2=A0 vo= id friendly_func() { /*does not use _p*/ }
=C2=A0 std::observer_ptr _p;
=C2=A0 ...
};

class string=C2=A0
{
=C2=A0 operator=C2=A0string_view () const = { return {c_str(), size()}; }
};

Note, string does not need attribute decorations any more!
Also note, now we can call vi= ew.friendly_func(),=C2=A0<= span style=3D"display: inline !important; float: none; background-color: tr= ansparent; color: rgb(34, 34, 34); font-family: arial,sans-serif; font-size= : 13px; font-style: normal; font-variant: normal; font-weight: 400; letter-= spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-= indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp= ace: normal; word-spacing: 0px;">without a warning, even when the observed object is destroyed. (not sure how u= sefully this is, just an observation)=C2=A0

Needless to say, the original example case should be now sol= ved as after the addition the compiler/analyzer should detect that the orig= inal string must be relocated and observer_ptr will dangle.

Interestingly - Is there something besides=C2=A0observer_ptr actuall= y needed?
Can w= e "just" define special = behavior of=C2=A0observe= r_ptr (in debug/analyze mode) and solve all cases of lifetime monitoring (u= nder the said limitations) - from smart pointers to function_view?



--
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/a395ffbf-fc53-4288-b1ca-f559e1703eac= %40isocpp.org.
------=_Part_5867_532900526.1516365052740-- ------=_Part_5866_1096684638.1516365052739-- .