220 8682 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: Sat, 18 Jan 2014 07:36:17 -0800 (PST) Lines: 254 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> <104254A6-C69A-4571-8455-89D7E466D493@gmail.com> <6a95bf9c-55c9-4ae2-966f-d1b1f4df6a37@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_422_23998461.1390059377973" X-Trace: ger.gmane.org 1390059375 786 80.91.229.3 (18 Jan 2014 15:36:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jan 2014 15:36:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCAJPLFFWYPBB4V65KLAKGQED3GLT3I@isocpp.org Sat Jan 18 16:36:21 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f198.google.com ([209.85.192.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4Xwa-0001uR-MO for gclcip-std-proposals@m.gmane.org; Sat, 18 Jan 2014 16:36:21 +0100 Original-Received: by mail-pd0-f198.google.com with SMTP id v10sf2508563pde.1 for ; Sat, 18 Jan 2014 07:36:19 -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=2ELuvUBqjH211GemXhXl0U7UrbeEzwGHi2aD0VN8/4s=; b=bCkrBNuQ5rbJUDQQvEaNKmdfP4lGhoyWrlSIITXxI/suErrhPyro5O5XQnqGfYC6he upMHZZU0UiVIrpAjPTmIMFkkHTTV47qLJQSGkxj9k4sbnI4LO9Zp+eNWkoe3G36TocId drICsf6mh1MFfDb97yH7l34qgcEBwdDe+imLqbHxEjSSfoljzpDlVwEJvaJrIWFRSx3M Seajb7G1mJvYXG0hoXIB/hBMgh/tJasxQG3gWfDSlCek3SWHV1HJKitbWRdYytDTR9Rf QBauw0s5CQK1HKaXI3jXc6G+Oi1oiBJ4jKwvomzAJNQFeBY4tzOSdvgUHy2MRxDmBc7c UGSA== 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=2ELuvUBqjH211GemXhXl0U7UrbeEzwGHi2aD0VN8/4s=; b=GfC6XSpCOA9eD2VlbzP8JFWfFRvV+ToUTz0YvFbdkux4oj0jv6r5AxneWk5wx8tbTV kI2ePcSksRRvaiHmK8h2Ron9/bG+Ga5czCUhAbcTwc0phtaxbBYHS2WyUKtiFuC+aA60 Ca3NY3f+Pj0HoeNTo2N53CAk0fgJwzrxIebY+qqHua8kfIyFrlIbA1f73Fiv9zZeQwRT RsfXQmoPPKj3YdzEG/c/fCN4xUmZj31912XNuBczVx3nY4ubDLm/xC1ulsFmQYEYcmt1 wkdQOBQedP5z/aitc/Tpp1HCn5x5XtXvTk6Ltry8jD3ccp9fzP9J5GImGX4CDMTnoh5T XYHg== X-Gm-Message-State: ALoCoQklntxPRhBGUIVt18OB6N3avEVcKIiP3bZ8U+Eo17Q5cmXDSqo0/rMkyo71Qy2xV248Fu/k X-Received: by 10.68.201.7 with SMTP id jw7mr3056823pbc.8.1390059379544; Sat, 18 Jan 2014 07:36:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.138 with SMTP id k10ls296164qge.66.gmail; Sat, 18 Jan 2014 07:36:18 -0800 (PST) X-Received: by 10.140.43.227 with SMTP id e90mr147527qga.4.1390059378760; Sat, 18 Jan 2014 07:36:18 -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:8682 Archived-At: ------=_Part_422_23998461.1390059377973 Content-Type: text/plain; charset=UTF-8 Am Samstag, 18. Januar 2014 03:15:43 UTC+1 schrieb Peter Bigot: > > On Friday, January 17, 2014 7:00:12 PM UTC-6, Bengt Gustafsson wrote: >> >> I have not followed this entire thread, instead I hacked up a little >> implementation which I used in implementing something for another thread on >> an improved "printf" functionality. What I noticed was: >> >> - I had use for a C array of string_view to keep the parts of the >> original string that fell between each data inserted. This means that I >> must be able to default construct string_view as there is no other way to >> construct an array element. >> > > Sure, that's one approach. > > >> - It is logical to do this default construction by setting m_begin and >> m_end to nullptr, or m_begin to nullptr and m_size to 0. >> > > Logical, perhaps; necessary, no. It's equally or more logical to treat it > the same as a default-constructed std::string. It was tentatively agreed > much earlier in this or another thread that doing so doesn't even require > allocating any memory to hold the "referenced" empty string, while still > preserving the requirement that data() have a value distinct from nullptr. > > >> - It must be allowed to take a default constructed string_view as the >> range of a range based for statement >> > > Sure. > > >> __or__ to check if the range is in default constucted state using >> something like os_null(). >> > > Why? Is there something specific to ranges that makes a > default-constructed range significant? > > >> - both of these methods are impossible if the presumptions stated above >> "begin() should never return nullptr" and "we don't need a special >> is_null()". Well, not entirely. Of course you could create some bogus >> object and use its address instead of nullptr. >> >> Someone stated above that the \0 at the end of the string should be >> accessible even if the string_view is empty. This is clearly impossible as >> a string_view may be constructed as a part of a string which continues on. >> Thus there is no \0 at *end() anytime. >> > > This may be referring to what I said about deref(sv2) in Marshall's > example, but if so it isn't an accurate summary. What I said is that if a > string_view is constructed from a string literal (which is necessarily > nul-terminated) and the default size calculated from traits::length(str), > then even though accessing the terminating nul from the string_view is not > legal the nul is still there and still legally accessible by using a char* > pointer which is known to point into that string literal. > > Here's another example which avoids the nul and any assumptions about > persistence of the string literal: > > const std::string base("ABCDE"); > string_view sv(base); > ASSERT_EQ(base.data(), sv.data()); > sv.remove_prefix(2); > ASSERT_EQ(base.data()+2, sv.data()); > sv.remove_suffix(3); > ASSERT_EQ(0, sv.size()); > ASSERT_EQ(base.data()+2, sv.data()); > ASSERT_EQ('C', *sv.data()); > > sv in isolation only guarantees that [sv.data(), sv.data()+0) is a valid > range and specifically does not sanction the expression *sv.data(). > > But sv.data() is value- and type-equivalent to base.data()+2 by the > specification for string_view. > > And accessing *(base.data()+2) is perfectly legitimate. > > So why can't I substitute a value- and type-equivalent subexpression into > that dereference expression? > > I'm hoping that somebody will explain why this is an invalid use of > std::string_view as currently described in > https://rawgithub.com/google/cxx-std-draft/string-ref-paper/string_view.html > . > > As for why I think allowing null sv.data() creates a new requirement to > check for null sv.data(): If you accept that sv.data() can be useful even > though sv.size() is zero---perhaps for nothing more than to calculate an > offset into the original string with sv.data()-base.data()---then it > becomes necessary to know that sv.data() is not null regardless of whether > sv.size() is zero so you don't perform pointer arithmetic on a null > pointer. Not always, but certainly if you're using sv.data() this way > (which I have found very convenient). > For the current proposal this should work. Since you can't put a nullptr in you can't get a nullptr out and sv.data() - base.data() is defined. If a string_view would allow null data() then (assuming a string_view is constructible from a nullptr, too) this would be ok too, since no operation on a string_view changes the data pointer and subtracting a nullptr from a nullptr is ok too. If a stringview were allowed to be constructed from a nullptr, but data() always returns non-null, then one actually has to check for base.data() != null., > > My preference is to impose the non-null requirement on the string_view > type just as it is imposed on std::string, rather than have to check it > manually. (AFAIK std::string has never permitted its data() function to > return a null pointer, so I don't see a lot of value in reviewing that > decision.) > > 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_422_23998461.1390059377973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Am Samstag, 18. Januar 2014 03:15:43 UTC+1 schrieb= Peter Bigot:
On Friday, Janua= ry 17, 2014 7:00:12 PM UTC-6, Bengt Gustafsson wrote:
I have not followed this entire thread, instead I h= acked up a little implementation which I used in implementing something for= another thread on an improved "printf" functionality. What I noticed was:<= div>
- I had use for a C array of string_view to keep the par= ts of the original string that fell between each data inserted. This means = that I must be able to default construct string_view as there is no other w= ay to construct an array element.

