220 8737 article Path: news.gmane.org!not-for-mail From: Alexander Bolz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Mon, 20 Jan 2014 04:15:16 -0800 (PST) Lines: 129 Approved: news@gmane.org Message-ID: 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> <60842af6-5ec4-4364-b2d5-a0be9d578bd6@isocpp.org> <6c82c4ae-c144-443a-81b2-ea1a6b645601@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1968_22086388.1390220116661" X-Trace: ger.gmane.org 1390220111 32569 80.91.229.3 (20 Jan 2014 12:15:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 12:15:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCAJPLFFWYPBBVNG6SLAKGQEAIKGN7Q@isocpp.org Mon Jan 20 13:15:18 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W5Dl8-00014i-D6 for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 13:15:18 +0100 Original-Received: by mail-qc0-f199.google.com with SMTP id m20sf11479068qcx.2 for ; Mon, 20 Jan 2014 04:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=PnsM9OoQehwWGg1Stvb1effrhOh2UgSRYD8Ve4600mQ=; b=cV2EvTwOqNNIpvKfB56GhzFz9X56gAf3YP9cq7Crq8aiiC6ZjeNQppJmOLe2V9gj3i 9Pfufsx3IQ0tETaupTgjJdGwQBmnHCdJ+X6AfXkNl+1ZH+QquDA5BwpZF0tyQO0Izdb7 zLiN5S+2zE9SvlXUMJcOJh9HDzmSMj/HrVvGEKyuwt9EMzJ0DF3UmJlWb8T2EBK048bi S47wfH9s11b51CjLpsY3hj5sqojmdhhSWlpljFWKYUIAq9wNkL8zzGpQ7vhsiTJQdtgD PbZv8rZhHnGXrF7vdR8mAriCgVdO9zOiw9U/BE5ki18zjhTpyWqTphAr+RebnSeS+Nwu TipQ== 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=PnsM9OoQehwWGg1Stvb1effrhOh2UgSRYD8Ve4600mQ=; b=gihm7T8PaTrBJg258jwuiaYeHMEmNO8AdavlkoHqjE7kLTKyfclgj59eLTS2B+nj9N NKq6ATmw5a/ZsVgp4N3UQgTleaIhyI4ZPHqEkDwI+GNHKU0jUGzh81hQ4/RJqcXsrC95 d1BeblBwrJXCfG+v8mt7KfwfIbC69MWja595KRX5Dk5dVO/pDP114hwUaHPMErjsLQz+ NyM+wLdpbw0GEKb/dFzoRFJp+b3l3GG3RDtNyj0eqPmBAnljBn+HrndKd2qNq1iupzNz Wli2gzqTTbjVjYSPTkeQ3npczfrScUF6YswMAGj6+q8LIJSdrbhaOb9DHVte0M/ZlC0i N0RA== X-Gm-Message-State: ALoCoQm9XH9aEGBgjF6Fve7PvfNG8gmSn+C5lGgq3aZ7fTQ8rpSWcVgF6fB1GjBWBZng8WRgfBO1 X-Received: by 10.58.145.233 with SMTP id sx9mr6720949veb.0.1390220117595; Mon, 20 Jan 2014 04:15:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.104.100 with SMTP id gd4ls291023qeb.77.gmail; Mon, 20 Jan 2014 04:15:17 -0800 (PST) X-Received: by 10.140.43.74 with SMTP id d68mr63065qga.8.1390220117155; Mon, 20 Jan 2014 04:15:17 -0800 (PST) In-Reply-To: X-Original-Sender: abolz.lists@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:8737 Archived-At: ------=_Part_1968_22086388.1390220116661 Content-Type: text/plain; charset=UTF-8 Please let me summarize why I think string_view should be constructible from a nullptr (and a zero length) and and data() should return the pointer passed to the constructor. Please, if I got anything wrong, let me know! I really don't understand the reason for data() != null. The only reason presented here that data() should always return non-null is that "nullptrs are bad". I'm not convinced. If there are other arguments, I really would like to hear them. Since it's not null terminated, string_view's data() is not a replacement for string's data() and since it might contain null characters, string's data() is not a replacement for C-strings. When using data() I have to be careful anyway. data() == null (which implies size() == 0) doesn't force the user to write additional null checks. The standard _explicitly_ allows nullptr + 0 and nullptr - nullptr. So if I use any standard algorithm like find, I can write find(sv.data(), sv.data() + sv.size(), 'x') or find(sv.begin(), sv.end(), 'x'). If a function f takes an iterator and and a length I could also write f(sv.begin(), sv.end() - sv.begin()). For all these algorithms using iterators, a null string_view is exactly the same as an empty string_view. Actually, allowing data() == null frees the user from performing null checks. So I think allowing data() == null makes working with C-strings more safe and working with std::string's more efficient. And of course I can directly use any other contiguous range of characters as a (sub-)string. And if there are situations where I need/want to know whether a string_view was constructed from a nullptr, I can get this information, too. This would not (directly) be possible if string_view were constructible from a nullptr, but the return value of data() is unspecified. It actually would introduce UB if I don't pay extra attention to this. void f(char const* ptr, size_t len) { auto s = string_view(ptr, len); // ... g(ptr, s.data() - ptr); } Summary: I pay for what I don't use: a non-null ptr. -- --- 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_1968_22086388.1390220116661 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please let me summarize why I think string_view shoul= d be constructible
from a nullptr (and a zero length) and and dat= a() should return the
pointer passed to the constructor. Please, = if I got anything wrong, let me
know! I really don't understand t= he reason for data() !=3D null.

The only reason pr= esented here that data() should always return non-null is
that "n= ullptrs are bad". I'm not convinced. If there are other arguments,
I really would like to hear them.

Since it's not= null terminated, string_view's data() is not a replacement
for s= tring's data() and since it might contain null characters, string's
data() is not a replacement for C-strings. When using data() I have to
be careful anyway.

data() =3D=3D null (wh= ich implies size() =3D=3D 0) doesn't force the user
to write addi= tional null checks. The standard _explicitly_ allows
nullptr + 0 = and nullptr - nullptr. So if I use any standard algorithm
like fi= nd, I can write

find(sv.data(), sv.data() + sv.size(), 'x')

=
or

find= (sv.begin(), sv.end(), 'x').

If a function = f takes an iterator and and a length I could also write

f(sv.begin(), sv.end() - sv.beg= in()).

For all these algorithms using itera= tors, a null string_view is exactly
the same as an empty string_v= iew.

Actually, allowing data() =3D=3D null frees t= he user from performing null checks.

So I think al= lowing data() =3D=3D null makes working with C-strings more safe
= and working with std::string's more efficient. And of course I can directly=
use any other contiguous range of characters as a (sub-)string.<= /div>

And if there are situations where I need/want to k= now whether a string_view
was constructed from a nullptr, I can g= et this information, too.

This would not (directly= ) be possible if string_view were constructible from
a nullptr, b= ut the return value of data() is unspecified. It actually
would i= ntroduce UB if I don't pay extra attention to this.

void f(char const* ptr, size_t len)=
{
=     auto s =3D string_view(= ptr, len);
  &n= bsp; // ...
  &= nbsp; g(ptr, s.data() - ptr);
}

Summary: I pay for what I don't= use: a non-null ptr.

--
 
---
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_1968_22086388.1390220116661-- .