220 33726 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view for fstream::open() Date: Wed, 9 Aug 2017 08:35:04 -0700 (PDT) Lines: 135 Approved: news@gmane.org Message-ID: References: <9f6c436a-852c-4665-bf9f-91415491cdec@isocpp.org> <9fedbad3-c6f6-4dbe-a215-814666c52c6b@isocpp.org> <8bff939d-098b-4797-85fc-bf286ab4423f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5524_1460263296.1502292904389" X-Trace: blaine.gmane.org 1502292914 25521 195.159.176.226 (9 Aug 2017 15:35:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Aug 2017 15:35:14 +0000 (UTC) Cc: bop@gmb.dk, olafvdspek@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBKOXVTGAKGQEYBUNHTA@isocpp.org Wed Aug 09 17:35:07 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f197.google.com ([209.85.216.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfT0f-00060m-8v for gclcip-std-proposals@m.gmane.org; Wed, 09 Aug 2017 17:35:01 +0200 Original-Received: by mail-qt0-f197.google.com with SMTP id t37sf31351851qtg.6 for ; Wed, 09 Aug 2017 08:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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; bh=sVc3oY5ER5a/IWx13sK/ztODnKtS7sRbnm80pS7cH1I=; b=TGw9Vnqilzg/sIMFw/6+kHcEplbIihBpAA4sK5s0/G4fI6/B32RetCEQbA0J6d5aUT OdzN2XgGmt6tpQVmoccB0fE+CuLevedxrvLhzgsffqInVIj1xc4aSLq8mrNm4lWU8k8A IEIvpI1Z5ZJ03ZKOmEPuB+fzNZ8ukkWYs47yTZcWoRf/TNxqYyr0/9VhPb0scCfG3eLb 3+vkeB8mtPDv1/OXR7Pr/apNpYT0fo2CKotzECGnlTrXTpZcSYsZP3tF8fX2CDdoTPHJ lkqmkAkHPKKlOlpBtYdblqP9BCKEOsm505Gnisg3XqanTSKb6y3iXbV7aXzhSgvdH0zG Pwzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=sVc3oY5ER5a/IWx13sK/ztODnKtS7sRbnm80pS7cH1I=; b=f2xHg/xfrxtrARFnLaPbDAMBzJwxEbTDx5sYSUUwi1Dsyh4hp73WbJJt1os+U0rlDy AEATwWylMJ2fvb+p5HBbH+5JZWUnKN0bnxeJPGsLC2vOiGZUCOkw+vY4Td4RenxEaw67 oyUAPYTXISaZtfB34MEznTR11Qy0VPhSs6NxYVJZHm4pCTCr0RpvdQAo1GGBEyfazokb dZQtuVxqYXlqhcJHButYZcoxATQDe0gFV8Njg3UnS85YeYE7wYLoICeN0TvaSDxD6uUE FCE5rEdmmsYFpJReUz1gf64zppBk8E8X215U6VzPhYlYFZ1l06G/LwWgylK1d7v9wPHm mpnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=sVc3oY5ER5a/IWx13sK/ztODnKtS7sRbnm80pS7cH1I=; b=pa7OwjXWX1k7uRYAe+JhW6uVSWboe6LE0kGCbcwYOv4LNfRaNLaZ3MYJfeukFFuFDz 5VCOTPSmSOZdLTzxPBG/b/cpXO+rLXWSoZphD7JeIx2wdxjiUQL8kbAs3Iu/ZpCgNL0Z GbQjQYp+or/ZZaO6p6wewf7XjrxjrxaeTs9Mcy9YfjjQxXWYmpkZYE6LjoXEq2SCck3i zXLPOR/UVbFpwZk9C791wLrNsltZSKjz8mY6e6BD+i4pmYbTqoO0cd9Dp4k+KZ8sW7Dc GPSLLN9P6Kg0e+5G09O8on57CcKsqMfkzBiltIbngDIj2knEZUGmUpFoTZhGqc7T0jYJ ypEg== X-Gm-Message-State: AHYfb5iCpqtFonhRDUSgpruIaXjKx4VPNgHT7Svcf3KNkXoAhc0cJxeB 0CJBmi2jz+skybKF X-Received: by 10.200.36.239 with SMTP id t44mr5207230qtt.39.1502292906380; Wed, 09 Aug 2017 08:35:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.8.136 with SMTP id h8ls72786ioi.20.gmail; Wed, 09 Aug 2017 08:35:04 -0700 (PDT) X-Received: by 10.31.169.17 with SMTP id s17mr43389vke.11.1502292904896; Wed, 09 Aug 2017 08:35:04 -0700 (PDT) In-Reply-To: <8bff939d-098b-4797-85fc-bf286ab4423f@isocpp.org> X-Original-Sender: jmckesson@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:33726 Archived-At: ------=_Part_5524_1460263296.1502292904389 Content-Type: multipart/alternative; boundary="----=_Part_5525_397010407.1502292904390" ------=_Part_5525_397010407.1502292904390 Content-Type: text/plain; charset="UTF-8" On Wednesday, August 9, 2017 at 5:35:12 AM UTC-4, olafv...@gmail.com wrote: > > Op dinsdag 8 augustus 2017 20:54:53 UTC+2 schreef Nicol Bolas: >> >> On Tuesday, August 8, 2017 at 2:16:24 PM UTC-4, Julian Watzinger wrote: >>> >>> Ah, I see. I definately agree on the notion that in this case, its >>> better that I create a copy myself. >>> >>> Is there any chance that low-level APIs will be moving away from >>> nul-terminated strings in the future? >>> >> >> I rather doubt it. It's hardly high on most people's priority lists. >> >> Having a lot of low-level functions require a nul-terminated string kind >>> of dampends the overall usefulness of string_view IMHO. >>> >> >> Which is why I wrote my own `zstring_view` class, which explicitly >> represents a view of a NUL-terminated string (it treats the NUL-terminator >> the same way `std::string` does; you can look at it, but it's not >> explicitly part of the `begin/end` range). It has some of the operations of >> `string_view` (thanks to inheritance), but it removes or alters the ones >> that subdivide from the end. For obvious reasons. >> >> At least from what I can tell after a few days worth of porting to >>> string_view - at first I though it would be a direct replacement for most >>> places where "const std::string&" was being used, but now it seems there's >>> a lot more consideration to be done, not to end up with more >>> temporaries/allocations than before. >>> >> >> You have exactly expressed why I wrote `zstring_view`. >> > > Any plans to propose it for standardization? > Not really. As useful as `zstring_view` certainly is, I do not like the idea of proliferating `string_view` types. The other problem is that there aren't very many APIs in the C++ parts of the standard that specifically need NUL-termination. Now, that being said, P0645 includes a `cstring_view` type , which is just a `const char*` for a NUL-terminated string. That is, it has no size, so `size` is linear. Personally, I think this is a horrible type and I hope it gets revised during standardization into something more like `zstring_view`. And that the system gets changed to one that can work based on an actual `string_view`. There's no excuse for making C++ APIs that depend on NUL-termiantion. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c63bfd77-b6b6-4b2f-ad3d-6d22210877ee%40isocpp.org. ------=_Part_5525_397010407.1502292904390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, August 9, 2017 at 5:35:12 AM UTC-4, olafv...= @gmail.com wrote:
Op dinsdag 8 augustus 2017 20:54:53 UTC+2 schreef Nicol Bolas:
On Tuesday, August 8, 2017 = at 2:16:24 PM UTC-4, Julian Watzinger wrote:
Ah, I see. I definately agree on the notion that = in this case, its better that I create a copy myself.

