220 8693 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 12:31:19 -0600 Lines: 215 Approved: news@gmane.org Message-ID: References: <8E74B747-7450-41E0-8D1E-48C2D6F81535@gmail.com> <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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c24dbc42210b04f056fb51 X-Trace: ger.gmane.org 1390156275 27022 80.91.229.3 (19 Jan 2014 18:31:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 18:31:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA3LUEAQACBB6FT6CLAKGQENBTKHPQ@isocpp.org Sun Jan 19 19:31:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f72.google.com ([209.85.212.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4x9V-0004eH-Vh for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 19:31:22 +0100 Original-Received: by mail-vb0-f72.google.com with SMTP id w20sf6055014vbb.11 for ; Sun, 19 Jan 2014 10:31:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=SeK5KIcAw6M6/9fro/+vk/JGoxddQrgvyPrrPqP02Vo=; b=mARHrJ6A+wWapYWnNCuJraRtoNroQriCGhMMw+cnzYGmx44fEy5+59GBhqitIL6QHG pBdd52gz6kSze+1TPO36QeWhc9NEMu7hquyirP9+prwucpq6s/tZmVu1xH2+/B/qtV2h rqeq2gyNoXXm1GZB+6JgoQtFB+SlY6bGjdGzRDZFe7Q7WAlsBTsN/zuQuUeGdfaAWP2b 4Oz6+NRcjxwFrKt/QrzgAYO5GkgTaqoJ0kizloquzPKGweKgDmF0pS8alpN0cMrETSPG BqtixCjyjNhkx2qJG1K5V7UNavIUeiC0s+Ujpg9oueepTfxCYt4pd6nA8PQ2vHHhWMLF inIA== X-Gm-Message-State: ALoCoQlKV+fqLG32DyZLru8iVIYaSh45AgyG4rmtKYyy/ABi8JEkqKqWoW7+k7rFOnFoeLufVmGJ X-Received: by 10.236.17.161 with SMTP id j21mr657943yhj.55.1390156281066; Sun, 19 Jan 2014 10:31:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.108.65 with SMTP id hi1ls1640697qeb.24.gmail; Sun, 19 Jan 2014 10:31:20 -0800 (PST) X-Received: by 10.236.135.172 with SMTP id u32mr595684yhi.107.1390156280557; Sun, 19 Jan 2014 10:31:20 -0800 (PST) Original-Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [2607:f8b0:4003:c01::22f]) by mx.google.com with ESMTPS id j50si18672267yhc.0.2014.01.19.10.31.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Jan 2014 10:31:20 -0800 (PST) Received-SPF: pass (google.com: domain of pabigot@gmail.com designates 2607:f8b0:4003:c01::22f as permitted sender) client-ip=2607:f8b0:4003:c01::22f; Original-Received: by mail-ob0-f175.google.com with SMTP id wn1so757110obc.6 for ; Sun, 19 Jan 2014 10:31:20 -0800 (PST) X-Received: by 10.60.63.235 with SMTP id j11mr530119oes.61.1390156280109; Sun, 19 Jan 2014 10:31:20 -0800 (PST) Original-Sender: pabigot@gmail.com Original-Received: by 10.76.168.228 with HTTP; Sun, 19 Jan 2014 10:31:19 -0800 (PST) In-Reply-To: <20140119174431.GA16875@faust.lysator.liu.se> X-Original-Sender: bigotp@acm.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of pabigot@gmail.com designates 2607:f8b0:4003:c01::22f as permitted sender) smtp.mail=pabigot@gmail.com; dkim=pass header.i=@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:8693 Archived-At: --001a11c24dbc42210b04f056fb51 Content-Type: text/plain; charset=ISO-8859-1 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: > > > > > > On Jan 17, 2014, at 6:13 PM, Miro Knejp > > > > wrote: > > > > > > >> > > > >> - 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. > > > >> > > > > Why not set the string_view to "" in the default constructor? > > > > > > I believe that this is the current proposal. > > > > > > However, this requires creating a global variable (which some > > > implementations will put in the code segment) for each default > constructed > > > string_view (yes, some implementations will merge them together in the > same > > > translation unit). > > > > > > > I thought somebody had proposed a "will-probably-work" solution involving > > casts of non-zero values to a pointer to avoid the global variable, but > > here's another solution I believe is safe and well-defined: > > > > Nothing in the current spec requires that the data() function return the > > same value for distinct default-constructed string_view instances. So > use > > the following data members: > > > > const charT * m_ptr; > > union { > > size_t m_len; > > charT m_nul; > > }; > > > > and have the default constructor set m_ptr to &m_nul and m_len to 0. The > > result is a (unique) empty string reference. > > > > I've tested this by modifying Boost's implementation and it works fine. > > Note that only the m_len data member is actually used and is always zero > > for the default-constructed value. There's no issue about accessing the > > other union member because when size() is zero you can't legitimately > > dereference data() unless you know from construction that it's pointing > > into a non-empty range (and in this case it doesn't). > > 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? 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/. --001a11c24dbc42210b04f056fb51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Jan 19, 2014 at 11:44 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
On Sun, Jan 19, 2014 at 07:55:32AM -080= 0, Peter Bigot wrote:
> On Friday, January 17, 2014 10:19:07 PM UTC-6, Marshall wrote:
> >
> > On Jan 17, 2014, at 6:13 PM, Miro Knejp <mi...@knejp.de <javascript:>= >
> > wrote:
> >
> > >>
> > >> - both of these methods are impossible if the presumptio= ns stated above
> > "begin() should never return nullptr" and "we don&= #39;t need a special
> > is_null()". Well, not entirely. Of course you could create s= ome bogus
> > object and use its address instead of nullptr.
> > >>
> > > Why not set the string_view to "" in the default c= onstructor?
> >
> > I believe that this is the current proposal.
> >
> > However, this requires creating a global variable (which some
> > implementations will put in the code segment) for each default co= nstructed
> > string_view (yes, some implementations will merge them together i= n the same
> > translation unit).
> >
>
> I thought somebody had proposed a "will-probably-work" solut= ion involving
> casts of non-zero values to a pointer to avoid the global variable, bu= t
> here's another solution I believe is safe and well-defined:
>
> Nothing in the current spec requires that the data() function return t= he
> same value for distinct default-constructed string_view instances. =A0= So use
> the following data members:
>
> =A0 const charT * m_ptr;
> =A0 union {
> =A0 =A0 =A0size_t m_len;
> =A0 =A0 =A0charT m_nul;
> =A0 };
>
> and have the default constructor set m_ptr to &m_nul and m_len to = 0. =A0The
> result is a (unique) empty string reference.
>
> I've tested this by modifying Boost's implementation and it wo= rks fine.
> Note that only the m_len data member is actually used and is always ze= ro
> for the default-constructed value. =A0There's no issue about acces= sing the
> other union member because when size() is zero you can't legitimat= ely
> dereference data() unless you know from construction that it's poi= nting
> into a non-empty range (and in this case it doesn't).

I have thought in a similar direction, but the problem is if yo= u have two
string_view's, s1 and s2. Assume that s1 i empty, does the statement s2 =3D s1; imply that s2.data() =3D=3D s1.data()?

Then what happens if s1 is deallocated and it's memory is returned to t= he
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.<= br>

In my approach I detect in the assignme= nt operator and copy constructor whether the RHS is default-constructed, an= d if so invoke clear() on the LHS/new instance.=A0 So in all cases either t= he reference is to a sequence outside the instance, or it's an empty de= fault-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 an= d operator=3D which are specified as =3Ddefault.

On further reflecti= on 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.= =A0 Then the default implementations are retained.=A0 This still means that= data() will be always be non-null, but sv1.data() will not compare equal t= o sv2.data() if one or both of the instances have been cleared/default-cons= tructed.=A0 (sv1 =3D=3D sv2 will still hold, of course.)

Does that address the objection?

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>.
--001a11c24dbc42210b04f056fb51-- .