220 8686 <11f13f8f-1270-427c-8942-94027a181ff4@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 07:55:32 -0800 (PST) Lines: 117 Approved: news@gmane.org Message-ID: <11f13f8f-1270-427c-8942-94027a181ff4@isocpp.org> References: <8045a4d2-721d-4725-8bb7-7a91b6f53ec8@isocpp.org> <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> <7aad44d8-6b4e-438a-b309-bd898b994b34@isocpp.org> <9C2C439F-7983-4224-B272-53CAD0E2E456@gmail.com> <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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_479_22096632.1390146932193" X-Trace: ger.gmane.org 1390146928 25850 80.91.229.3 (19 Jan 2014 15:55:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 15:55:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA3LUEAQACBB5PK56LAKGQEHJTLZPI@isocpp.org Sun Jan 19 16:55:35 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f72.google.com ([209.85.219.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4uil-00028q-6L for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 16:55:35 +0100 Original-Received: by mail-oa0-f72.google.com with SMTP id o6sf24426312oag.11 for ; Sun, 19 Jan 2014 07:55: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=vnA0EDeEo7H9yTQ2Q6qGit0+fWFNqmc2hCY6UZK3s6w=; b=CXVdycbh+Nqlk/aSDmOuQzxQlBlZC5ykrgkwvTk7SRgVh22SZ46voscwmtzt9S3aXi nyI9zaBKp0m4ID3iTi2eE7JgeQiOw2/vO7mgXvb2sI5ZPHeEJusJqAjdxMUnsTV9ZzqN Mw5wfAnguJ0qhJWPLny5xEb7av9W6/xNsWK6tA96sSf72UjfxjRaPXaEDJgZedqt9B2G ReDzzQKQ0gZ80pw9GPF/T8GvbA8na3KgpivjMIoxrdMHRfXIM6la5MFOG7DxLrAbQfR3 jDtT9GWi1O8E8C8GH3r8oARQGRzHSkraTcQE9XsD0Ebj3wedUusKZFtT/I2ZPonydm7u cNpg== X-Gm-Message-State: ALoCoQmM1rvrTTeK7f0EM6wCyWjBMN4GEPlVGfn4zdBW18HTXZNuNSHxsQe7pvCUxACMksZUelnk X-Received: by 10.182.98.230 with SMTP id el6mr5029608obb.10.1390146934204; Sun, 19 Jan 2014 07:55:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.80.230 with SMTP id u6ls876481obx.86.gmail; Sun, 19 Jan 2014 07:55:32 -0800 (PST) X-Received: by 10.182.47.161 with SMTP id e1mr16126obn.24.1390146932885; Sun, 19 Jan 2014 07:55:32 -0800 (PST) In-Reply-To: <1B534FD7-B385-4A7E-A718-3C73F0AB61DC@gmail.com> 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:8686 Archived-At: ------=_Part_479_22096632.1390146932193 Content-Type: text/plain; charset=UTF-8 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). 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_479_22096632.1390146932193 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, January 17, 2014 10:19:07 PM UTC-6, Marshall wr= ote:
On Jan 17, 2014, at 6:13 P= M, Miro Knejp <mi...@knejp.de&g= t; wrote:

>>=20
>> - both of these methods are impossible if the presumptions sta= ted above "begin() should never return nullptr" and "we don't need a specia= l is_null()". Well, not entirely. Of course you could create some bogus obj= ect and use its address instead of nullptr.
>>=20
> 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 implement= ations will put in the code segment) for each default constructed string_vi= ew (yes, some implementations will merge them together in the same translat= ion 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-de= fined:

Nothing in the current spec requires that the data() function= return the same value for distinct default-constructed string_view instanc= es.  So use the following data members:

  const charT * m_= ptr;
  union {
     size_t m_len;
 &= nbsp;   charT m_nul;
  };

and have the default con= structor set m_ptr to &m_nul and m_len to 0.  The result is a (uni= que) empty string reference.

I've tested this by modifying Boost's i= mplementation and it works fine.  Note that only the m_len data member= is actually used and is always zero for the default-constructed value.&nbs= p; There's no issue about accessing the other union member because when siz= e() 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).

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>.
------=_Part_479_22096632.1390146932193-- .