220 13492 article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Some safety for C: add array_view overloads for snprintf() and others Date: Thu, 2 Oct 2014 01:23:14 -0700 (PDT) Lines: 258 Approved: news@gmane.org Message-ID: References: <6cbdd555-44e4-4049-8558-6dc76911b388@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_425_2093090180.1412238194540" X-Trace: ger.gmane.org 1412238202 8955 80.91.229.3 (2 Oct 2014 08:23:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 08:23:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKLT4PURQHRB5EWWSQQKGQETF67D6A@isocpp.org Thu Oct 02 10:23:18 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZbfS-0005kf-7r for gclcip-std-proposals@m.gmane.org; Thu, 02 Oct 2014 10:23:18 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id et14sf9990117pad.1 for ; Thu, 02 Oct 2014 01:23:16 -0700 (PDT) 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=wwAhPpfxx1tOUtQy5oMdJ1WXryK4+RD872SQtbIqBp0=; b=RBFXgsKq6YIp3NJ4NVAVSxaHJqm18vUBDp45kMtJRFZaUx4GAMJhFdz8x4RAthjl9i azri5hGClai1FG65/CNgRnovDHodldiL0Tt1v3EbfPY0cRFtOeOHGn4ChQs1L5ZhYH4P N9FF2MSvPj4ElmhStF5XK5RkmJX+8rSPEB+CeeaScOvMQsKaS2/hKCbsWgUJ6C6Xyxww D3MZjQz1P43pjyhSMqEPmDeoA3cVyE8AVL+INWv8bY50NOy+piw2Xo/paH5aCHOLi/fv bQ4dfarNLvwcZSDmO0N4oFMKJSAsfQkZSthzUFnMorMwrcMuF/02XrW6PGzyyxHcCCFd 4cUg== 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=wwAhPpfxx1tOUtQy5oMdJ1WXryK4+RD872SQtbIqBp0=; b=F3zdkcGzAB1NrhBOtxHe/KHbdq0ynUhZzjMxEtfDNXPdWMyeFiG2NQgFddjbwGhxpm NnGc8R+wJ0J+fu1adVMbkuyJmSc/5mSCNJ/BC8tcKNq6JnUHw+m526UqFXqHkz39Rmsg bCRkl7oxOb9wE2yJX+mbeKOA+yBDZ6lbAUZn79XJU3mEvL32KXYFmQnyWCBbKkT8ZhAT sZFbf/+BdTvq7tReIs/ESu4veMMh/G/BPdV8QnaofU4LD5bazjQg6/mMuLgzT81Cm0ta ho/0TqK/70qflasvqOpXxmAwyH8ZeMZGpQlLQ45UfI/b8myG9/bH09rNHeTfjGfCxkt8 Q6jw== X-Gm-Message-State: ALoCoQnDZX8Jxspj/80+8Spx+Ilh4xy4pC0jHD7BUlD8JQUP2dGd2gz/Ys+ZTYEjOPp0RGPh1bHy X-Received: by 10.66.227.135 with SMTP id sa7mr50444566pac.19.1412238196951; Thu, 02 Oct 2014 01:23:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.30.170 with SMTP id t10ls172474igh.18.canary; Thu, 02 Oct 2014 01:23:16 -0700 (PDT) X-Received: by 10.50.73.165 with SMTP id m5mr22292igv.14.1412238196330; Thu, 02 Oct 2014 01:23:16 -0700 (PDT) In-Reply-To: X-Original-Sender: myriachan@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:13492 Archived-At: ------=_Part_425_2093090180.1412238194540 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 1, 2014 10:37:39 AM UTC-7, Matthew Fioravante wrote: > > This idea is inspired by these blog posts and also my personal experience: > > http://randomascii.wordpress.com/2014/09/24/a-crash-of-great-opportunity/ > http://randomascii.wordpress.com/2013/04/03/stop-using-strncpy-already/ > > Despite personal opinions or religous convictions about iostream vs > printf, many of us still use snprintf() to efficently format some data to a > buffer without allocating memory and using the handy printf syntax. Until a > uniform replacement for printf and iostream is found (may never happen!), > many of us will continue using snprintf. > > On Wednesday, October 1, 2014 10:04:11 PM UTC-7, Matthew Fioravante wrote: > Added some example header files here: > > https://github.com/fmatthew5876/stdcxx-safec/tree/master/include > > > I'm a fan of ...printf, but would love it to come into this...well, millennium. We have variadic templates and constexpr now. Not only can its buffer overflow problems be solved as above, but its type-safety and extendability problems can be solved, too. There's nothing really stopping us from having a %v format specifier that means to call std::printf_handler(const T &, const std::printf_parameters &) if it exists, and fall back to std::operator <<(std::ostream &, const T &), T::c_str() const or T::operator const char *() const if it doesn't. I understand that there are certain things about iostream that are better, but there are also things about ...printf that are better. You can't really beat iostream's direct calls to output types as opposed to ...printf needing to parse a string at runtime (something partly fixable with constexpr and variadic templates). But you also can't compare how succinct std::printf("%06X", num); is to the cout alternative. It's also a matter of preference. There are people who use Visual Studio here at my employer who install a mod that makes its editor commands work like vim's. Regarding your cstdio.hh: Your fread/fwrite could be more flexible, I suppose. Perhaps: template inline size_t fread(enable_if_t::value, array_view> buf, FILE * stream) { return fread(buf.data(), sizeof(*buf.data()), buf.size(), stream); } Why array_view, though? I mean, there's always been this sort of design: template inline int vsnprintf(char (&buf)[S], const char *format, va_list args) { return vsnprintf(buf, S, format, args); } Melissa -- --- 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_425_2093090180.1412238194540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 1, 2014 10:37:39 AM UTC-7, Matthew F= ioravante wrote:
This idea is inspired by these blog posts and also my personal experienc= e:

