220 8285 <7c9130ef-9e06-4d78-864a-570fbc68c8bf@isocpp.org> article Path: news.gmane.org!not-for-mail From: abolz.lists@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Sun, 29 Dec 2013 11:15:07 -0800 (PST) Lines: 252 Approved: news@gmane.org Message-ID: <7c9130ef-9e06-4d78-864a-570fbc68c8bf@isocpp.org> References: <8045a4d2-721d-4725-8bb7-7a91b6f53ec8@isocpp.org> <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> <4E250ADA-5977-4F29-94B4-24D9F3E63EC2@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5037_20131352.1388344507283" X-Trace: ger.gmane.org 1388344503 24167 80.91.229.3 (29 Dec 2013 19:15:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Dec 2013 19:15:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCAJPLFFWYPBBPHJQGLAKGQEJ7R3RRA@isocpp.org Sun Dec 29 20:15:10 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f69.google.com ([209.85.216.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VxLpN-0000ED-LI for gclcip-std-proposals@m.gmane.org; Sun, 29 Dec 2013 20:15:09 +0100 Original-Received: by mail-qa0-f69.google.com with SMTP id ii20sf14083955qab.0 for ; Sun, 29 Dec 2013 11:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=YDGVbzWPfvmp2EQUnFeNi7Mps9+txikPHLVa3Rm3Usw=; b=Et3bKLDoRpWocNpKPNY834hNvMxI3LIOBP8XT37nAFtGR5AGbRmHTwbJmRL0LF/jY/ qq9kraaTH4TDsV5abfVeWIaVAkTiJfyT2bBF4KRReZU3WUeYx/TkT7A+578KgnOgjfAQ 6Vg6Mth3GFkra8FJ/ri+ahZcchRDej3JngTM5Unjg13VuYjjyMw3zcKwilxcc/Gdzqzb YDN013IbmDjVWchekojDNZRaEuKORgOG8mQOav/u3+odAhAR7u4jZ+qI+2trem9OSfr4 lzJYwdQ76aVMhxyngoP8WjM+9LIQ8qEnHEwnl4gAF/vLCNhjavFBzDMOf35zRlng9hs/ ypIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=YDGVbzWPfvmp2EQUnFeNi7Mps9+txikPHLVa3Rm3Usw=; b=X58LN+/2NyTj7BUj2mzmwJgMWqhTDTSe8M7rn0z0hM7cktLKJaz/JSJx8r2mpx9Z3g +wThpURJDyz+KlRGROACDQCJ5AUfAWZWO/Wfm4CkDVQPBsWErugSLwWICBUiCE/wP/06 Wg2SEfqttPwVCOW/57MeB4BQnaTO9S+l1xtvzAgvKl56tsXGWSbI/xuL/XUt6QRnZdFF aKiKkmOl/5GwalM/f8RbNJk5UhMWq7htBruwoSZkWU4T219Ue/bXVt8/vfN1c6dJRYTK gzMr3g6AxTXoDvZh4p13ohZHs/pO0uOVDODMh2uDR8MrUtAh0L8ir2Ix7Xct25/UfsCg 59Tw== X-Gm-Message-State: ALoCoQmmGmCJfWEhY11RPae735IGec+iWZeEiyDvJCgmdDEGtymKsIc/MVtGpdZ16LCwaeLDlHkc X-Received: by 10.58.39.202 with SMTP id r10mr26070491vek.12.1388344508637; Sun, 29 Dec 2013 11:15:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.15.70 with SMTP id v6ls3536002qec.47.gmail; Sun, 29 Dec 2013 11:15:07 -0800 (PST) X-Received: by 10.49.12.109 with SMTP id x13mr53375qeb.12.1388344507897; Sun, 29 Dec 2013 11:15:07 -0800 (PST) In-Reply-To: X-Original-Sender: abolzlists@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:8285 Archived-At: ------=_Part_5037_20131352.1388344507283 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Am Sonntag, 29. Dezember 2013 19:15:50 UTC+1 schrieb Peter Bigot: > On Sun, Dec 29, 2013 at 11:35 AM, Marshall Clow > > wrote: > >> >> On Dec 28, 2013, at 11:21 AM, Peter Bigot >= =20 >> 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: >>> >> This should not affect data() which returns a non-null pointer. >>> >>> I disagree here with the proposal as currently written. >>> I believe that the requirement that data() always return a non-null=20 >>> pointer is misguided. >>> >>> if sv.size () =3D=3D 0 or sv.empty () [same thing], there is nothing th= at=20 >>> you can do with sv.data() >>> (except compare it to null, and that doesn=92t tell you anything useful= ). >>> >> >> My understanding (which I'd like confirmed) is that sv.data() is still= =20 >> useful as it provides a valid position within the referenced object, whi= ch=20 >> might 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()= =20 >> is an iterator to the beginning of that range. >> > > Agreed. > =20 > >> >> If sv.size() =3D=3D 0, then dereferencing sv.data() or sv.begin() is=20 >> undefined behavior. >> > > Agreed. > > Also, per [string.view.access] the requirements disallow expression sv[0]= =20 > in this case (unlike str[0] if str is a std::string, where the expression= =20 > is permitted but the referenced object may not be modified). A subtlety= =20 > worth keeping in mind (libstdc++ missed that one). > =20 > >> >> Also, I can=92t find anywhere in the specification does it guarantee tha= t=20 >> the following code works: >> >> const char *foo =3D =93abc=94; >> string_view sv1 ( foo, 3 ); // size() =3D=3D 3 >> > > The definition of the constructor in section x.1 [string.view.cons]=20 > guarantees sv1.data() =3D=3D foo. > =20 > >> sv1. remove_suffix (3); // size() =3D=3D 0 >> > > Per [string.view.modifiers] this is equivalent to sv1 =3D sv1.substr(0,= =20 > sv1.size() - 3). > > Per [string.view.ops] the definition of substr makes the RHS equivalent t= o=20 > string_view(sv1.data() + 0, sv1.size() - 3). > > Same constructor as above, so if that temporary object is tv, tv.data() = =3D=3D=20 > sv1.data()+0 =3D=3D foo+0 =3D=3D foo. > > =20 > >> assert ( sv1.size() =3D=3D 0);=20 >> assert ( sv1.data() =3D=3D foo ); // will probably work - but might not= .. >> > > AFAICT this must be true. > > If my reasoning is wrong, string_view becomes significantly less valuable= =20 > to me, so do please point out my error. > Yes. When used as a replacement for "string const&" one should already test for non-null pointers, I think. The precondition for the constructors just make= s it impossible to use string_view as a pair (char const*, length). =20 > > FWIW my first reading of N3593 was probably correct and zero-length=20 > string_view values returned from a delimiter find() may point into the= =20 > middle of an input range; they only indicate "not found" when the data()= =20 > member references the end position of the input. > =20 > Peter > --=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/. ------=_Part_5037_20131352.1388344507283 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Am Sonntag, 29. Dezember 2013 19:15:50 UTC+1 schrieb Peter= Bigot:
On Sun, Dec 29, 2013 at 11:35 AM, Marshall Cl= ow <mclow...@gmai= l.com> wrote:
On Dec 28, 2013, at 11:21 AM, Peter Bigot <big...@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:

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

