220 8283 <4E250ADA-5977-4F29-94B4-24D9F3E63EC2@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: Sun, 29 Dec 2013 09:35:17 -0800 Lines: 145 Approved: news@gmane.org Message-ID: <4E250ADA-5977-4F29-94B4-24D9F3E63EC2@gmail.com> References: <8045a4d2-721d-4725-8bb7-7a91b6f53ec8@isocpp.org> <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> 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=_4AC57258-D88D-4E30-A372-36F025A63F0F" X-Trace: ger.gmane.org 1388338635 31933 80.91.229.3 (29 Dec 2013 17:37:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Dec 2013 17:37:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDHIXP53REBRBTN3QGLAKGQEAG7VZTQ@isocpp.org Sun Dec 29 18:37:20 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VxKIh-0002lH-F0 for gclcip-std-proposals@m.gmane.org; Sun, 29 Dec 2013 18:37:19 +0100 Original-Received: by mail-ob0-f197.google.com with SMTP id vb8sf51247622obc.4 for ; Sun, 29 Dec 2013 09:37:18 -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=ead9EJpidXkBJokD3hrrK2SNASURR7PQc+3TW4w1W2g=; b=fLsrp2K0gzSJf8EtHIN+sVjW4c99KkZ2aKgePsSdY8SGvefNCjmm4arOlD/v+kKYBq puD4eS7c7P+d8ET/j0g4on5eaXzMDW2OsOFh7H1d9mlJWC8w5bN++3NiYRsDbTInuawp NBMxiMEnJSwo6KR5igIAbcT/xkqg8R7yaFsXH5gt1cPrlnu36W+QhYJAncZIIE0sPEyI pymah9lofXo46fGPXGfykPaWl0IAZzYYE0kQv8yvWSaH0bsu4Rt88yLx8+YciIxyl9IB JLmkXi2z2Uy0UAqIz8yc/qYu/T7Gnq3rlqDUj4f9TsfDqqDms7VqKlsv3NDCD8+NNskU F+fg== X-Gm-Message-State: ALoCoQlvazER5pLUo8WszxJDNCDGA+K9R9vVQCx/b6OInHj35MCpLZiZC3XS6PlzY+r71In85DVE X-Received: by 10.50.79.201 with SMTP id l9mr25207277igx.4.1388338638347; Sun, 29 Dec 2013 09:37:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.81.229 with SMTP id d5ls3212521qey.64.gmail; Sun, 29 Dec 2013 09:37:17 -0800 (PST) X-Received: by 10.49.81.178 with SMTP id b18mr103912807qey.0.1388338637813; Sun, 29 Dec 2013 09:37:17 -0800 (PST) Original-Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [2607:f8b0:400e:c01::230]) by mx.google.com with ESMTPS id r6si38553083qaj.127.2013.12.29.09.37.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Dec 2013 09:37:17 -0800 (PST) Received-SPF: pass (google.com: domain of mclow.lists@gmail.com designates 2607:f8b0:400e:c01::230 as permitted sender) client-ip=2607:f8b0:400e:c01::230; Original-Received: by mail-pb0-f48.google.com with SMTP id md12so10814383pbc.21 for ; Sun, 29 Dec 2013 09:37:16 -0800 (PST) X-Received: by 10.66.162.167 with SMTP id yb7mr64678666pab.16.1388338636855; Sun, 29 Dec 2013 09:37:16 -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 os1sm14443632pac.20.2013.12.29.09.37.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Dec 2013 09:37:16 -0800 (PST) In-Reply-To: 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:c01::230 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:8283 Archived-At: --Apple-Mail=_4AC57258-D88D-4E30-A372-36F025A63F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 28, 2013, at 11:21 AM, Peter Bigot wrote: >=20 > On Friday, December 27, 2013 11:01:34 PM UTC-6, Marshall wrote: > On Dec 27, 2013, at 4:52 AM, abolz...@gmail.com wrote: >=20 >> Is there a reason why string_view is not nullable? >>=20 >> Nullable here means default constructed or constructed from a nullptr >> (and a zero length). Then adding a is_null() (or null()) member >> function which can then be used to distinguish the string_view from an >> empty string. >=20 > i think that attempting to distinguish between an empty string_view that = =93used to point at something=94 > and an empty string view =93that never pointed at anything=94 is a use ca= se to be discouraged, rather than > something that should be enshrined in the standard. >=20 > -1 ; I think it's an obvious and valuable feature. >=20 >> This should not affect data() which returns a non-null pointer. >>=20 >=20 > I disagree here with the proposal as currently written. > I believe that the requirement that data() always return a non-null point= er is misguided. >=20 > 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 null, and that doesn=92t tell you anything useful). >=20 > My understanding (which I'd like confirmed) is that sv.data() is still us= eful as it provides a valid position within the referenced object, which mi= ght be referenced by other string_view instances or in its native form. a string view refers to a half open range (just like an iterator pair). sv.data() a pointer to the beginning of that range, just like sv.begin() is= an iterator to the beginning of that range. If sv.size() =3D=3D 0, then dereferencing sv.data() or sv.begin() is undefi= ned behavior. Also, I can=92t find anywhere in the specification does it guarantee that t= he following code works: const char *foo =3D =93abc=94; string_view sv1 ( foo, 3 ); // size() =3D=3D 3 sv1. remove_suffix (3); // size() =3D=3D 0 assert ( sv1.size() =3D=3D 0);=09 assert ( sv1.data() =3D=3D foo ); // will probably work - but might not. =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=_4AC57258-D88D-4E30-A372-36F025A63F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 2= 8, 2013, at 11:21 AM, Peter Bigot <big= otp@acm.org> wrote:


On Friday, December 27, 2013 11= :01:34 PM UTC-6, Marshall wrote:
On Dec 27, 2013, at 4:52 AM, abolz...@gmail.com wrote:

Is there a reason why string_vi= ew is not nullable?

Nullable here means default constructed or= constructed from a nullptr
(and a zero length). Then adding a is= _null() (or null()) member
function which can then be used to dis= tinguish the string_view from an
empty string.

i think that attempting to distinguish between an empt= y string_view that =93used to point at something=94
and an empty = string view =93that never pointed at anything=94 is a use case to be discou= raged, rather than
something that should be enshrined in the stan= dard.

-1 ; I think it's an obvious and val= uable feature.

This should not affect data() which returns a non-null= pointer.

I disagree here with the proposa= l as currently written.
I believe that the requirement that = data() always return a non-null pointer is misguided.

<= /div>
if sv.size () =3D=3D 0 or sv.empty () [same thing], there is noth= ing that you can do with sv.data()
(except compare it to null, an= d that doesn=92t tell you anything useful).
My understanding (which I'd like confirmed) is that sv.data() is still us= eful as it provides a valid position within the referenced object, which mi= ght be referenced by other string_view instances or in its native form.
=

a string view refers to a hal= f open range (just like an iterator pair).
sv.data() a pointer to the b= eginning of that range, just like sv.begin() is an iterator to the beginnin= g of that range.

If sv.size() =3D=3D 0, then deref= erencing sv.data() or sv.begin() is undefined behavior.

Also, I can=92t find anywhere in the specification does it guarantee = that the following code works:

const char *foo =3D =93abc=94= ;
string_view sv1 ( foo, 3 ); // size() =3D=3D 3
sv1. remove_suffix (3); // size() =3D=3D 0<= /div>
= assert ( sv1.size() =3D=3D 0);
assert ( sv1.data() =3D=3D foo ); // will probably work - but mig= ht not.

=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=_4AC57258-D88D-4E30-A372-36F025A63F0F-- .