220 8707 <52DC491D.5060806@gmail.com> article Path: news.gmane.org!not-for-mail From: "Paul A. Tessier" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Sun, 19 Jan 2014 16:52:29 -0500 Lines: 467 Approved: news@gmane.org Message-ID: <52DC491D.5060806@gmail.com> 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> <52DC20DB.9030303@gmail.com> <1e1da13e-663f-4f98-8f54-595b8f75591e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040806000801000106030406" X-Trace: ger.gmane.org 1390168348 27148 80.91.229.3 (19 Jan 2014 21:52:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 21:52:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDYTQX56INBBH4S6GLAKGQEDUEIMBQ@isocpp.org Sun Jan 19 22:52:34 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 1W50ID-00074G-Bb for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 22:52:33 +0100 Original-Received: by mail-pb0-f71.google.com with SMTP id jt11sf10904674pbb.2 for ; Sun, 19 Jan 2014 13:52:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-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=an+ULftURk05kBlQfTEaoDF4ldaqDRDuDvh2FvK1wzk=; b=XAFNu1Cj1r4l1t6QGf3wcBU8sjzdkJzVEBW598Kix3pB+wemtESCOfQ7jldFN9WahV W07HF0WOhJIAp3zJkKs/Er65L89MkF0W0Kb47/tf2uXpWUgCeB1+D3DlQwgyasDJ2USR HXHNgCNQoQT6SGnbQgHP7iAqmJL2yBOohTkfQJJ/rr0MPVtESh29z/Zmb6giT8zThrpj ZklRI+dZ2RFq41GrmL8cZ4W8kfLDW3V0ybv1LvCOwhedr2F7erdOXx2n7HvHha5+PIi5 5Iwk9pHVlY3ea70ARAbhW27v9gJstAt4gFQwjeL1/XNA2mZ4Fa2biTV/L7UHQAVG26VS PE2w== X-Gm-Message-State: ALoCoQl5/4p4aEvq3sa/LW+VXC44X5IxwajKTuc6AyohHdW5btfrjkmSRcl/Xo7JSk2YVR3NyG4B X-Received: by 10.67.4.202 with SMTP id cg10mr1295093pad.42.1390168351927; Sun, 19 Jan 2014 13:52:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.80.148 with SMTP id c20ls886402qgd.94.gmail; Sun, 19 Jan 2014 13:52:31 -0800 (PST) X-Received: by 10.140.101.162 with SMTP id u31mr21757665qge.107.1390168351294; Sun, 19 Jan 2014 13:52:31 -0800 (PST) Original-Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [2607:f8b0:400d:c01::236]) by mx.google.com with ESMTPS id e7si4429772qew.114.2014.01.19.13.52.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Jan 2014 13:52:31 -0800 (PST) Received-SPF: pass (google.com: domain of phernost@gmail.com designates 2607:f8b0:400d:c01::236 as permitted sender) client-ip=2607:f8b0:400d:c01::236; Original-Received: by mail-qc0-f182.google.com with SMTP id c9so5291622qcz.41 for ; Sun, 19 Jan 2014 13:52:31 -0800 (PST) X-Received: by 10.224.165.12 with SMTP id g12mr21716617qay.89.1390168351078; Sun, 19 Jan 2014 13:52:31 -0800 (PST) Original-Received: from [192.168.0.150] (c-71-192-182-216.hsd1.ma.comcast.net. [71.192.182.216]) by mx.google.com with ESMTPSA id nz10sm25137948qeb.10.2014.01.19.13.52.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Jan 2014 13:52:30 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <1e1da13e-663f-4f98-8f54-595b8f75591e@isocpp.org> X-Original-Sender: phernost@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of phernost@gmail.com designates 2607:f8b0:400d:c01::236 as permitted sender) smtp.mail=phernost@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:8707 Archived-At: This is a multi-part message in MIME format. --------------040806000801000106030406 Content-Type: text/plain; charset=UTF-8; format=flowed On 01/19/2014 03:37 PM, Alexander Bolz wrote: > Am Sonntag, 19. Januar 2014 20:00:43 UTC+1 schrieb Paul Tessier: > > On 01/19/2014 12:44 PM, 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. > > > > /MF > > > > If s1 and s2 are empty, only access to the metadata is rational. > Using > operator[], front(), back(), etc. will produce undefined behavior. > s1.data() and s2.data() are irrelevant because, it points to the > beginning of a range of zero length. One could just as easily set > data() to null or some random value, when the string_view becomes > empty > but, such actions are unneeded. The equality comparison is based > on the > equality of the two ordered sets of characters from s1 and s2. All > empty views are equally empty and does not imply ( s2.data() == > s1.data() ), just as ( s1 == s2 ) does not imply that ( &s1 == &s2 ). > > If &s1 is deallocated and falls into a protected segment, any > access to > it will trap, just like any other object. If both s1 and s2 where > referencing a string that was deallocated before they both became > empty > then, both would trap, unless data() is randomized or set to some > safe > location as I mentioned above but, this would be pointless as > accessing > the referenced string of an empty view is undefined behavior. > > > To me the prevention of null being returned by data() is just an > artifact inherited from std::string. It seem like an early and > incomplete error check. You could also argue that all unreachable > segments be restricted. > > If string_view was only a range of a std:string, forwarding all > std::string's warts through the interface would not be completely > unexpected. Especially when the wrapper is such a lightweight class. > Yet, string_view serves a wider purpose therefore, those warts should > ignored. I argue that std::string's interface should be relaxed > and, not > that string_view's be restricted. > > Consider std::array< char, 0 >. It's data() will return null, and > the > rest of it's members behave as rationally. > > > This is not correct. I just looked it up in N3797: > 23.3.2.8. says "begin() == end() == unique value. The return value of > data() is unspecified" > > I see no reason for > string_view not to behave in a similar fashion. While std:string may > never return null for it's data(), it is inconsequential as > string_view > maybe constructed from other sources. > > Having a is_null() seems excessive. data() should be allowed to be > null, > as this seems the simplest solution. Following the behavior of > std::array< char, 0 > seems to solve many of the other problems in > the > interface being unable to handle data() and begin() being null. > > While string_view is modeled after std::string's interface, the newer > std::array interface seems more flexible and also solves the default > empty initialization problem. Besides, any object that behaves > rationally when zeroed out, say by memset, is a plus. > > > -- > > --- > 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/. Ah, that is correct, of which null is a unique value. My original point still stands though. Preventing null as an allowable value only adds complexity, and allowing null can be handled in a rational fashion as is demonstrated by new interfaces. -- --- 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/. --------------040806000801000106030406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 01/19/2014 03:37 PM, Alexander Bolz wrote:
Am Sonntag, 19. Januar 2014 20:00:43 UTC+1 schrieb Paul Tessier:
On 01/19/2014 12:44 PM, 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 <mi...@knejp.de <javascript:>>
>>> 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. =C2=A0So use
>> the following data members:
>>
>> =C2=A0 =C2=A0const charT * m_ptr;
>> =C2=A0 =C2=A0union {
>> =C2=A0 =C2=A0 =C2=A0 size_t m_len;
>> =C2=A0 =C2=A0 =C2=A0 charT m_nul;
>> =C2=A0 =C2=A0};
>>
>> and have the default constructor set m_ptr to &m_nul and m_len to 0. =C2=A0The
>> 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. =C2=A0There's no issu= e 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 =3D s1; imply that s2.data() =3D=3D 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.
>
> /MF
>