Sure, th= at's one approach.
 
- It is logical to do this default construction by setting m_= begin and m_end to nullptr, or m_begin to nullptr and m_size to 0.

Logical, perhaps; necessary, no.  It's equall= y or more logical to treat it the same as a default-constructed std::string= ..  It was tentatively agreed much earlier in this or another thread th= at doing so doesn't even require allocating any memory to hold the "referen= ced" empty string, while still preserving the requirement that data() have = a value distinct from nullptr.
 
- It must be allowed to take a default constructe= d string_view as the range of a range based for statement

Sure.
 
__or__ to check if the range is in default constucted sta= te using something like os_null().

Why?&nb= sp; Is there something specific to ranges that makes a default-constructed = range significant?


- both of these methods are impossible if= the presumptions stated above "begin() should never return nullptr" and "w= e don't need a special is_null()". Well, not entirely. Of course you could = create some bogus object and use its address instead of nullptr.
=
Someone stated above that the \0 at the end of the string sh= ould be accessible even if the string_view is empty. This is clearly imposs= ible as a string_view may be constructed as a part of a string which contin= ues on. Thus there is no \0 at *end() anytime.

This may be referring to what I said about deref(sv2) in Marshall's ex= ample, but if so it isn't an accurate summary.  What I said is that if= a string_view is constructed from a string literal (which is necessarily n= ul-terminated) and the default size calculated from traits::length(str), th= en even though accessing the terminating nul from the string_view is not le= gal the nul is still there and still legally accessible by using a char* po= inter which is known to point into that string literal.

