220 8726 <6c82c4ae-c144-443a-81b2-ea1a6b645601@isocpp.org> article Path: news.gmane.org!not-for-mail From: Paul Tessier Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Sun, 19 Jan 2014 20:07:45 -0800 (PST) Lines: 249 Approved: news@gmane.org Message-ID: <6c82c4ae-c144-443a-81b2-ea1a6b645601@isocpp.org> References: <104254A6-C69A-4571-8455-89D7E466D493@gmail.com> <6a95bf9c-55c9-4ae2-966f-d1b1f4df6a37@isocpp.org> <52D9E336.1060801@knejp.de> <1B534FD7-B385-4A7E-A718-3C73F0AB61DC@gmail.com> <11f13f8f-1270-427c-8942-94027a181ff4@isocpp.org> <20140119174431.GA16875@faust.lysator.liu.se> <20140119192238.GA19497@faust.lysator.liu.se> <60842af6-5ec4-4364-b2d5-a0be9d578bd6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1627_22142613.1390190865793" X-Trace: ger.gmane.org 1390190862 14487 80.91.229.3 (20 Jan 2014 04:07:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 04:07:42 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDYTQX56INBBEWC6KLAKGQEFGIGDWA@isocpp.org Mon Jan 20 05:07:50 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W569M-0008Ie-6x for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 05:07:48 +0100 Original-Received: by mail-yk0-f197.google.com with SMTP id 20sf5726118yks.0 for ; Sun, 19 Jan 2014 20:07:47 -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=hkYBN0C51xaltXDeY/RIQheu5jOTgM754B5zBH2UCC0=; b=K1bk5534Q8zzOMB0yTg5wrsZ8ZuIBAmmFgP32Ihv3XTGe7dKUXSgT8G9yRGEnwoI1b GFa3dlrc6J33o8aRDtBkxCgszXxw+HktLUFzfZrCgk/a7ofFu1g/S36otNNPzM8MyyIz Di4lnm5sruA2mfBMGpVOFgXAVElIXxnIN1W1sKrXztZBXZXosR684fgL12NlYBv89Ejs u3s9DoPJ9rDZ/+KF7hMlBLCeqxZxs5q+NRXX+SW/6YPVUt0Ru0LK1CvI03rA65lyvZvI 8y/ClLiaSJEq4Ox/1T0slerIdCP3eaC6FYq4ktAU33xvdadF5S3sRQaK/xb+zeDnH9C/ 0H1Q== 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=hkYBN0C51xaltXDeY/RIQheu5jOTgM754B5zBH2UCC0=; b=cFrQAIemWtmC976nj4rNTwOko29oNstZ/w5GWkzxxqhU7Et3ENQ1uAZl2LveuZC6XH Pqm3weUFAsRXOLzQE61Y3gYuFSsluqT2fTHatbSGVNeIobaHb9aJthtyV12QlIj11yUd sf38IoE81E8BR6+HIFb58FugF3D52TPSXnsiJb3F4eJ7VfPLah0Nj1kNkEH/ev93zBRo wOSuGu7x1eN3yac726aKSoQ5WrZTDjQQDStsv46aEYtYYATl5WxNznHeNuBLyChOKkh7 bRWaJcJcv1iP9lIpGtNDeZD9ibuDrtKpX8/QXWtmFWx2JJ6yRoJq8BDReFrjREK53OH4 n0dw== X-Gm-Message-State: ALoCoQlkw9o/uaJp2H40EPeVUE+bMPcCBkOsw5OQgON3UBAhWa1djLAljhLtPli4j5gPN0cDg4Ce X-Received: by 10.224.121.70 with SMTP id g6mr2223838qar.1.1390190867151; Sun, 19 Jan 2014 20:07:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.48.165 with SMTP id m5ls27778qen.52.gmail; Sun, 19 Jan 2014 20:07:46 -0800 (PST) X-Received: by 10.140.48.8 with SMTP id n8mr515qga.36.1390190866578; Sun, 19 Jan 2014 20:07:46 -0800 (PST) In-Reply-To: <60842af6-5ec4-4364-b2d5-a0be9d578bd6@isocpp.org> X-Original-Sender: phernost@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:8726 Archived-At: ------=_Part_1627_22142613.1390190865793 Content-Type: text/plain; charset=UTF-8 On Sunday, January 19, 2014 8:54:32 PM UTC-5, Peter Bigot wrote: > > > > On Sunday, January 19, 2014 1:22:40 PM UTC-6, Magnus Fromreide wrote: >> >> On Sun, Jan 19, 2014 at 12:31:19PM -0600, Peter Bigot wrote: >> > On Sun, Jan 19, 2014 at 11:44 AM, Magnus Fromreide < >> ma...@lysator.liu.se>wrote: >> > >> > > On Sun, Jan 19, 2014 at 07:55:32AM -0800, Peter Bigot wrote: >> > > > On Friday, January 17, 2014 10:19:07 PM UTC-6, Marshall wrote: >> > > > > >> > > >> > > I have thought in a similar direction, but the problem is if you have >> two >> > > string_view's, s1 and s2. Assume that s1 i empty, does the statement >> > > s2 = s1; imply that s2.data() == s1.data()? >> > > >> > > Then what happens if s1 is deallocated and it's memory is returned to >> the >> > > system, won't s2.m_ptr then hold an illegal pointer value, one of >> those >> > > where even loading it could trigger a hardware trap on some >> architectures. >> > > >> > >> > In my approach I detect in the assignment operator and copy constructor >> > whether the RHS is default-constructed, and if so invoke clear() on the >> > LHS/new instance. So in all cases either the reference is to a >> sequence >> > outside the instance, or it's an empty default-constructed (cleared) >> > instance where data() is a non-dereferenceable pointer to an internal >> charT >> > object: no cross-object pointers. >> > >> > Now that you point it out, this does result in behavior non-conformant >> with >> > the current draft specification for the copy constructor and operator= >> > which are specified as =default. >> > >> > On further reflection it'd better to store a null pointer in m_ptr to >> > represent a default-constructed value but to return &m_nul from data() >> when >> > m_ptr is null. Then the default implementations are retained. This >> still >> > means that data() will be always be non-null, but sv1.data() will not >> > compare equal to sv2.data() if one or both of the instances have been >> > cleared/default-constructed. (sv1 == sv2 will still hold, of course.) >> > >> > Does that address the objection? >> >> The check at copy time seems to solve the problem. >> >> The use of null as a flag value seems to interfere with the "allow null >> string_views" > > > Yes. I am not in favor of string_view supporting null values as well as > empty values; absence of a value is a distinct concept that should be > treated independently as with std::optional. I think string_view should > support the intersection, not the union, of the information provided by its > underlying concepts (a) std::string and (b) a pair (const charT * ptr, > size_t len). Only the latter is capable of expressing absence-of-a-value > as distinct from empty-string. (In fact it expresses multiple > absence-of-a-value as you could wish to encode information in a non-zero > size() paired with a null data(). Madness that way lies. Just say no to > null data().) > Why would ( nullptr, 3 ) be considered an empty view? It's garbage in almost all use cases but, so is ( (char*)1, 3 ). Defending against one single bad pointer and ignoring all the rest, solves one out of a myriad of similar problems. A null view ( null, 0 ) is no different than an empty view ( (char*)rand(), 0 ). Although, is_null seems pointless if it can be guaranteed that the following be true. For any empty string_view N constructed as ( string_view N{ P, 0 } ), that N.data(), N.begin(), N.end(), etc. all return P. Currently P is banned from being null. Which seems to solve one corner case and, creates problems for other, otherwise logical, use cases. > > I do think that string_view is more a reference type than a collection > type (thought it is both), so there may be an argument in support of being > able to detect whether an instance holds a valid reference (i.e. does not > have a default-constructed value, including a value equivalent to > default-construction due to invocation of clear()). If this is desirable, > it can be detected easily by adding a member function has_reference() that > returns !!m_ptr. > > All references can become dangling by one way or another. What you described is a smart pointer with a string interface, which if that's what you want, I can argue against. It may solve many use cases but, seems overkill at least considering the current stated goal of string_view. > and "have an optimized optional" proposals >> as both allow null's for other purposes. >> > > I can't speak to that question. > > 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_1627_22142613.1390190865793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sunday, January 19, 2014 8:54:32 PM UTC-5, Pete= r Bigot wrote:


