220 8655 article Path: news.gmane.org!not-for-mail From: Peter Bigot Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Fri, 17 Jan 2014 15:24:19 -0600 Lines: 156 Approved: news@gmane.org Message-ID: References: <8045a4d2-721d-4725-8bb7-7a91b6f53ec8@isocpp.org> <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> <7aad44d8-6b4e-438a-b309-bd898b994b34@isocpp.org> <9C2C439F-7983-4224-B272-53CAD0E2E456@gmail.com> <3379bbae-dd54-461c-bf90-228e476ca7db@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b471e6a43b95b04f0312a0a X-Trace: ger.gmane.org 1389993855 22553 80.91.229.3 (17 Jan 2014 21:24:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jan 2014 21:24:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA3LUEAQACBBBF742LAKGQEDKZJUKI@isocpp.org Fri Jan 17 22:24:23 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4Gtp-0003Vb-Vh for gclcip-std-proposals@m.gmane.org; Fri, 17 Jan 2014 22:24:22 +0100 Original-Received: by mail-ie0-f198.google.com with SMTP id ar20sf4250575iec.9 for ; Fri, 17 Jan 2014 13:24:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=sDB3e6f03esxq/rEH7KuELSG3OGFkl46jKSDEDv/KHo=; b=GnCahaogX0zjirLytWMn5qk8pufZ19s1sgoqUmVTmrOSeSCzmIE29eHaz5isW8yF93 ZFXwloxZWHUNd1WQvWKTKdeUau72oyH2lkBZLi4rieBMb0/fn/w4VzjenASJYGRc27hz ze9QcPzt7I30cSeN4azso0iLSnQr1Zz+EOHAp4HI2PP1EDDbxv2pojWV37+EeOnLkrby mkAL3KPRIfeeGI/qnJFGFDbcWCoI1ZnAvYEMeooXVTABaE14ogjdWGqVuARtVCLckco+ xG2DVPdZQzF4VTFH86t0GAzM44ZY0LlYxP7h6jg8S3cXw7cZj0mcttPUvvLg2qzRU4BD 0+aA== X-Gm-Message-State: ALoCoQkifb0WuhGAOSCHpf9n9Vanz88cZg23sTPkkY9w5UYynv6u+TlY57oGG4Hg7RiIs5AqOBXl X-Received: by 10.42.110.198 with SMTP id r6mr1475571icp.33.1389993861120; Fri, 17 Jan 2014 13:24:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.16.145 with SMTP id 17ls524184qgb.58.gmail; Fri, 17 Jan 2014 13:24:20 -0800 (PST) X-Received: by 10.236.91.201 with SMTP id h49mr1909yhf.96.1389993860449; Fri, 17 Jan 2014 13:24:20 -0800 (PST) Original-Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [2607:f8b0:4003:c02::230]) by mx.google.com with ESMTPS id t28si13015932yhd.261.2014.01.17.13.24.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 13:24:20 -0800 (PST) Received-SPF: pass (google.com: domain of pabigot@gmail.com designates 2607:f8b0:4003:c02::230 as permitted sender) client-ip=2607:f8b0:4003:c02::230; Original-Received: by mail-oa0-f48.google.com with SMTP id l6so431790oag.7 for ; Fri, 17 Jan 2014 13:24:20 -0800 (PST) X-Received: by 10.60.134.230 with SMTP id pn6mr3457786oeb.40.1389993859986; Fri, 17 Jan 2014 13:24:19 -0800 (PST) Original-Sender: pabigot@gmail.com Original-Received: by 10.76.168.228 with HTTP; Fri, 17 Jan 2014 13:24:19 -0800 (PST) In-Reply-To: X-Original-Sender: bigotp@acm.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of pabigot@gmail.com designates 2607:f8b0:4003:c02::230 as permitted sender) smtp.mail=pabigot@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:8655 Archived-At: --047d7b471e6a43b95b04f0312a0a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 17, 2014 at 1:58 PM, Nevin Liber wrote: > On 17 January 2014 12:34, Peter Bigot wrote: > >> >> While the half-open range argument is true in isolation, it's missing the >> point that the value of data() is well-known based on how the string_view >> was created and what operations have been performed on it. >> > > How does the callee know how the string_view was created? If the callee > has more preconditions than those enforced by string_view, you might be > better off using a separate type. If the callee "knows" how it was > created, why use a string_view at all? > I don't understand this argument. Where does a callee enter the picture? Both Marshall's example and mine are self-contained: we can see how the instances were created, we have N3762 which specifies what data() means throughout the operations that were invoked, and from that we know that data() points within a range that is still valid in the "caller" context where it's used. > Based on how sv2 is constructed in that example, I believe it's guaranteed >> that deref(sv2) will return the '\0' that terminates the string literal >> used to initialize sv2, and that doing so does not invoke undefined >> behavior. >> > > What compilers are allowed to assume from the specification of the > standard library is an interesting question... :-) > > Take for example: > > std::vector v(1); > auto p1 = v.data(); > v.pop_back(); > > Can I legally do a placement new of a std::string into the space pointed > to by p1? Beats me. > I'd guess that'd depend in part on whether pop_back() might invalidate data(), which I'm not motivated to research. For string_view I think it's a lot simpler: When a string_view is first created, it references a valid range [data(), data()+size()) that itself is within an external object that the string_view references. I'm unaware of any legal string_view operation (except clear()) that can move data() outside that initially valid range: every mutating operation leaves the string_view instance's range unchanged or reduces it within existing bounds. The validity of the original range derives from an object other than the string view, so as long as that range is not invalidated (which in turn I think would necessarily involve a data race), it should be possible to continue use the pointers that lie within it, right? Peter -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7b471e6a43b95b04f0312a0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 17, 2014 at 1:58 PM, Nevin Liber <nevin@eviloverlord.com&= gt; wrote:
On 17 Jan= uary 2014 12:34, Peter Bigot <bigotp@acm.org> wrote:

