220 8657 <6489D5D6-37BC-4C44-B591-1B931BA723BF@gmail.com> article Path: news.gmane.org!not-for-mail From: Marshall Clow Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Fri, 17 Jan 2014 13:48:25 -0800 Lines: 156 Approved: news@gmane.org Message-ID: <6489D5D6-37BC-4C44-B591-1B931BA723BF@gmail.com> 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 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_392DBC53-EBD0-4E78-A8AA-0F4E5B1CDE0B" X-Trace: ger.gmane.org 1389995306 6144 80.91.229.3 (17 Jan 2014 21:48:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jan 2014 21:48:26 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDHIXP53REBRBLWK42LAKGQEGRVBTYQ@isocpp.org Fri Jan 17 22:48:32 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4HHE-0002fl-0w for gclcip-std-proposals@m.gmane.org; Fri, 17 Jan 2014 22:48:32 +0100 Original-Received: by mail-ie0-f197.google.com with SMTP id e14sf17864966iej.0 for ; Fri, 17 Jan 2014 13:48:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-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=n1qnINJssnRfmFvMT4XvpKjUVliMuM1lHV6ObMk2FE0=; b=PbT9sASelBccs4nik+hn0QA2FqjxpD0EkhcP44QM/MVDPULSRi+Sjvw3lDRuZlIEvV GlvUw+9dJPnS1vSpuvlbRgUD3qVOR3vYZlEiDpDWhYRovL8xlOog86Y2WgBvKXiPBPgn SpLaMk73xt+MH5Nph2Eq7xCNpfdTMPE4mlnXbKQsGXP+XJ4Pvlfhg7m0hFUDFeZp+uuT V+F/MZD5wFH6cxZbacAs9jmXvum6Vm2xlAGa/kxUYeuvGSC/xXGXJtR70d8oXDMKFSCg Hw8Yoj3dx6eJQFEXG4Qd3h25P0wakj3fUTV1LTbmuI4dTGK1rns/fX7FT/JTgfPugEMp eq2g== X-Gm-Message-State: ALoCoQnsdD4ndduvf0AMQWhY44lvY3mjI/F62lrkmBySan1YDqGP8M5Vq40lFfqENllpAprrnF5g X-Received: by 10.42.44.200 with SMTP id c8mr1427876icf.21.1389995310837; Fri, 17 Jan 2014 13:48:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.60.37 with SMTP id e5ls1201823qer.84.gmail; Fri, 17 Jan 2014 13:48:30 -0800 (PST) X-Received: by 10.224.65.135 with SMTP id j7mr7621141qai.10.1389995310295; Fri, 17 Jan 2014 13:48:30 -0800 (PST) Original-Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [2607:f8b0:400e:c03::232]) by mx.google.com with ESMTPS id v8si5284092qed.134.2014.01.17.13.48.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 13:48:29 -0800 (PST) Received-SPF: pass (google.com: domain of mclow.lists@gmail.com designates 2607:f8b0:400e:c03::232 as permitted sender) client-ip=2607:f8b0:400e:c03::232; Original-Received: by mail-pa0-f50.google.com with SMTP id kp14so4625206pab.23 for ; Fri, 17 Jan 2014 13:48:28 -0800 (PST) X-Received: by 10.66.240.4 with SMTP id vw4mr4746223pac.26.1389995308284; Fri, 17 Jan 2014 13:48:28 -0800 (PST) Original-Received: from [192.168.16.50] (wsip-174-77-164-131.sd.sd.cox.net. [174.77.164.131]) by mx.google.com with ESMTPSA id x5sm25263206pbw.26.2014.01.17.13.48.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 13:48:27 -0800 (PST) In-Reply-To: <3379bbae-dd54-461c-bf90-228e476ca7db@isocpp.org> X-Mailer: Apple Mail (2.1827) X-Original-Sender: mclow.lists@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mclow.lists@gmail.com designates 2607:f8b0:400e:c03::232 as permitted sender) smtp.mail=mclow.lists@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:8657 Archived-At: --Apple-Mail=_392DBC53-EBD0-4E78-A8AA-0F4E5B1CDE0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 17, 2014, at 10:34 AM, Peter Bigot wrote: >=20 >=20 > On Friday, January 17, 2014 10:26:50 AM UTC-6, Marshall wrote: > On Jan 15, 2014, at 4:28 AM, Olaf van der Spek wrote= : >=20 >> On Saturday, December 28, 2013 6:01:34 AM UTC+1, Marshall wrote: >> if sv.size () =3D=3D 0 or sv.empty () [same thing], there is nothing tha= t you can do with sv.data() >> (except compare it to null, and that doesn=92t tell you anything useful)= .. >>=20 >> Are you sure? >> IMO an empty string_view could still point into a string and I should be= able to use that pointer to for example construct a new string_view. >=20 >=20 > A string view references a half-open contiguous range of characters; [ da= ta(), data()+size()) >=20 > if size() =3D=3D 0, then the range of characters referenced by the string= view is empty, and accessing them (either via dereferencing begin() or dat= a()) is (or should be) undefined behavior. (the same as any other container= ) >=20 > If in your program, you =93know=94 that the pointer returned by data() po= ints to something valid, well, that=92s on you to determine. >=20 > Code example: >=20 > char deref ( string_view sv ) { return *sv.data(); } >=20 > string_view sv1; > string_view sv2 { =93ABCDE=94 }; > sv2.remove_prefix(5); > assert ( sv1 =3D=3D sv2 ); > deref ( sv1 ); // may or may not blow up in your face > deref ( sv2 ); // this will probably =93work=94 ; but I don=92t know wha= t it will return. >=20 > =97 Marshall >=20 >=20 > 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. Adjusting the st= ring_view to the point where size() is zero does not invalidate data(). Peter =97 I think you=92re trying to add additional meaning to string_view.=20 It=92s a reference to a sequence of characters. When the size =3D=3D 0, then it=92s a reference to NO characters.=20 Saying =93all, yes, but we *know* what it points to, and so, really, it ref= ers to a character=94 is widening the definition of string_view. Unnecessarily so, in my belief. =97 Marshall --=20 ---=20 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 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-proposa= ls/. --Apple-Mail=_392DBC53-EBD0-4E78-A8AA-0F4E5B1CDE0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jan 1= 7, 2014, at 10:34 AM, Peter Bigot <big= otp@acm.org> wrote:



