220 13561 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Some safety for C: add array_view overloads for snprintf() and others Date: Fri, 3 Oct 2014 00:45:26 +0800 Lines: 152 Approved: news@gmane.org Message-ID: References: <6cbdd555-44e4-4049-8558-6dc76911b388@isocpp.org> <3A51FA56-6D21-49AD-8379-FC185D2E20A9@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_D4C336AA-78C3-41A9-98C5-C7EECFD16F55" X-Trace: ger.gmane.org 1412268353 20826 80.91.229.3 (2 Oct 2014 16:45:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 16:45:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBN4CW2QQKGQEWJV44GA@isocpp.org Thu Oct 02 18:45:46 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZjVh-0005EF-2K for gclcip-std-proposals@m.gmane.org; Thu, 02 Oct 2014 18:45:45 +0200 Original-Received: by mail-ig0-f200.google.com with SMTP id h15sf10628767igd.11 for ; Thu, 02 Oct 2014 09:45:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to: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; bh=xUJQOexVnBnTAvsi3h133WJ6/DfuBpcnCB06zySQmsw=; b=TGUzC49I7w3nfWlKMQjUm3B045NFwQXFS3KXT4v7Dhzh5y5CPodfaBxxuDDbPJMEOG 2i69p08mrBdXrLgmX0rSefOlzO6glFshjkVa9pKQywnI+i5wF7e1ws4GTq6Ll3v/CCMk J04pUhcx6PildfqANLirgVzNnN5w1pzPtRO6bYbXXkkQhP4Yuq9w9lH9Q9HzmUBqBDsr 08euaZTnbye69RJSwiwK4NcKZunWYdV4JJI0Tn+owIPYixbUx8uKvObo4C1xOeDSoD5F n+hB0yEzlRQYoKYoh/kvPNsGT+qGXo0sRfuIL7kniZ7Hxu2ej/OHuv3GJWvFTmsOcDBJ dDzQ== X-Gm-Message-State: ALoCoQn8Vf8iukSwVD/inCF+lj8PLrf5LR50SuAeW/YrnRpXi26spdFw8Izpuwz0mZwLxILSY0Xi X-Received: by 10.182.45.162 with SMTP id o2mr84141obm.20.1412268343947; Thu, 02 Oct 2014 09:45:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.43.162 with SMTP id x2ls435344igl.38.gmail; Thu, 02 Oct 2014 09:45:43 -0700 (PDT) X-Received: by 10.66.160.65 with SMTP id xi1mr88644239pab.123.1412268343261; Thu, 02 Oct 2014 09:45:43 -0700 (PDT) Original-Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [2607:f8b0:400e:c03::230]) by mx.google.com with ESMTPS id pw4si4575283pbb.98.2014.10.02.09.45.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 09:45:43 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::230 as permitted sender) client-ip=2607:f8b0:400e:c03::230; Original-Received: by mail-pa0-f48.google.com with SMTP id eu11so2841170pac.7 for ; Thu, 02 Oct 2014 09:45:43 -0700 (PDT) X-Received: by 10.68.68.131 with SMTP id w3mr51509293pbt.93.1412268343107; Thu, 02 Oct 2014 09:45:43 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.128]) by mx.google.com with ESMTPSA id xf9sm4249652pab.2.2014.10.02.09.45.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 09:45:42 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::230 as permitted sender) smtp.mail=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:13561 Archived-At: --Apple-Mail=_D4C336AA-78C3-41A9-98C5-C7EECFD16F55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-10-02, at 10:19 PM, Matthew Fioravante wro= te: > Generic backend (fixed buffer, dynamic buffer, file, IPC, network socket,= etc..) implemented efficiently! (that is no returning copies of std::strin= g etc..) Networking libraries are a very active area of development, and it's also t= he kind of I/O with the most stringent requirements. They can be a good sta= rting point. I started a generic networking library, but it's on hold right= now. > Somehow support atomic messages which don't get interleaved across multip= le threads sharing a stream. I don't think that belongs in the I/O library any more than it belongs in t= he containers library. The threads simply need to share a mutex. Associatin= g a mutex with a stream is the programmer's job. > Global locale setting using dynamic dispatch > Static locale setting which can be inlined (the global locale thing destr= oys performance) This comes down to a better mechanism for named locales, and the first step= toward that is to sync with the relevant ISO standards to determine what t= hose are and what they should do. > A variadic printf() style formatting library built on top of the underlyi= ng stream library > Should be type safe > Watch out for long compile times or too much code generation! > Must be as efficient as C printf! C printf efficiency is overrated. Also, such a library can probably exist o= utside the standard, in something like Boost, if it's redundant with a more= modern interface. > Parsing libraries (csv, html, json, etc..)=20 Likewise, these should be external components. There could be a follow-on T= S. > For buffered files, parsing routines (such as finding a newline) which op= erate on and return string_view(s) to the internal buffer without making a = copy. I have my own file parsing classes which do this and the performance = difference matters big time. That would require the entire returned string to fit inside the buffer. Als= o it requires the buffer to be in the application's text encoding, as oppos= ed to the raw file/wire encoding which is essential for operation as an I/O= buffer. While there are benefits, it might be better to allow the user to = hook (or hack) directly into the buffer than to provide a parser-style inte= rface. This is already the status quo with std::filebuf, which is singularl= y the least broken part of iostreams. --=20 ---=20 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 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-proposa= ls/. --Apple-Mail=_D4C336AA-78C3-41A9-98C5-C7EECFD16F55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 2014&= ndash;10–02, at 10:19 PM, Matthew Fioravante <fmatthew5876@gmail.com> wrote:

  • Generic backend (fixed buffer, dynamic buffer, file, IPC, network = socket, etc..) implemented efficiently! (that is no returning copies of std= ::string etc..)
Networking libraries are a very = active area of development, and it’s also the kind of I/O with the mo= st stringent requirements. They can be a good starting point. I started a g= eneric networking library, but it’s on hold right now.
  • Somehow support atomic messages= which don't get interleaved across multiple threads sharing a stream.
    <= /li>
I don’t think that belongs in the I/O library a= ny more than it belongs in the containers library. The threads simply need = to share a mutex. Associating a mutex with a stream is the programmer&rsquo= ;s job.
  • Global loca= le setting using dynamic dispatch
  • Static locale setting which can b= e inlined (the global locale thing destroys performance)
This comes down to a better mechanism for named locales, and the fi= rst step toward that is to sync with the relevant ISO standards to determin= e what those are and what they should do.
  • A variadic printf() style formatting library built o= n top of the underlying stream library
    • Should be type safe
      • =
    • Watch out for long compile times or too much code generation!
    • <= b>Must be as efficient as C printf!
C pr= intf efficiency is overrated. Also, such a library can probably exist outsi= de the standard, in something like Boost, if it’s redundant with a mo= re modern interface.
    Parsing libraries (csv, html, json, etc..) 
Likewise, these should be ex= ternal components. There could be a follow-on TS.
  • For buffered files, parsing routines (such a= s finding a newline) which operate on and return string_view(s) to the inte= rnal buffer without making a copy. I have my own file parsing classes which= do this and the performance difference matters big time.
That would require the entire returned string to fit inside the = buffer. Also it requires the buffer to be in the application’s text e= ncoding, as opposed to the raw file/wire encoding which is essential for op= eration as an I/O buffer. While there are benefits, it might be better to a= llow the user to hook (or hack) directly into the buffer than to provide a = parser-style interface. This is already the status quo with std::filebuf, which is singularly the least broken part of i= ostreams.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--Apple-Mail=_D4C336AA-78C3-41A9-98C5-C7EECFD16F55-- .