220 33850 <8841975e-d2b4-49dd-8f31-f8d19bc0c56b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: string_view for fstream::open() Date: Fri, 11 Aug 2017 15:26:12 -0700 (PDT) Lines: 89 Approved: news@gmane.org Message-ID: <8841975e-d2b4-49dd-8f31-f8d19bc0c56b@isocpp.org> References: <25b20004-c1b3-4844-b957-ef57e043b533@isocpp.org> <1630708.cPAEmNVcRk@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2519_1998246755.1502490372455" X-Trace: blaine.gmane.org 1502490384 13087 195.159.176.226 (11 Aug 2017 22:26:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 11 Aug 2017 22:26:24 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBBO6XDGAKGQEFXDAOYI@isocpp.org Sat Aug 12 00:26:20 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dgINd-0002ZO-8S for gclcip-std-proposals@m.gmane.org; Sat, 12 Aug 2017 00:26:09 +0200 Original-Received: by mail-qk0-f198.google.com with SMTP id n196sf3778739qkn.7 for ; Fri, 11 Aug 2017 15:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=CYNU0Mp+bR7gJErlGN/lEQ2ZNOtT1gVjczrpHjIYKHI=; b=RCXMENmXSPPvR0vxEi6+JydFwFylS2Xy/Eaq3pmIO7SUqcFQIbW0a5Eliv9ww8S6Dr UnFAjzE+2JrDTNPw5fwdPYVC5PYh6WNMHgNwty5mvdm64YAD5r2odxI1EHqeEbHokUFA UOOjd9wr7ke6MRQ6IEbZHCqVe7PuKsFtSzMezGINS2e9Wi2bXf9Nh0xiw58LIh9NwsxV nSXe5LbYBVh3CDLpScR6siu+zXaBbWLPTyfMMT3Wmr+X4dgmPFZyMyya5QINeJ0QRJEy f3VfdKfepdc+FpBk0ysSL6hCXSfrXWNtOQUCPZHLB9QTg+DsY11WVijfiLFocORC/upX GwDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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; bh=CYNU0Mp+bR7gJErlGN/lEQ2ZNOtT1gVjczrpHjIYKHI=; b=T63ecIZNB0j02J6ETASBBF1DeAruhxuOGIztITJcwQvbSRcH4q3k+uj6FienHuKXcv 1fo5QWtf3SpKPS0e+EnP7pku3O1Ky74dhzDRwVE4vkyYU+aPIMRI/jsn9IYNBrZTK+nO ztepYfWn1PPnKl7wrL7aAxyjhylCR6r+d6fgnw+R4wRCG2+VfoS/JzC/gdcqZLLs9s1b hQ1aW8W3PPbkn3DOwJDSeY8ShgevfD1U5to/tZ+O6qeCxEA+VJQM/tkbJAKWY+qR+Ydn cJdcVjJaBQjDeLkPKMA5oT2TeV9ibWeHd7zKQSMIsRKeBRXDDMDVu9azmtVNSdl++kmJ AW/A== 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: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=CYNU0Mp+bR7gJErlGN/lEQ2ZNOtT1gVjczrpHjIYKHI=; b=QnY79JmbzrCHMPL4l2q9f23KcolJ4KJW1Q5LAgcrCkwkMmNCxg8V3Jeg9vUPZMLzGz 607dHRBz16kt4MnojuOr2jSD0MGLvAMEwQvku8RedQAoPBgMGfUNVt6WtaeZ5Ws3y3RT 1MgSuOdcGAvB9Dw2v42++/H5//YAgFcJRSggDjGjpWJG4uljhRO7aJbGAGXufmHKGwkW BQe7y3T6U+oV4ruz7uzrEfIwC3dR+X7LPJhN/Bkj91slbGpBrHxDlcJsA/gYru1kqYpr EJ2W7Wabe2aKumpRrormaDE0XA/JQe40jvN9xJyrnLLNgB9N1I7fivLB9w0x87J4dJ0J jfoQ== X-Gm-Message-State: AHYfb5jDxyYgFkyIS3s8mE/+EFKEoGvCzz5tDXAeFC6FzjzImXZvMnkj g3JV8CyQUwCGvmKF X-Received: by 10.200.3.39 with SMTP id q39mr11089777qtg.121.1502490374258; Fri, 11 Aug 2017 15:26:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.143.132 with SMTP id r126ls1989718iod.10.gmail; Fri, 11 Aug 2017 15:26:13 -0700 (PDT) X-Received: by 10.31.191.67 with SMTP id p64mr90196vkf.4.1502490373006; Fri, 11 Aug 2017 15:26:13 -0700 (PDT) In-Reply-To: <1630708.cPAEmNVcRk@tjmaciei-mobl1> X-Original-Sender: nialldouglas14@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:33850 Archived-At: ------=_Part_2519_1998246755.1502490372455 Content-Type: multipart/alternative; boundary="----=_Part_2520_1931980374.1502490372455" ------=_Part_2520_1931980374.1502490372455 Content-Type: text/plain; charset="UTF-8" > > > > The path_view::c_str structure is a PATH_MAX sized structure with > > additional buffer and length values. If the source view is zero > terminated, > > that is used directly. If it is not, it is copied into the c_str and > zero > > terminated. If on Windows and the underlying view source is UTF-8, a > > conversion to UTF-16 is done. It is perfectly minimum overhead, no > malloc > > anywwhere, and can be used by end users identically on Windows and > POSIX, > > no #ifdefing. > > So you're saying that it uses 64kB of stack on Windows? > For now yes. And 32Kb on Linux and 1Kb on FreeBSD as those are their PATH_MAX. If it turns out to be a problem down the line, we could shrink to 4Kb and use malloc if the input path is longer than that. For now I haven't encountered a problem, generally if you're calling a path consuming syscall, this is not an overhead. Niall -- 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/8841975e-d2b4-49dd-8f31-f8d19bc0c56b%40isocpp.org. ------=_Part_2520_1931980374.1502490372455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> The = path_view::c_str structure is a PATH_MAX sized structure with
> additional buffer and length values. If the source view is zero te= rminated,
> that is used directly. If it is not, it is copied into the c_str a= nd zero
> terminated. If on Windows and the underlying view source is UTF-8,= a
> conversion to UTF-16 is done. It is perfectly minimum overhead, no= malloc
> anywwhere, and can be used by end users identically on Windows and= POSIX,
> no #ifdefing.

So you're saying that it uses 64kB of stack on Windows?

For now yes. And 32Kb on Linux and 1Kb on = FreeBSD as those are their PATH_MAX.

If it turns o= ut to be a problem down the line, we could shrink to 4Kb and use malloc if = the input path is longer than that. For now I haven't encountered a pro= blem, generally if you're calling a path consuming syscall, this is not= an overhead.

Niall

--
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/8841975e-d2b4-49dd-8f31-f8d19bc0c56b= %40isocpp.org.
------=_Part_2520_1931980374.1502490372455-- ------=_Part_2519_1998246755.1502490372455-- .