On Sunday, January 19, 2014 1:22:40 PM UTC-6, Magnus Fromreide wro= te:
On Sun, Jan 19, 2014 at 12:31:19= PM -0600, Peter Bigot wrote:
> On Sun, Jan 19, 2014 at 11:44 AM, Magnus Fromreide <ma...@ly= sator.liu.se>wrote:
>=20
> > On Sun, Jan 19, 2014 at 07:55:32AM -0800, Peter Bigot wrote:
> > > On Friday, January 17, 2014 10:19:07 PM UTC-6, Marshall = wrote:
> > > >
> >
> > I have thought in a similar direction, but the problem is if = you have two
> > string_view's, s1 and s2. Assume that s1 i empty, does the st= atement
> > s2 =3D s1; imply that s2.data() =3D=3D s1.data()?
> >
> > Then what happens if s1 is deallocated and it's memory is ret= urned to the
> > system, won't s2.m_ptr then hold an illegal pointer value, on= e of those
> > where even loading it could trigger a hardware trap on some a= rchitectures.
> >
>=20
> In my approach I detect in the assignment operator and copy constr= uctor
> whether the RHS is default-constructed, and if so invoke clear() o= n the
> LHS/new instance.  So in all cases either the reference is to= a sequence
> outside the instance, or it's an empty default-constructed (cleare= d)
> instance where data() is a non-dereferenceable pointer to an inter= nal charT
> object: no cross-object pointers.
>=20
> Now that you point it out, this does result in behavior non-confor= mant with
> the current draft specification for the copy constructor and opera= tor=3D
> which are specified as =3Ddefault.
>=20
> On further reflection it'd better to store a null pointer in m_ptr= to
> represent a default-constructed value but to return &m_nul fro= m data() when
> m_ptr is null.  Then the default implementations are retained= ..  This still
> means that data() will be always be non-null, but sv1.data() will = not
> compare equal to sv2.data() if one or both of the instances have b= een
> cleared/default-constructed.  (sv1 =3D=3D sv2 will still hold= , of course.)
>=20
> Does that address the objection?