If s1 and s2 are empty, only access to the metadata is rational. Using
operator[], front(), back(), etc. will produce undefined behavior.
s1.data() and s2.data() are irrelevant because, it points to the
beginning of a range of zero length. =C2=A0One could just as easi= ly set
data() to null or some random value, when the string_view becomes empty
but, such actions are unneeded. =C2=A0The equality comparison is based on the
equality of the two ordered sets of characters from s1 and s2. =C2=A0All
empty views are equally empty and does not imply ( s2.data() =3D=3D
s1.data() ), just as ( s1 =3D=3D s2 ) does not imply that ( &s1 =3D=3D &s2 ).

If &s1 is deallocated and falls into a protected segment, any access to
it will trap, just like any other object. =C2=A0If both s1 and s2 where
referencing a string that was deallocated before they both became empty
then, both would trap, unless data() is randomized or set to some safe
location as I mentioned above but, this would be pointless as accessing
the referenced string of an empty view is undefined behavior.


To me the prevention of null being returned by data() is just an
artifact inherited from std::string. =C2=A0It seem like an early and
incomplete error check. =C2=A0You could also argue that all unreachable
segments be restricted.

If string_view was only a range of a std:string, forwarding all
std::string's warts through the interface would not be completely
unexpected. =C2=A0Especially when the wrapper is such a lightweig= ht class.
Yet, string_view serves a wider purpose therefore, those warts should
ignored. I argue that std::string's interface should be relaxed and, not
that string_view's be restricted.

Consider std::array< char, 0 >. =C2=A0It's data() will retu= rn null, and the
rest of it's members behave as rationally. =C2=A0

This is not correct. I just looked it up in N3797:
23.3.2.8. says "begin() =3D=3D end() =3D=3D unique value. The return value of data() is unspecified"
=C2=A0
I see no reason for
string_view not to behave in a similar fashion. =C2=A0While std:string may
never return null for it's data(), it is inconsequential as string_view
maybe constructed from other sources.

Having a is_null() seems excessive. data() should be allowed to be null,
as this seems the simplest solution. =C2=A0Following the behavior of
std::array< char, 0 > seems to solve many of the other problems in the
interface being unable to handle data() and begin() being null.

While string_view is modeled after std::string's interface, the newer
std::array interface seems more flexible and also solves the default
empty initialization problem. =C2=A0Besides, any object that behaves
rationally when zeroed out, say by memset, is a plus.


--
=C2=A0
---
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/.

Ah, that is correct, of which null is a unique value.=C2=A0 My original point still stands though.=C2=A0 Preventing null as an allowable value only adds complexity, and allowing null can be handled in a rational fashion as is demonstrated by new interfaces.

--
 
---
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>.
--------------040806000801000106030406-- .