Here's= another example which avoids the nul and any assumptions about persistence= of the string literal:

  const std::string base("ABCDE");
&= nbsp; string_view sv(base);
  ASSERT_EQ(base.data(), sv.data());  sv.remove_prefix(2);
  ASSERT_EQ(base.data()+2, sv.data());=
  sv.remove_suffix(3);
  ASSERT_EQ(0, sv.size());
 = ; ASSERT_EQ(base.data()+2, sv.data());
  ASSERT_EQ('C', *sv.data())= ;

sv in isolation only guarantees that [sv.data(), sv.data()+0) is a= valid range and specifically does not sanction the expression *sv.data().<= br>
But sv.data() is value- and type-equivalent to base.data()+2 by the = specification for string_view.

And accessing *(base.data()+2) is per= fectly legitimate.

So why can't I substitute a value- and type-equiv= alent subexpression into that dereference expression?

I'm hoping tha= t somebody will explain why this is an invalid use of std::string_view as c= urrently described in https://rawgithub= ..com/google/cxx-std-draft/string-ref-paper/string_view.html.<= br>
As for why I think allowing null sv.data() creates a new requirement= to check for null sv.data():  If you accept that sv.data() can be use= ful even though sv.size() is zero---perhaps for nothing more than to calcul= ate an offset into the original string with sv.data()-base.data()---then it= becomes necessary to know that sv.data() is not null regardless of whether= sv.size() is zero so you don't perform pointer arithmetic on a null pointe= r.  Not always, but certainly if you're using sv.data() this way (whic= h I have found very convenient).

= For the current proposal this should work. Since you can't put a nullptr in= you can't get a nullptr out and sv.data() - base.data() is defined.
<= div>If a string_view would allow null data() then (assuming a string_view i= s constructible from a nullptr, too) this would be ok too, since nooperation on a string_view changes the data pointer and subtracting a nu= llptr from a nullptr is ok too.
If a stringview were allowed to b= e constructed from a nullptr, but data() always returns non-null, then one = actually has to check for base.data() !=3D null., 

My preference is to impose the non-null= requirement on the string_view type just as it is imposed on std::string, = rather than have to check it manually.   (AFAIK std::string has n= ever permitted its data() function to return a null pointer, so I don't see a lot of value in reviewing that decision.)

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_422_23998461.1390059377973-- .