The check at copy time seems to solve the problem.

The use of null as a flag value seems to interfere with the "allow null
string_views"

Yes.  I am not in favor of str= ing_view supporting null values as well as empty values; absence of a value= is a distinct concept that should be treated independently as with std::op= tional.  I think string_view should support the intersection, not the = union, of the information provided by its underlying concepts (a) std::stri= ng and (b) a pair (const charT * ptr, size_t len).  Only the latter is= capable of expressing absence-of-a-value as distinct from empty-string.&nb= sp; (In fact it expresses multiple absence-of-a-value as you could wish to = encode information in a non-zero size() paired with a null data().  Ma= dness that way lies.  Just say no to null data().)

Why would ( nullptr, 3 ) be considered an empty view?&nbs= p; It's garbage in almost all use cases but, so is ( (char*)1, 3 ).  D= efending against one single bad pointer and ignoring all the rest, solves o= ne out of a myriad of similar problems.  A null view ( null, 0 ) is no= different than an empty view ( (char*)rand(), 0 ).  Although, is_null= seems pointless if it can be guaranteed that the following be true.
For any empty string_view N constructed as ( string_view N{ P, 0 } ), that= N.data(), N.begin(), N.end(), etc. all return P.

Currently P is ban= ned from being null.  Which seems to solve one corner case and, create= s problems for other, otherwise logical, use cases.
 

I do thi= nk that string_view is more a reference type than a collection type (though= t it is both), so there may be an argument in support of being able to dete= ct whether an instance holds a valid reference (i.e. does not have a defaul= t-constructed value, including a value equivalent to default-construction d= ue to invocation of clear()).  If this is desirable, it can be detecte= d easily by adding a member function has_reference() that returns !!m_ptr.<= br> 

All references can become dangli= ng by one way or another.  What you described is a smart pointer with = a string interface, which if that's what you want, I can argue against.&nbs= p; It may solve many use cases but, seems overkill at least considering the= current stated goal of string_view.
 
and "have an optimized optional<string_view>" proposals
as both allow null's for other purposes.

I can't speak to that question.

Pete= r

--
 
---
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_1627_22142613.1390190865793-- .