220 8663 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 14:43:09 -0800 (PST) Lines: 164 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> <8E74B747-7450-41E0-8D1E-48C2D6F81535@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_119_20714774.1389998589706" X-Trace: ger.gmane.org 1389998587 9667 80.91.229.3 (17 Jan 2014 22:43:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jan 2014 22:43:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA3LUEAQACBB7XD42LAKGQEUB6SNSY@isocpp.org Fri Jan 17 23:43:15 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4I88-0006x1-VZ for gclcip-std-proposals@m.gmane.org; Fri, 17 Jan 2014 23:43:13 +0100 Original-Received: by mail-pa0-f69.google.com with SMTP id fa1sf5876189pad.4 for ; Fri, 17 Jan 2014 14:43:11 -0800 (PST) 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=TY5IhCgGfLtnEDRmKq2fZX3vM2TABjKxfP6znVpRfig=; b=XYLdVHgdXJzUZjtzS8FJbldhNrH1K4HdwC/nj9NSm6ExvJiNVb4mFqynf00oJOvll/ pNvHRW4WZGOKWTwJxkFKkt53rmVQT7+hxgcuClgd57zrQV0AkZGCD89Qsw6L7/VVozHn 2uKjM4+uumIvD+0qGqFmb611Q1QC91Ar8I6F1Y985VRg/Jm+fiuc+ypndsdVR4XGJVUR 0CbSNmOervyb94Kh9yiutR8AEQ9zJdh4byQOYj4KeYkaF4tQfCsVLHEhLTRpiRCkiSxE z6tXXpAkRJlOQbRhIJS50nDkbI8mGng1Rfi+yWLBdBJ0wKROuFWpJEkTampr58tTZlmX b2Vw== X-Gm-Message-State: ALoCoQloht/LCrTZItoqP7gD6MwnTIrGLT+/82gdTIUgo6hQMr9W6lpTsk58C5/ZMMHVu6qe66eK X-Received: by 10.66.146.65 with SMTP id ta1mr1776455pab.19.1389998591675; Fri, 17 Jan 2014 14:43:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.245.19 with SMTP id xk19ls580571obc.17.gmail; Fri, 17 Jan 2014 14:43:10 -0800 (PST) X-Received: by 10.182.158.196 with SMTP id ww4mr44174obb.5.1389998590315; Fri, 17 Jan 2014 14:43:10 -0800 (PST) In-Reply-To: <8E74B747-7450-41E0-8D1E-48C2D6F81535@gmail.com> X-Original-Sender: bigotp@acm.org 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:8663 Archived-At: ------=_Part_119_20714774.1389998589706 Content-Type: text/plain; charset=UTF-8 On Friday, January 17, 2014 3:55:41 PM UTC-6, Marshall wrote: > > > On Jan 17, 2014, at 1:25 PM, Peter Bigot > > wrote: > > On Fri, Jan 17, 2014 at 2:22 PM, Jeffrey Yasskin > > wrote: > >> On Fri, Jan 17, 2014 at 12:18 PM, Nevin Liber > >> wrote: >> > On 17 January 2014 14:11, Jeffrey Yasskin > >> wrote: >> >> >> >> If it is, I intend to also >> >> remove the precondition on the string_view(data, size) to let people >> >> explicitly put nullptr in. >> > >> > >> > I'd like to, mainly because it makes it easy to create a string_view >> from a >> > vector by using v.data() and v.size(). Having to special case a >> check >> > for nullptr (such as in string::string(const char*, size_t)) for what is >> > otherwise a perfectly valid 0-sized range is just annoying. >> > >> Ah, vector.data() doesn't guarantee non-null results. :( That's a good >> argument. >> > > First, is that true? [data(), data()+size()) must be a valid range, but > I've been unable to find a definition of "valid range" in the standard so I > could understand whether an empty valid range permits its base to be a null > pointer. > > Second, even if so std::string.data() does guarantee a non-null result, > doesn't it? In that case it's also required that data()+i == > &operator[](i) for i in [0, size()] which led me to believe data() could > not be null, since the equality must hold for i==0 and operator[] must > return a reference to an object (hence the underlying pointer cannot be > null). > > > I think you mean, [0,i), not [0,i] > > No, I mean i in [0,size()] which in this case is [0,0]. 21.4.7.1 paragraph 1. I've been swayed by the argument that there's no such thing as a null > std::string, so there should be no such thing as a null std::string_view. > This is easily assured by disallowing std::string_view(s, n) for a null s > just as std::string(s, n) is disallowed for null s. > > > The difference here is that string manages its own storage, while > string_view does not. > As others have confirmed, std::string still doesn't permit a null pointer for data(), so this isn't compelling to me. 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/. ------=_Part_119_20714774.1389998589706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, January 17, 2014 3:55:41 PM UTC-6, Mars= hall wrote:

On Jan 17, 2014, at 1:25 PM, Peter Bigot <= ;big...@acm.org> wrote:
On= Fri, Jan 17, 2014 at 2:22 PM, Jeffrey Yasskin <jyas...@google.com> wrote:
On Fri, Jan 17, 2014 at 12:18 PM, Nevin= Liber <ne...@eviloverlord.com= > wrote:
> On 17 January 2014 14:11, Jeffrey Yasskin <jyas...@google.com> wrote:
>>
>> If it is, I intend to also
>> remove the precondition on the string_view(data, size) to let peop= le
>> explicitly put nullptr in.
>
>
> I'd like to, mainly because it makes it easy to create a string_view f= rom a
> vector<char> by using v.data() and v.size().  Having to spe= cial case a check
> for nullptr (such as in string::string(const char*, size_t)) for what = is
> otherwise a perfectly valid 0-sized range is just annoying.
<= /blockquote>

Ah, vector.data() doesn't guarantee non-null results. :( That's a goo= d argument.

First, is that true?  = [data(), data()+size()) must be a valid range, but I've been unable to find= a definition of "valid range" in the standard so I could understand whethe= r an empty valid range permits its base to be a null pointer.

Second, even if so std::string.data() does guara= ntee a non-null result, doesn't it?  In that case it's also required t= hat data()+i =3D=3D &operator[](i) for i in [0, size()] which led me to= believe data() could not be null, since the equality must hold for i=3D=3D= 0 and operator[] must return a reference to an object (hence the underlying= pointer cannot be null).

I thin= k you mean, [0,i), not [0,i]

No, I mean i in [0,size()] which in this case is [0,0].  21.4.7.1 pa= ragraph 1.

I've been swayed by the argument that there's no such th= ing as a null std::string, so there should be no such thing as a null std::= string_view.  This is easily assured by disallowing std::string_view(s= , n) for a null s just as std::string(s, n) is disallowed for null s.

The difference here is that string ma= nages its own storage, while string_view does not.
=

As others have confirmed, std::string still doesn't permit a null = pointer for data(), so this isn't compelling to me.

Peter
<= /div>

--
 
---
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_119_20714774.1389998589706-- .