220 8690 <20140119174431.GA16875@faust.lysator.liu.se> article Path: news.gmane.org!not-for-mail From: Magnus Fromreide Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Sun, 19 Jan 2014 18:44:34 +0100 Lines: 64 Approved: news@gmane.org Message-ID: <20140119174431.GA16875@faust.lysator.liu.se> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1390153473 29819 80.91.229.3 (19 Jan 2014 17:44:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 17:44:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELLREETMBRBBM66CLAKGQEK3ECIBA@isocpp.org Sun Jan 19 18:44:41 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4wQI-0002zI-HY for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 18:44:38 +0100 Original-Received: by mail-wg0-f72.google.com with SMTP id y10sf10157168wgg.7 for ; Sun, 19 Jan 2014 09:44:38 -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:subject:message-id:mail-followup-to :references:mime-version:in-reply-to:user-agent: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:content-disposition; bh=m7X4tuNLTFqwxZO2PRoIkKWamNCAqc3oifv+MkXhYhE=; b=S1HFzxddYvZ4MtYVpSvXlZPHMtj2STuZwie6cuE9EuaR2rnncznP1/Y+LKI7GCf1RM TTjN7qlDcOwNTv0gV4ZjE4uMoCs7C8Ybva2au8k7fAvVUExJPAfebhQpgRYVyRNBB2Tt DeYByK71Z7WYo7AAXfPi0TUv7igFPXy2e4JfDDSabkZoXHVAvRnVD8I1Prvi+HM/IAYS Pk9UNETRxnMpBzyqyJMy2F4Ip0U97nEVU2nteHlLXjL6RdgGbA7VLZviG9nOUv81XUkH yzaKMp1bS2eiSg/sM1E5hPvsHmdDShXN033PBd8Go4nVJW3Z6/UZU2F9uaKTUocYoyBk X-Gm-Message-State: ALoCoQkRs0ydD4cA13DCEPmSFXIs+ZsfHTZovizRqrACqddh6Aj8BNqA+nGqIl47tawz5f1x9beA X-Received: by 10.112.161.197 with SMTP id xu5mr6300693lbb.7.1390153478054; Sun, 19 Jan 2014 09:44:38 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.92.168 with SMTP id cn8ls372408wib.16.canary; Sun, 19 Jan 2014 09:44:36 -0800 (PST) X-Received: by 10.204.53.75 with SMTP id l11mr1556246bkg.35.1390153476133; Sun, 19 Jan 2014 09:44:36 -0800 (PST) Original-Received: from mail.lysator.liu.se (mail.lysator.liu.se. [2001:6b0:17:f0a0::3]) by mx.google.com with ESMTPS id j9si13002113bki.52.2014.01.19.09.44.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jan 2014 09:44:35 -0800 (PST) Received-SPF: pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) client-ip=2001:6b0:17:f0a0::3; Original-Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 66BB54001F for ; Sun, 19 Jan 2014 18:44:35 +0100 (CET) Original-Received: from faust.lysator.liu.se (faust.lysator.liu.se [IPv6:2001:6b0:17:f0a0::d3]) by mail.lysator.liu.se (Postfix) with SMTP id 59E3140014 for ; Sun, 19 Jan 2014 18:44:34 +0100 (CET) Original-Received: by faust.lysator.liu.se (sSMTP sendmail emulation); Sun, 19 Jan 2014 18:44:34 +0100 Mail-Followup-To: std-proposals@isocpp.org In-Reply-To: <11f13f8f-1270-427c-8942-94027a181ff4@isocpp.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP X-Original-Sender: magfr@lysator.liu.se X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mail=magfr@lysator.liu.se 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: , Content-Disposition: inline Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8690 Archived-At: 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 -- --- 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/. .