Is there any = chance that low-level APIs will be moving away from nul-terminated strings = in the future?

I rather doubt it. It's hardl= y high on most people's priority lists.

Having a lot of low-level functions= require a nul-terminated string kind of dampends the overall usefulness of= string_view IMHO.

Which is why I wrote my o= wn `zstring_view` class, which explicitly represents a view of a NUL-termin= ated string (it treats the NUL-terminator the same way `std::string` does; = you can look at it, but it's not explicitly part of the `begin/end` ran= ge). It has some of the operations of `string_view` (thanks to inheritance)= , but it removes or alters the ones that subdivide from the end. For obviou= s reasons.

At least from what I can tell after a few days worth of porting to st= ring_view - at first I though it would be a direct replacement for most pla= ces where "const std::string&" was being used, but now it see= ms there's a lot more consideration to be done, not to end up with more= temporaries/allocations than before.

You ha= ve exactly expressed why I wrote `zstring_view`.

Any plans to propose it for standardization?=C2=A0
<= /div>

Not really. As useful as `zstring_view` certainl= y is, I do not like the idea of proliferating `string_view` types. The othe= r problem is that there aren't very many APIs in the C++ parts of the s= tandard that specifically need NUL-termination.

Now, that being said= , P0645 includes a `cstring_view` type, which is just = a `const char*` for a NUL-terminated string. That is, it has no size, so `s= ize` is linear. Personally, I think this is a horrible type and I hope it g= ets revised during standardization into something more like `zstring_view`.= And that the system gets changed to one that can work based on an actual `= string_view`.

There's no excuse for making C++ APIs that depend = on NUL-termiantion.

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/c63bfd77-b6b6-4b2f-ad3d-6d22210877ee= %40isocpp.org.
------=_Part_5525_397010407.1502292904390-- ------=_Part_5524_1460263296.1502292904389-- .