I disagree here with the propo= sal as currently written.
I believe that the requirement that data() always return a non-nu= ll pointer is misguided.

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 usefu= l).

My understanding (which I'd like confi= rmed) is that sv.data() is still useful as it provides a valid position wit= hin the referenced object, which might be referenced by other string_view i= nstances 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 be= ginning of that range.

Agreed.
 

If sv.size() =3D=3D 0, then dereferencing sv.data() or sv.begin() is und= efined behavior.

Agreed.

Also, per [string.vie= w.access] the requirements disallow expression sv[0] in this case (unlike s= tr[0] if str is a std::string, where the expression is permitted but the re= ferenced object may not be modified).  A subtlety worth keeping in min= d (libstdc++ missed that one).
 

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

const char= *foo =3D =93abc=94;
string_view sv1 ( foo, 3 ); //= size() =3D=3D 3

The definition of the constructor in= section x.1 [string.view.cons] guarantees sv1.data() =3D=3D foo.
 =
sv1. remove_suffix (3); // size() =3D=3D 0

Per= [string.view.modifiers] this is equivalent to sv1 =3D sv1.substr(0, sv1.si= ze() - 3).

Per [string.view.ops] the definition of substr makes the RHS equivalent= to string_view(sv1.data() + 0, sv1.size() - 3).

Same constructor as= above, so if that temporary object is tv, tv.data() =3D=3D sv1.data()+0 = =3D=3D foo+0 =3D=3D foo.

 
assert ( sv1.size() =3D=3D 0);
assert ( sv1.data() =3D= =3D foo ); // will probably wor= k - but might not.

AFAICT this = must be true.

If my reasoning is wrong, string_view becomes significantly = less valuable to me, so do please point out my error.
=

Yes.
When used as a r= eplacement for "string const&" one should already test for
no= n-null pointers, I think. The precondition for the constructors just makes<= /div>
it impossible to use string_view as a pair (char const*, length).=
 
<= div dir=3D"ltr">

<= div>FWIW my first reading of N3593 was probably correct and zero-length str= ing_view values returned from a delimiter find()  may point into the m= iddle of an input range; they only indicate "not found" when the data() mem= ber references the end position of the input.
 
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>.
------=_Part_5037_20131352.1388344507283-- .