While the half-open range argument is true in iso= lation, it's missing the point that the value of data() is well-known b= ased on how the string_view was created and what operations have been perfo= rmed on it.

How does the callee know how t= he string_view was created?=A0 If the callee has more preconditions than th= ose enforced by string_view, you might be better off using a separate type.= =A0 If the callee "knows" how it was created, why use a string_vi= ew at all?

I don't unders= tand this argument.=A0 Where does a callee enter the picture?=A0 Both Marsh= all's example and mine are self-contained: we can see how the instances= were created, we have N3762 which specifies what data() means throughout t= he operations that were invoked, and from that we know that data() points w= ithin a range that is still valid in the "caller" context where i= t's used.
=A0
Based on how sv2 is constructed in that example, I b= elieve it's guaranteed that deref(sv2) will return the '\0' tha= t terminates the string literal used to initialize sv2, and that doing so d= oes not invoke undefined behavior.=A0

What compilers are allowed to = assume from the specification of the standard library is an interesting que= stion... :-)

Take for example:

std::vec= tor<std::string> v(1);
auto p1 =3D v.data();
v.pop_back();

<= div>Can I legally do a placement new of a std::string into the space pointe= d to by p1?=A0 Beats me.

I'd guess that'd depend in part on whether pop_back() might in= validate data(), which I'm not motivated to research.=A0 For string_vie= w I think it's a lot simpler:

When a string_view is first create= d, it references a valid range [data(), data()+size()) that itself is withi= n an external object that the string_view references.=A0 I'm unaware of= any legal string_view operation (except clear()) that can move data() outs= ide that initially valid range: every mutating operation leaves the string_= view instance's range unchanged or reduces it within existing bounds.= =A0 The validity of the original range derives from an object other than th= e string view, so as long as that range is not invalidated (which in turn I= think would necessarily involve a data race), it should be possible to con= tinue use the pointers that lie within it, right?

Peter

--
 
---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7b471e6a43b95b04f0312a0a-- .