= On Friday, January 17, 2014 10:26:50 AM UTC-6, Marshall wrote:
On Jan 15, 2014, at 4= :28 AM, Olaf van der Spek <olafv...@gmail.com> wrote:

On Saturday, December 28, 2013 6:01:34 AM UTC+= 1, Marshall wrote:
if sv.size () =3D=3D 0 or sv.empty () [same thing], there is= nothing that you can do with sv.data()
(except compare it to nul= l, and that doesn=92t tell you anything useful).

Are you sure?
IMO an empty string_view could st= ill point into a string and I should be able to use that pointer to for exa= mple construct a new string_view.

A string view references a half-open contiguous range of character= s; [ data(), data()+size())

if size() =3D=3D 0, th= en the range of characters referenced by the string view is empty, and acce= ssing them (either via dereferencing begin() or data()) is (or should be) u= ndefined behavior. (the same as any other container)

If in your program, you =93know=94 that the pointer returned by data() p= oints to something valid, well, that=92s on you to determine.
Code example:

char deref ( string_view sv ) { return *sv.data(); }

string_view = sv1;
string_view sv2 { = =93ABCDE=94 };
sv2.remo= ve_prefix(5);
assert ( = sv1 =3D=3D sv2 );
deref= ( sv1 ); // may or may not blow u= p in your face
deref ( = sv2 ); // this will probably =93wo= rk=94 ; but I don=92t know what it will return.

= =97 Marshall


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. Adjusting the string_view to the= point where size() is zero does not invalidate data().

Peter =97

I think you=92= re trying to add additional meaning to string_view. 
It=92s = a reference to a sequence of characters.
When the size =3D=3D 0, = then it=92s a reference to NO characters. 

Sa= ying =93all, yes, but we *know* what it points to, and so, really, it refer= s to a character=94 is widening the definition of string_view.
Un= necessarily so, in my belief.

=97 Marshall

--
 
---
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>.
--Apple-Mail=_392DBC53-EBD0-4E78-A8AA-0F4E5B1CDE0B-- .