http://randomascii.wordpress.co= m/2014/09/24/a-crash-of-great-opportunity/
http://randomascii.wordpress.com/2013/04/03/stop-using-str= ncpy-already/

Despite personal opinions or religous convictions about iostream vs printf,=20 many of us still use snprintf() to efficently format some data to a=20 buffer without allocating memory and using the handy printf syntax.=20 Until a uniform replacement for printf and iostream is found (may never=20 happen!), many of us will continue using snprintf.

 On Wednesday, October 1, 2014 10:04:11 PM UTC-7, Matthew Fiora= vante wrote:
=

I'm a fan of ...constexpr now.  Not only can its buffer overflow pr= oblems be solved as above, but its type-safety and extendability problems c= an be solved, too.

There's nothing really stopping us from having a = %v format specif= ier that means to call = std::printf_handler(const T &, const std::printf_parameters &) if it exists, and fall back to std::operator <<(std::ostream &, const T &)= , T::c_str() const or T::operator const= char *() const if it doesn't.

I understand that there are ce= rtain things about iost= ream that are better, but there are also things about ...printf that are better.&nbs= p; You can't really beat printf needing to parse a= string at runtime (something partly fixable with constexpr and variadic templates).  = But you also can't compare how succinct std::printf("%06X", num); is to the cout alternative.

It's a= lso a matter of preference.  There are people who use Visual Studio he= re at my employer who install a mod that makes its editor commands work lik= e vim's.

Regarding your cstdio.hh: Your fread/fwrite could be more flexible, I suppose.  Perhap= s:

te= mplate <typename T>
inline size_t fread(enable_if_t<is_pod<T>::val= ue,= array_view<T>> buf, FILE *stream)
{
  &n= bsp; retur= n fread(buf.data(), sizeof(*buf.data<= span style=3D"color: #660;" class=3D"styled-by-prettify">()), buf.size(), stream);
}

Why array_view, though?  I mean, there's always bee= n this sort of design:

template <std::size_t S>
inline int vsnprintf(char (&b= uf)[S], const char *forma= t,<= span style=3D"color: #000;" class=3D"styled-by-prettify"> va_list args)
{
    return vsnprintf(buf, S, format,<= /span> args);
}

Mel= issa

--

---
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>.
------=_Part_425_2093090180.1412238194540-- .