220 8722 <60842af6-5ec4-4364-b2d5-a0be9d578bd6@isocpp.org> 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: Sun, 19 Jan 2014 17:54:32 -0800 (PST) Lines: 201 Approved: news@gmane.org Message-ID: <60842af6-5ec4-4364-b2d5-a0be9d578bd6@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_598_24792908.1390182872735" X-Trace: ger.gmane.org 1390182868 2958 80.91.229.3 (20 Jan 2014 01:54:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 01:54:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA3LUEAQACBBWMD6KLAKGQECEQ2RCI@isocpp.org Mon Jan 20 02:54:36 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f71.google.com ([209.85.160.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W544R-0004Le-M8 for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 02:54:36 +0100 Original-Received: by mail-pb0-f71.google.com with SMTP id jt11sf11282240pbb.10 for ; Sun, 19 Jan 2014 17:54:34 -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=Sua4PliqhQWpHDGCgp23X31FrnHY0pYV5xajvorz7iQ=; b=A46epk+DDKP6XR0iJbaiGl5uzNkw5NwyOG36AsK3X96/cqwuiH6ZBGDNoYcwFdYKSQ 1r3k3mCuQ+E/CIodGUafIIqaX35vBgVLKe9o3KLRsp2j6lmqACgpIPVqzQkxKwDhsGEc 4xTVCbLnxsYqdXrBD/vhaJ/XSL3ApdJLYUabfrv4Ju8wpv0Y62jBRkfw4ee0WqC6DxHG kNgNQAxuP8uN33u3Hub4YfcH8LKRh1YjPG2CwtOf9Tn9eU94NLrfZre/mLGcSN4wOzka cKKZ/Y5FULCYbc8uUVYt/Wh7XnHWOJPdPe2Uf2QCRmAAjEUdx9TWTyAb6kEhwpWcv9p7 endg== X-Gm-Message-State: ALoCoQnO9nUMR+x5p1M96IU+Wrnd4lHN39oljCFAqqsI1VP9PXWqm3UjpBAw7owg66N83yrZxyTx X-Received: by 10.66.253.9 with SMTP id zw9mr6435504pac.38.1390182874487; Sun, 19 Jan 2014 17:54:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.33.35 with SMTP id o3ls846978obi.73.gmail; Sun, 19 Jan 2014 17:54:33 -0800 (PST) X-Received: by 10.182.199.39 with SMTP id jh7mr23689obc.25.1390182873340; Sun, 19 Jan 2014 17:54:33 -0800 (PST) In-Reply-To: <20140119192238.GA19497@faust.lysator.liu.se> 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:8722 Archived-At: ------=_Part_598_24792908.1390182872735 Content-Type: text/plain; charset=UTF-8 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 >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().) 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. > 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_598_24792908.1390182872735 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sunday, January 19, 2014 1:22:40 PM UTC-6, Magn= us 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:
>=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().)

I do think t= hat 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 w= hether an instance holds a valid reference (i.e. does not have a default-co= nstructed value, including a value equivalent to default-construction due t= o invocation of clear()).  If this is desirable, it can be detected ea= sily by adding a member function has_reference() that returns !!m_ptr.
&= nbsp;
and "have an optimi= zed 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_598_24792908.1390182872735-- .