------=_Part_4480_859105578.1412185059325
Content-Type: text/plain; charset=UTF-8

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.

The problem with snprintf() is that you have to specify the size separately
from the buffer. Its very easy to make mistakes:

char buf[4096];
snprintf(buf, sizeof(buf), "Hello World"); //Ok

wchar_t wbuf[4096];
swprintf(wbuf, sizeof(wbuf), "Hello World"); //Ops!
swprintf(wbuf, sizeof(wbuf) / sizeof(wchar_t), "Hello World"); //Correct,
but awful

We have a solution for this stupidity now, that solution is
std::array_view. Not only does it correctly store the size as an invariant
of the type, but it also directly works with C arrays, std::array,
std::vector, std::string, etc..

So how about we add some simple overload wrappers to the popular C
functions which take a pointer and length pair?


inline int snprintf(std::array_view<char> buf, const char* fmt, ...) {
  va_list va;
  va_start(va, fmt);
  int rc = vsnprintf(buf.data(), buf.size(), fmt, va);
  va_end(va);
  return rc;
}

inline int swprintf(std::array_view<wchar_t> buf, const wchar_t* fmt, ...);
inline size_t strftime(std::array_view<char> buf, const char* fmt, std::tm*
time);


--

---
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_4480_859105578.1412185059325
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This idea is inspired by these blog posts and also my pers=
onal experience:<br><br>http://randomascii.wordpress.com/2014/09/24/a-crash=
-of-great-opportunity/<br>http://randomascii.wordpress.com/2013/04/03/stop-=
using-strncpy-already/<br><br>Despite personal opinions or religous convict=
ions about iostream vs printf, many of us still use snprintf() to efficentl=
y format some data to a buffer without allocating memory and using the hand=
y printf syntax. Until a uniform replacement for printf and iostream is fou=
nd (may never happen!), many of us will continue using snprintf.<br><br>The=
 problem with snprintf() is that you have to specify the size separately fr=
om the buffer. Its very easy to make mistakes:<br><br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> buf</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D=
"styled-by-prettify">4096</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">];</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>snprintf</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
buf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">buf</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"Hello World"</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//Ok</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">wchar_t=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> wbuf</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">4096</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>swprintf</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">wbuf</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">wbuf<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"Hello World"</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">//Ops!</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>swprintf</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">wbuf</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
sizeof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">wbuf</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">/</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">wchar_t</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #080;" class=3D"styled-by-prettify">"Hello World"=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">//Correct, but awful</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div>=
</code></div><br>We have a solution for this stupidity now, that solution i=
s std::array_view. Not only does it correctly store the size as an invarian=
t of the type, but it also directly works with C arrays, std::array, std::v=
ector, std::string, etc..<br><br>So how about we add some simple overload w=
rappers to the popular C functions which take a pointer and length pair?<br=
><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">inline</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> snprintf</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">array_view</span><span style=3D"color: #080;" class=3D"sty=
led-by-prettify">&lt;char&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> buf</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> fmt</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">...)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; va_list va</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; va_start</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">va</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> fmt</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> rc </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> vsnprintf</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">buf</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">data<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> buf</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> fmt</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> va</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; va_end</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">va=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> rc</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">inline</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> swprintf</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">array_view</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&lt;wchar_t&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> buf</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">wchar_t</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> fmt</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">...);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">inline</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> size_t strftime</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">array_view</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">&lt;char&gt;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> buf</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> fmt</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">tm</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> time</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></div></code></div><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4480_859105578.1412185059325--

.

------=_Part_2391_1268934644.1412226251586
Content-Type: text/plain; charset=UTF-8

Added some example header files here:

https://github.com/fmatthew5876/stdcxx-safec/tree/master/include

--

---
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_2391_1268934644.1412226251586
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Added some example header files here:<div><br></div><div>https://github.com/fmatthew5876/stdcxx-safec/tree/master/include</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_2391_1268934644.1412226251586--

.

------=_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
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-safec%2Ftree%2Fmaster%2Finclude&sa=D&sntz=1&usg=AFQjCNEggz_KC5cXpBXOLxGcUO-pvU4CVg>
>
>
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 <typename T>
inline size_t fread(enable_if_t<is_pod<T>::value, array_view<T>> 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 <std::size_t S>
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

<div dir=3D"ltr">On Wednesday, October 1, 2014 10:37:39 AM UTC-7, Matthew F=
ioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">This idea is inspired by these blog posts and also my personal experienc=
e:<br><br><a href=3D"http://randomascii.wordpress.com/2014/09/24/a-crash-of=
-great-opportunity/" target=3D"_blank">http://randomascii.wordpress.<wbr>co=
m/2014/09/24/a-crash-of-<wbr>great-opportunity/</a><br><a href=3D"http://ra=
ndomascii.wordpress.com/2013/04/03/stop-using-strncpy-already/" target=3D"_=
blank">http://randomascii.wordpress.<wbr>com/2013/04/03/stop-using-<wbr>str=
ncpy-already/</a><br><br>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.<br><br></div></blockquot=
e><div>&nbsp;On Wednesday, October 1, 2014 10:04:11 PM UTC-7, Matthew Fiora=
vante wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Added some example header files here:<div><br></div><div><a href=3D"ht=
tps://www.google.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdc=
xx-safec%2Ftree%2Fmaster%2Finclude&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCN=
Eggz_KC5cXpBXOLxGcUO-pvU4CVg" target=3D"_blank" onmousedown=3D"this.href=3D=
'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fs=
tdcxx-safec%2Ftree%2Fmaster%2Finclude\46sa\75D\46sntz\0751\46usg\75AFQjCNEg=
gz_KC5cXpBXOLxGcUO-pvU4CVg';return true;" onclick=3D"this.href=3D'https://w=
ww.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-safe=
c%2Ftree%2Fmaster%2Finclude\46sa\75D\46sntz\0751\46usg\75AFQjCNEggz_KC5cXpB=
XOLxGcUO-pvU4CVg';return true;">https://github.com/<wbr>fmatthew5876/stdcxx=
-safec/<wbr>tree/master/include</a></div><div><br></div></div></blockquote>=
<div><br>I'm a fan of ...<span style=3D"font-family: courier new,monospace;=
">printf</span>, but would love it to come into this...well, millennium.&nb=
sp; We have variadic templates and <span style=3D"font-family: courier new,=
monospace;">constexpr</span> now.&nbsp; Not only can its buffer overflow pr=
oblems be solved as above, but its type-safety and extendability problems c=
an be solved, too.<br><br>There's nothing really stopping us from having a =
<span style=3D"font-family: courier new,monospace;">%v</span> format specif=
ier that means to call <span style=3D"font-family: courier new,monospace;">=
std::printf_handler(const T &amp;, const std::printf_parameters &amp;)</spa=
n> if it exists, and fall back to <span style=3D"font-family: courier new,m=
onospace;">std::operator &lt;&lt;(std::ostream &amp;, const T &amp;)</span>=
, <span style=3D"font-family: courier new,monospace;">T::c_str() const</spa=
n> or <span style=3D"font-family: courier new,monospace;">T::operator const=
 char *() const</span> if it doesn't.<br><br>I understand that there are ce=
rtain things about <span style=3D"font-family: courier new,monospace;">iost=
ream</span> that are better, but there are also things about ...<span style=
=3D"font-family: courier new,monospace;">printf</span> that are better.&nbs=
p; You can't really beat <span style=3D"font-family: courier new,monospace;=
">iostream</span>'s direct calls to output types as opposed to ...<span sty=
le=3D"font-family: courier new,monospace;">printf</span> needing to parse a=
 string at runtime (something partly fixable with <span style=3D"font-famil=
y: courier new,monospace;">constexpr</span> and variadic templates).&nbsp; =
But you also can't compare how succinct <span style=3D"font-family: courier=
 new,monospace;">std::printf("%06X", num);</span> is to the <span style=3D"=
font-family: courier new,monospace;">cout</span> alternative.<br><br>It's a=
lso a matter of preference.&nbsp; 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.<br><br>Regarding your cstdio.hh: Your <span style=3D"font-family: =
courier new,monospace;">fread</span>/<span style=3D"font-family: courier ne=
w,monospace;">fwrite</span> could be more flexible, I suppose.&nbsp; Perhap=
s:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">te=
mplate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">inline</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> size_t fread</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">enable_if_t</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">is_pod</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">val=
ue</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> array_view</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> buf</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> FILE </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">stream</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fread</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">buf</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">data</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(*</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">buf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">data</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">()),</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> buf</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> stream</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></div></code></div><br>Why <span style=3D"font-family: courier =
new,monospace;">array_view</span>, though?&nbsp; I mean, there's always bee=
n this sort of design:<br><br><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">template</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t S</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> vsnprintf</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b=
uf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)[</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">S</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">],</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">forma=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> va_list args</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> vsnprintf</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">buf</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> S</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> format</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> args</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Mel=
issa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_425_2093090180.1412238194540--

.

--Apple-Mail=_1B41181F-1149-43C3-AE6E-D0FC42683CC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-02, at 4:23 PM, Myriachan <myriachan@gmail.com> wrote:

> But you also can't compare how succinctstd::printf("%06X", num); is to th=
e cout alternative.

How about a hybrid, std::cout << std::fmt( "06X", num )? This would cut dow=
n a lot of the metaprocessing overhead; I don't know if it's a good idea to=
 feed sizeable text blocks into a constexpr parser just so it can find embe=
dded markup.

<iostream> is showing its age too. It felt old already by 2011 but it was s=
till premature to go for a replacement.

Maybe it really would be reasonable to get a completely new serialization l=
ibrary standardized around 2020. Something with a generic interface to pote=
ntially handle input, output, and hashing from a single user-defined interf=
ace function, with proper filtering stages and enough I/O savvy to support =
sockets.

--=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=_1B41181F-1149-43C3-AE6E-D0FC42683CC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;02, at 4:23 PM, Myriachan &lt;<a href=3D"mailto:myriachan@gm=
ail.com">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interch=
ange-newline"><blockquote type=3D"cite"><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
 normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none=
; display: inline !important;">But you also can't compare how succinct</spa=
n><span style=3D"font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; font-family: 'courier new', monospace;">std::printf("%06X", num);</span><=
span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px; float: none; display: inline !important;"><span clas=
s=3D"Apple-converted-space">&nbsp;</span>is to the<span class=3D"Apple-conv=
erted-space">&nbsp;</span></span><span style=3D"font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
 -webkit-text-stroke-width: 0px; font-family: 'courier new', monospace;">co=
ut</span><span style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
 -webkit-text-stroke-width: 0px; float: none; display: inline !important;">=
<span class=3D"Apple-converted-space">&nbsp;</span>alternative.</span></blo=
ckquote></div><br><div>How about a hybrid, <font face=3D"Courier">std::cout=
 &lt;&lt; std::fmt( "06X", num )</font>? This would cut down a lot of the m=
etaprocessing overhead; I don&rsquo;t know if it&rsquo;s a good idea to fee=
d sizeable text blocks into a <font face=3D"Courier">constexpr</font> parse=
r just so it can find embedded markup.</div><div><br></div><div><font face=
=3D"Courier">&lt;iostream&gt;</font> is showing its age too. It felt old al=
ready by 2011 but it was still premature to go for a replacement.</div><div=
><br></div><div>Maybe it really would be reasonable to get a completely new=
 serialization library standardized around 2020. Something with a generic i=
nterface to potentially handle input, output, and hashing from a single use=
r-defined interface function, with proper filtering stages and enough I/O s=
avvy to support sockets.</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_1B41181F-1149-43C3-AE6E-D0FC42683CC2--

.

------=_Part_1046_1771348031.1412259580863
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, October 2, 2014 4:23:14 AM UTC-4, Myriachan wrote:
>
>
> I'm a fan of ...printf, but would love it to come into this...well,=20
> millennium.=20
>

I've been wanting this for years. I love printf and loathe iostream.=20
Unfortunately its a really really hard problem to solve.
=20

> We have variadic templates and constexpr now.  Not only can its buffer=20
> overflow problems be solved as above, but its type-safety and extendabili=
ty=20
> problems can be solved, too.
>
> There's nothing really stopping us from having a %v format specifier that=
=20
> means to call std::printf_handler(const T &, const std::printf_parameters=
=20
> &) if it exists, and fall back to std::operator <<(std::ostream &, const=
=20
> 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=20
> better, but there are also things about ...printf that are better.  You=
=20
> can't really beat iostream's direct calls to output types as opposed to=
=20
> ...printf needing to parse a string at runtime (something partly fixable=
=20
> with constexpr and variadic templates).  But you also can't compare how=
=20
> succinct std::printf("%06X", num); is to the cout alternative.
>

iostream also pollutes the caller's instruction stream with tons of=20
function calls. Pushing a few things to std::cout can destroy your icache.
=20

>
> It's also a matter of preference.  There are people who use Visual Studio=
=20
> here at my employer who install a mod that makes its editor commands work=
=20
> like vim's.
>
> Regarding your cstdio.hh: Your fread/fwrite could be more flexible, I=20
> suppose.  Perhaps:
>
> template <typename T>
> inline size_t fread(enable_if_t<is_pod<T>::value, array_view<T>> buf,=20
> FILE *stream)
> {
>     return fread(buf.data(), sizeof(*buf.data()), buf.size(), stream);
> }
>
>
I don't want to go too far down the rabbit hole here. All I'm after is a=20
simple wrapper for arrays so that we can stop having buffer overflows when=
=20
we use the old C functions, like the C array& version you proposed below.

Also this interface is misleading because due to padding it may not=20
actually do what you think it does. I'm not even sure I like the array_view=
=20
overloads for the things taking void* (fread, fwrite, memcpy, etc..)
=20

> Why array_view, though?  I mean, there's always been this sort of design:
>
> template <std::size_t S>
> inline int vsnprintf(char (&buf)[S], const char *format, va_list args)
> {
>     return vsnprintf(buf, S, format, args);
> }
>
>
array_view is more general than the pass C array by reference. It supports=
=20
this usage automatically as well as std::array, std::vector, std::string=20
and any other contiguous backend. array_view is the future.


On Thursday, October 2, 2014 4:45:48 AM UTC-4, David Krauss wrote:
>
>
> On 2014=E2=80=9310=E2=80=9302, at 4:23 PM, Myriachan <myri...@gmail.com <=
javascript:>>=20
> wrote:
>
> But you also can't compare how succinctstd::printf("%06X", num); is to th=
e
>  cout alternative.
>
>
> How about a hybrid, std::cout << std::fmt( "06X", num )? This would cut=
=20
> down a lot of the metaprocessing overhead; I don=E2=80=99t know if it=E2=
=80=99s a good idea=20
> to feed sizeable text blocks into a constexpr parser just so it can find=
=20
> embedded markup.
>

There was a std::putf() proposal that does exactly this. I'm not sure how=
=20
far its gotten or what the status is now.
I don't like this approach at all because it only works with iostream. I=20
call snprintf() a lot more than I do printf() and I often do it on fixed=20
size stack buffers for efficiency.

In my opinion, a truely modern printf replacement should work this way.=20
Implementing such a beast is not easy at all.


printf(cout, "%d", 1); //prints to cout
std::string s;
printf(s, "%d", 1); //grows the string so that it stores the result
std::vector<char> v;
printf(v, "%d", 1); //grows the vector so that it stores the result
std::array<char,32> a;
printf(a, "%d", 1); //prints into the array until it hits the end, and then=
=20
truncates
char b[32];
printf(b, "%d", 1); //prints into the array until it hits the end, and then=
=20
truncates
array_view c =3D b;
printf(c, "%d", 1); //prints into the array_view until it hits the end, and=
=20
then truncates


=20

>
> <iostream> is showing its age too. It felt old already by 2011 but it was=
=20
> still premature to go for a replacement.
>
>
iostream needs to go. It was a good first try but I won't miss it.
=20

> Maybe it really would be reasonable to get a completely new serialization=
=20
> library standardized around 2020. Something with a generic interface to=
=20
> potentially handle input, output, and hashing from a single user-defined=
=20
> interface function, with proper filtering stages and enough I/O savvy to=
=20
> support sockets.
>

We need this, we need it badly. But this is a HUGE project. 2017 is out,=20
2020 maybe out too.
Just an off the cuff laundry list of things that need to be supported in=20
such a library:


   - Generic backend (fixed buffer, dynamic buffer, file, IPC, network=20
   socket, etc..) implemented efficiently! (that is no returning copies of=
=20
   std::string etc..)
   - Somehow support atomic messages which don't get interleaved across=20
   multiple threads sharing a stream.
   - Global locale setting using dynamic dispatch
   - Static locale setting which can be inlined (the global locale thing=20
   destroys performance)
   - A variadic printf() style formatting library built on top of the=20
   underlying stream library
      - Should be type safe
      - Watch out for long compile times or too much code generation!
      - *Must be as efficient as C printf!*
      - Parsing libraries (csv, html, json, etc..)=20
   - For buffered files, parsing routines (such as finding a newline) which=
=20
   operate on and return string_view(s) to the internal buffer without maki=
ng=20
   a copy. I have my own file parsing classes which do this and the=20
   performance difference matters big time.
  =20

We can complain about iostream all day (I do all the time), but really this=
=20
is a very hard job. I give the designers of the original iostream a lot of=
=20
credit. The project probably needs its own study group.

Anyway we're getting off topic. My point is that a modern printf=20
replacement is a huge job that will not happen anytime soon if ever. In the=
=20
meantime we should extend a lifeline to the old C functions we all pretend=
=20
we aren't using anymore because of "type safety".


--=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/.

------=_Part_1046_1771348031.1412259580863
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 4:23:14 AM UTC-4, Myr=
iachan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><div>I'm a fan of ...<span style=3D"font-family:courier new,monospace">=
printf</span>, but would love it to come into this...well, millennium.&nbsp=
;</div></div></blockquote><div><br>I've been wanting this for years. I love=
 printf and loathe iostream. Unfortunately its a really really hard problem=
 to solve.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div> We have variadic templates and <span style=3D"font-famil=
y:courier new,monospace">constexpr</span>
 now.&nbsp; Not only can its buffer overflow problems be solved as above, b=
ut
 its type-safety and extendability problems can be solved, too.<br><br>Ther=
e's nothing really stopping us from having a <span style=3D"font-family:cou=
rier new,monospace">%v</span> format specifier that means to call <span sty=
le=3D"font-family:courier new,monospace">std::printf_handler(const T &amp;,=
 const std::printf_parameters &amp;)</span> if it exists, and fall back to =
<span style=3D"font-family:courier new,monospace">std::operator &lt;&lt;(st=
d::ostream &amp;, const T &amp;)</span>, <span style=3D"font-family:courier=
 new,monospace">T::c_str() const</span> or <span style=3D"font-family:couri=
er new,monospace">T::operator const char *() const</span> if it doesn't.<br=
><br>I understand that there are certain things about <span style=3D"font-f=
amily:courier new,monospace">iostream</span> that are better, but there are=
 also things about ...<span style=3D"font-family:courier new,monospace">pri=
ntf</span> that are better.&nbsp; You can't really beat <span style=3D"font=
-family:courier new,monospace">iostream</span>'s direct calls to output typ=
es as opposed to ...<span style=3D"font-family:courier new,monospace">print=
f</span> needing to parse a string at runtime (something partly fixable wit=
h <span style=3D"font-family:courier new,monospace">constexpr</span> and va=
riadic templates).&nbsp; But you also can't compare how succinct <span styl=
e=3D"font-family:courier new,monospace">std::printf("%06X", num);</span> is=
 to the <span style=3D"font-family:courier new,monospace">cout</span> alter=
native.<br></div></div></blockquote><div><br>iostream also pollutes the cal=
ler's instruction stream with tons of function calls. Pushing a few things =
to std::cout can destroy your icache.<br>&nbsp;<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>It's
 also a matter of preference.&nbsp; There are people who use Visual Studio=
=20
here at my employer who install a mod that makes its editor commands=20
work like vim's.<br><br>Regarding your cstdio.hh: Your <span style=3D"font-=
family:courier new,monospace">fread</span>/<span style=3D"font-family:couri=
er new,monospace">fwrite</span> could be more flexible, I suppose.&nbsp; Pe=
rhaps:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word">=
<code><div><span style=3D"color:#008">template</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">&lt;</span><span style=3D"color:#00=
8">typename</span><span style=3D"color:#000"> T</span><span style=3D"color:=
#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#008">inline</span><span style=3D"color:#000"> size_t fread</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">enable_if_t</span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#000">is_pod</span>=
<span style=3D"color:#660">&lt;</span><span style=3D"color:#000">T</span><s=
pan style=3D"color:#660">&gt;::</span><span style=3D"color:#000">v<wbr>alue=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> array=
_view</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000=
">T</span><span style=3D"color:#660">&gt;&gt;</span><span style=3D"color:#0=
00"> buf</span><span style=3D"color:#660">,</span><span style=3D"color:#000=
"> FILE </span><span style=3D"color:#660">*</span><span style=3D"color:#000=
">stream</span><span style=3D"color:#660">)</span><span style=3D"color:#000=
"><br></span><span style=3D"color:#660">{</span><span style=3D"color:#000">=
<br>&nbsp; &nbsp; </span><span style=3D"color:#008">return</span><span styl=
e=3D"color:#000"> fread</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#000">buf</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">data</span><span style=3D"color:#660">(),</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span style=
=3D"color:#660">(*</span><span style=3D"color:#000">buf</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">data</span><span style=
=3D"color:#660">()),</span><span style=3D"color:#000"> buf</span><span styl=
e=3D"color:#660">.</span><span style=3D"color:#000">size</span><span style=
=3D"color:#660">(),</span><span style=3D"color:#000"> stream</span><span st=
yle=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></cod=
e></div><br></div></div></blockquote><div><br>I don't want to go too far do=
wn the rabbit hole here. All I'm after is a simple wrapper for arrays so th=
at we can stop having buffer overflows when we use the old C functions, lik=
e the C array&amp; version you proposed below.<br><br>Also this interface i=
s misleading because due to padding it may not actually do what you think i=
t does. I'm not even sure I like the array_view overloads for the things ta=
king void* (fread, fwrite, memcpy, etc..)<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Why <span style=3D"font-f=
amily:courier new,monospace">array_view</span>, though?&nbsp; I mean, there=
's always been this sort of design:<br><br><div style=3D"background-color:r=
gb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid=
th:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">template=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&lt;</=
span><span style=3D"color:#000">std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#000">size_t S</span><span style=3D"color:#660">&gt=
;</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">in=
line</span><span style=3D"color:#000"> </span><span style=3D"color:#008">in=
t</span><span style=3D"color:#000"> vsnprintf</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#008">char</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">(&amp;</span><span style=3D"color:#000=
">buf</span><span style=3D"color:#660">)[</span><span style=3D"color:#000">=
S</span><span style=3D"color:#660">],</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">const</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">char</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">*</span><span style=3D"color:#000">format</span=
><span style=3D"color:#660">,</span><span style=3D"color:#000"> va_list arg=
s</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br><=
/span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nb=
sp; &nbsp; </span><span style=3D"color:#008">return</span><span style=3D"co=
lor:#000"> vsnprintf</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">buf</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> S</span><span style=3D"color:#660">,</span><span style=3D"col=
or:#000"> format</span><span style=3D"color:#660">,</span><span style=3D"co=
lor:#000"> args</span><span style=3D"color:#660">);</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#660">}</span><span style=3D"colo=
r:#000"><br></span></div></code></div><br></div></div></blockquote><div><br=
>array_view is more general than the pass C array by reference. It supports=
 this usage automatically as well as std::array, std::vector, std::string a=
nd any other contiguous backend. array_view is the future.<br></div><br><br=
>On Thursday, October 2, 2014 4:45:48 AM UTC-4, David Krauss wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><b=
r><div><div>On 2014=E2=80=9310=E2=80=9302, at 4:23 PM, Myriachan &lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8TNrf9FfaxUJ" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">myri...@gmail.com</a>&gt; wrote:</div><br><b=
lockquote type=3D"cite"><span style=3D"font-family:Helvetica;font-size:12px=
;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:no=
rmal;line-height:normal;text-align:start;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px;float:none;display:inline!important">=
But you also can't compare how succinct</span><span style=3D"font-size:12px=
;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:no=
rmal;line-height:normal;text-align:start;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px;font-family:'courier new',monospace">=
std::printf("%06X", num);</span><span style=3D"font-family:Helvetica;font-s=
ize:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-sp=
acing:normal;line-height:normal;text-align:start;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px;float:none;display:inline!imp=
ortant"><span>&nbsp;</span>is to the<span>&nbsp;</span></span><span style=
=3D"font-size:12px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;font-family:'courie=
r new',monospace">cout</span><span style=3D"font-family:Helvetica;font-size=
:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spaci=
ng:normal;line-height:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;float:none;display:inline!import=
ant"><span>&nbsp;</span>alternative.</span></blockquote></div><br><div>How =
about a hybrid, <font face=3D"Courier">std::cout &lt;&lt; std::fmt( "06X", =
num )</font>? This would cut down a lot of the metaprocessing overhead; I d=
on=E2=80=99t know if it=E2=80=99s a good idea to feed sizeable text blocks =
into a <font face=3D"Courier">constexpr</font> parser just so it can find e=
mbedded markup.</div></div></blockquote><div><br>There was a std::putf() pr=
oposal that does exactly this. I'm not sure how far its gotten or what the =
status is now.<br>I don't like this approach at all because it only works w=
ith iostream. I call snprintf() a lot more than I do printf() and I often d=
o it on fixed size stack buffers for efficiency.<br><br>In my opinion, a tr=
uely modern printf replacement should work this way. Implementing such a be=
ast is not easy at all.<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>printf</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">cout</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">"%d"</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">//prints to cout</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">string</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>printf</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">"%d"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">//grows the string so tha=
t it stores the result</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>vector</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt=
;char&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>printf</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">v</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D=
"styled-by-prettify">"%d"</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//grows the vector so that i=
t stores the result</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ar=
ray</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">32</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>printf</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">"%d"</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">//prints into the array until it hits the end, and then truncates</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">32</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">];</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>printf</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">"%d"</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">//prints into the array until it hits the end, and then truncates</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>array_vie=
w c </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>printf</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">c</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">"%d"</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">//prints into the array_view until it=
 hits the end, and then truncates</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br><br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-w=
ord"><div><br></div><div><font face=3D"Courier">&lt;iostream&gt;</font> is =
showing its age too. It felt old already by 2011 but it was still premature=
 to go for a replacement.</div><div><br></div></div></blockquote><div><br>i=
ostream needs to go. It was a good first try but I won't miss it.<br>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word"><div></div><div>Maybe it really would be reasonable to get a co=
mpletely new serialization library standardized around 2020. Something with=
 a generic interface to potentially handle input, output, and hashing from =
a single user-defined interface function, with proper filtering stages and =
enough I/O savvy to support sockets.</div></div></blockquote><div><br>We ne=
ed this, we need it badly. But this is a HUGE project. 2017 is out, 2020 ma=
ybe out too.<br>Just an off the cuff laundry list of things that need to be=
 supported in such a library:<br><br><ul><li>Generic backend (fixed buffer,=
 dynamic buffer, file, IPC, network socket, etc..) implemented efficiently!=
 (that is no returning copies of std::string etc..)</li><li>Somehow support=
 atomic messages which don't get interleaved across multiple threads sharin=
g a stream.<br></li><li>Global locale setting using dynamic dispatch</li><l=
i>Static locale setting which can be inlined (the global locale thing destr=
oys performance)<br></li><li>A variadic printf() style formatting library b=
uilt on top of the underlying stream library</li><ul><li>Should be type saf=
e</li><li>Watch out for long compile times or too much code generation!</li=
><li><b>Must be as efficient as C printf!</b><br></li></ul><li>Parsing libr=
aries (csv, html, json, etc..) <br></li><li>For buffered files, parsing rou=
tines (such as finding a newline) which operate 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.<br><=
/li></ul><p><br></p><p>We can complain about iostream all day (I do all the=
 time), but really this is a very hard job. I give the designers of the ori=
ginal iostream a lot of credit. The project probably needs its own study gr=
oup.<br></p><p>Anyway we're getting off topic. My point is that a modern pr=
intf replacement is a huge job that will not happen anytime soon if ever. I=
n the meantime we should extend a lifeline to the old C functions we all pr=
etend we aren't using anymore because of "type safety".<br></p><p><br></p><=
/div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1046_1771348031.1412259580863--

.

------=_Part_515_396131354.1412263669080
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 1, 2014 7:37:39 PM UTC+2, Matthew Fioravante wrote:
>
> We have a solution for this stupidity now, that solution is
> std::array_view. Not only does it correctly store the size as an invariant
> of the type, but it also directly works with C arrays, std::array,
> std::vector, std::string, etc..
>

Has array_view been accepted already? Why not string_view?


> std::array<char,32> a;
> printf(a, "%d", 1); //prints into the array until it hits the end, and
> then truncates
>

I don't think truncation is a good idea.
Would it return the number of characters written?

--

---
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_515_396131354.1412263669080
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 1, 2014 7:37:39 PM UTC+2, Ma=
tthew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">We hav=
e a solution for this stupidity now, that solution is std::array_view. Not =
only does it correctly store the size as an invariant of the type, but it a=
lso directly works with C arrays, std::array, std::vector, std::string, etc=
...<br></div></blockquote><div><br></div><div>Has array_view been accepted a=
lready? Why not string_view?</div><div>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div style=3D"background-color:r=
gb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid=
th:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">std</spa=
n><span style=3D"color:#660">::</span><span style=3D"color:#000">array</spa=
n><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">char</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#066">32</span><=
span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> a</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br>printf</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#000">a</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#080">"%d"</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#066">1</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#800">//prints into the array until it hits the end, and then truncates</=
span></div></code></div></div></div></blockquote><div><br></div><div>I don'=
t think truncation is a good idea.</div><div>Would it return the number of =
characters written?&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_515_396131354.1412263669080--

.

------=_Part_5602_1668713234.1412264064630
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 11:27:49 AM UTC-4, Olaf van der Spek wrote:
>
>
>
> On Wednesday, October 1, 2014 7:37:39 PM UTC+2, Matthew Fioravante wrote:
>>
>> We have a solution for this stupidity now, that solution is
>> std::array_view. Not only does it correctly store the size as an invariant
>> of the type, but it also directly works with C arrays, std::array,
>> std::vector, std::string, etc..
>>
>
> Has array_view been accepted already?
>

Yes I believe so.

Why not string_view?
>


   1. string_view is always const, you cannot write to it.
   2. The invariant of string_view is that the stored length represents the
   entire string. array_view<char> is just an array of characters, so if your
   printf only fills up half of the arrray its not violating the invariants of
   the type.



>
>
>> std::array<char,32> a;
>> printf(a, "%d", 1); //prints into the array until it hits the end, and
>> then truncates
>>
>
> I don't think truncation is a good idea.
>

You have no other option with a fixed size destination buffer.


> Would it return the number of characters written?
>

Yes, or even better (for a modern printf, not these C updates):

string_view printf(array_view<char> a, string_view fmt, ...); //return
value points to a.begin() and stores the length of the result.



--

---
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_5602_1668713234.1412264064630
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 11:27:49 AM UTC-4, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Wednesday, October 1, 2014 7:37:39 PM UTC+2, Matthew Fi=
oravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr">We have a solution for thi=
s stupidity now, that solution is std::array_view. Not only does it correct=
ly store the size as an invariant of the type, but it also directly works w=
ith C arrays, std::array, std::vector, std::string, etc..<br></div></blockq=
uote><div><br></div><div>Has array_view been accepted already? </div></div>=
</blockquote><div><br>Yes I believe so.&nbsp; <br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Why not string_view?</d=
iv></div></blockquote><div><br><ol><li>string_view is always const, you can=
not write to it.</li><li>The invariant of string_view is that the stored le=
ngth represents the entire string. array_view&lt;char&gt; is just an array =
of characters, so if your printf only fills up half of the arrray its not v=
iolating the invariants of the type.<br></li></ol>&nbsp;</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&nbsp;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000=
">std</span><span style=3D"color:#660">::</span><span style=3D"color:#000">=
array</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008=
">char</span><span style=3D"color:#660">,</span><span style=3D"color:#066">=
32</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> =
a</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>p=
rintf</span><span style=3D"color:#660">(</span><span style=3D"color:#000">a=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#080">"%d"</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#066">1</span><span=
 style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#800">//prints into the array until it hits the end, and then t=
runcates</span></div></code></div></div></div></blockquote><div><br></div><=
div>I don't think truncation is a good idea.</div></div></blockquote><div><=
br>You have no other option with a fixed size destination buffer.<br>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Wo=
uld it return the number of characters written?&nbsp;</div></div></blockquo=
te><div><br>Yes, or even better (for a modern printf, not these C updates):=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">stri=
ng_view printf</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">array=
_view</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;c=
har&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> string_view fmt</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">...);</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">//return value points to a.begin() and stores =
the length of the result.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><br>&nbsp;<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5602_1668713234.1412264064630--

.

On 2 October 2014 18:34, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>
>
> On Thursday, October 2, 2014 11:27:49 AM UTC-4, Olaf van der Spek wrote:
>>
>>
>>
>> On Wednesday, October 1, 2014 7:37:39 PM UTC+2, Matthew Fioravante wrote:
>>>
>>> We have a solution for this stupidity now, that solution is
>>> std::array_view. Not only does it correctly store the size as an invariant
>>> of the type, but it also directly works with C arrays, std::array,
>>> std::vector, std::string, etc..
>>
>>
>> Has array_view been accepted already?
>
>
> Yes I believe so.

No, it hasn't been accepted, it's not in any standard, and it's not in
any TS I can find
either.

--

---
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_594_1644131082.1412264588882
Content-Type: text/plain; charset=UTF-8

Sorry, maybe I misunderstood this?

https://groups.google.com/a/isocpp.org/forum/#!searchin/std-discussion/array_view/std-discussion/rhyHVrKtC50/IR2EvQFFFYIJ


--

---
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_594_1644131082.1412264588882
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Sorry, maybe I misunderstood this?<br><br>https://groups.google.com/a/isocpp.org/forum/#!searchin/std-discussion/array_view/std-discussion/rhyHVrKtC50/IR2EvQFFFYIJ<br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_594_1644131082.1412264588882--

.

------=_Part_708_1135227779.1412264755689
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 5:34:24 PM UTC+2, Matthew Fioravante wrote:
>
>
>
>    1. string_view is always const, you cannot write to it.
>
>
Right. Perhaps we need a non-const one too.


>
>    1. The invariant of string_view is that the stored length represents
>    the entire string. array_view<char> is just an array of characters, so if
>    your printf only fills up half of the arrray its not violating the
>    invariants of the type.
>
>
I don't think that's really a problem.

--

---
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_708_1135227779.1412264755689
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 5:34:24 PM UTC+2, Mat=
thew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br><ol><li>string_view is always const, you cannot write to =
it.</li></ol></div></div></blockquote><div><br></div><div>Right. Perhaps we=
 need a non-const one too.</div><div>&nbsp;</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><ol><li>The invariant of string_view is=
 that the stored length represents the entire string. array_view&lt;char&gt=
; is just an array of characters, so if your printf only fills up half of t=
he arrray its not violating the invariants of the type.</li></ol></div></bl=
ockquote><div><br></div><div>I don't think that's really a problem.&nbsp;</=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_708_1135227779.1412264755689--

.

------=_Part_6832_70952541.1412265057798
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 11:45:55 AM UTC-4, Olaf van der Spek wrote:
>
>
>
> On Thursday, October 2, 2014 5:34:24 PM UTC+2, Matthew Fioravante wrote:
>>
>>
>>
>>    1. string_view is always const, you cannot write to it.
>>
>>
> Right. Perhaps we need a non-const one too.
>
>
>>
>>    1. The invariant of string_view is that the stored length represents
>>    the entire string. array_view<char> is just an array of characters, so if
>>    your printf only fills up half of the arrray its not violating the
>>    invariants of the type.
>>
>>
> I don't think that's really a problem.
>

It is a problem because there is no concept of null termination with
string_view. If you were to write to a string_view with printf then you
also need to modify the length. Otherwise you end up with a string_view
which claims to be of length 32 but only has 16 characters, a null
terminator, and 15 more uninitialized bytes.

This means you either have to pass in a mutable string_view by reference or
return a new string_view.

When you do a C printf you're writing to a buffer of fixed size.The best
way to represent that concept is with an array_view.

--

---
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_6832_70952541.1412265057798
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 11:45:55 AM UTC-4, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Thursday, October 2, 2014 5:34:24 PM UTC+2, Matthew Fio=
ravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
><br><ol><li>string_view is always const, you cannot write to it.</li></ol>=
</div></div></blockquote><div><br></div><div>Right. Perhaps we need a non-c=
onst one too.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><ol><li>The invariant of string_view is that the stored l=
ength represents the entire string. array_view&lt;char&gt; is just an array=
 of characters, so if your printf only fills up half of the arrray its not =
violating the invariants of the type.</li></ol></div></blockquote><div><br>=
</div><div>I don't think that's really a problem.&nbsp;</div></div></blockq=
uote><div><br>It is a problem because there is no concept of null terminati=
on with string_view. If you were to write to a string_view with printf then=
 you also need to modify the length. Otherwise you end up with a string_vie=
w which claims to be of length 32 but only has 16 characters, a null termin=
ator, and 15 more uninitialized bytes.<br><br>This means you either have to=
 pass in a mutable string_view by reference or return a new string_view.<br=
><br>When you do a C printf you're writing to a buffer of fixed size.The be=
st way to represent that concept is with an array_view.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6832_70952541.1412265057798--

.

On 2 October 2014 18:43, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> Sorry, maybe I misunderstood this?
>
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-discussion/array_view/std-discussion/rhyHVrKtC50/IR2EvQFFFYIJ


"On its way to a TS" is _far_ away from being accepted. It's going to
end up in a working draft
of that TS at some point (but isn't there yet, as far as I
understand), and it still needs to be balloted
and published. And as much as people like to claim that TS (technical
specification) is as official
as an IS (international standard), the TS stuff lives in a namespace
called std::experimental.

So no, certainly not accepted.

--

---
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/.

.

On Thu, Oct 2, 2014 at 5:50 PM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
> It is a problem because there is no concept of null termination with
> string_view. If you were to write to a string_view with printf then you also
> need to modify the length. Otherwise you end up with a string_view which
> claims to be of length 32 but only has 16 characters, a null terminator, and
> 15 more uninitialized bytes.
>
> This means you either have to pass in a mutable string_view by reference or
> return a new string_view.

IMO it's exactly the same with array_view.


--
Olaf

--

---
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_2760_778597621.1412265397582
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 11:53:54 AM UTC-4, Ville Voutilainen wrote:
>
> On 2 October 2014 18:43, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
> > Sorry, maybe I misunderstood this?
> >
> >
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-discussion/array_view/std-discussion/rhyHVrKtC50/IR2EvQFFFYIJ
>
>
> "On its way to a TS" is _far_ away from being accepted. It's going to
> end up in a working draft
> of that TS at some point (but isn't there yet, as far as I
> understand), and it still needs to be balloted
> and published. And as much as people like to claim that TS (technical
> specification) is as official
> as an IS (international standard), the TS stuff lives in a namespace
> called std::experimental.
>
> So no, certainly not accepted.
>

Fair enough, sorry for the misunderstanding. Still having it on the way to
a TS is good enough for me to write a new proposal on top of it. New
proposals can also help show uses cases and flesh out design mistakes.

--

---
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_2760_778597621.1412265397582
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 11:53:54 AM UTC-4, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2 Oct=
ober 2014 18:43, Matthew Fioravante &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"VreNYhxnNcQJ" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;=
">fmatth...@gmail.com</a>&gt; wrote:
<br>&gt; Sorry, maybe I misunderstood this?
<br>&gt;
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin=
/std-discussion/array_view/std-discussion/rhyHVrKtC50/IR2EvQFFFYIJ" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.=
org/forum/#!searchin/std-discussion/array_view/std-discussion/rhyHVrKtC50/I=
R2EvQFFFYIJ';return true;" onclick=3D"this.href=3D'https://groups.google.co=
m/a/isocpp.org/forum/#!searchin/std-discussion/array_view/std-discussion/rh=
yHVrKtC50/IR2EvQFFFYIJ';return true;">https://groups.google.com/a/<wbr>isoc=
pp.org/forum/#!searchin/<wbr>std-discussion/array_view/std-<wbr>discussion/=
rhyHVrKtC50/<wbr>IR2EvQFFFYIJ</a>
<br>
<br>
<br>"On its way to a TS" is _far_ away from being accepted. It's going to
<br>end up in a working draft
<br>of that TS at some point (but isn't there yet, as far as I
<br>understand), and it still needs to be balloted
<br>and published. And as much as people like to claim that TS (technical
<br>specification) is as official
<br>as an IS (international standard), the TS stuff lives in a namespace
<br>called std::experimental.
<br>
<br>So no, certainly not accepted.
<br></blockquote><div><br>Fair enough, sorry for the misunderstanding. Stil=
l having it on the way to a TS is good enough for me to write a new proposa=
l on top of it. New proposals can also help show uses cases and flesh out d=
esign mistakes.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2760_778597621.1412265397582--

.

On 2 October 2014 18:56, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>> "On its way to a TS" is _far_ away from being accepted. It's going to
>> end up in a working draft
>> of that TS at some point (but isn't there yet, as far as I
>> understand), and it still needs to be balloted
>> and published. And as much as people like to claim that TS (technical
>> specification) is as official
>> as an IS (international standard), the TS stuff lives in a namespace
>> called std::experimental.
>>
>> So no, certainly not accepted.
> Fair enough, sorry for the misunderstanding. Still having it on the way to a
> TS is good enough for me to write a new proposal on top of it. New proposals
> can also help show uses cases and flesh out design mistakes.


Certainly, no disagreement there. It's plenty fine as a base for new
proposals, I didn't
mean to suggest that at all, just wanted to clarify the acceptance status.

--

---
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_6820_868083016.1412265717708
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 11:55:58 AM UTC-4, Olaf van der Spek wrote:
>
> On Thu, Oct 2, 2014 at 5:50 PM, Matthew Fioravante
> <fmatth...@gmail.com <javascript:>> wrote:
> > It is a problem because there is no concept of null termination with
> > string_view. If you were to write to a string_view with printf then you
> also
> > need to modify the length. Otherwise you end up with a string_view which
> > claims to be of length 32 but only has 16 characters, a null terminator,
> and
> > 15 more uninitialized bytes.
> >
> > This means you either have to pass in a mutable string_view by reference
> or
> > return a new string_view.
>
> IMO it's exactly the same with array_view.
>
>
I disagree. An array_view<char> is just an array which can store up to
array_view<char>::size() characters. Modifying the first N characters by a
call to printf() or something else doesn't mean anything for the type.
Maybe you want to fill up the rest of the array_view with something else
after the printf call.

There are 2 objects under consideration here. One is the underlying buffer
we will write to. The other is the conceptual string that this data
represents.

That's why I like this design:

string_view printf(array_view<char> buf, string_view fmt, ...);

Its saying I will write up buf.size() characters into buf and return
string_view which points to those characters.

We don't need out parameters here or pass by reference. The 2 different
types have obvious meanings.

--

---
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_6820_868083016.1412265717708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 11:55:58 AM UTC-4, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, =
Oct 2, 2014 at 5:50 PM, Matthew Fioravante
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
CDWLbasGixMJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">fmatth...@gmail.com</a>&gt; wr=
ote:
<br>&gt; It is a problem because there is no concept of null termination wi=
th
<br>&gt; string_view. If you were to write to a string_view with printf the=
n you also
<br>&gt; need to modify the length. Otherwise you end up with a string_view=
 which
<br>&gt; claims to be of length 32 but only has 16 characters, a null termi=
nator, and
<br>&gt; 15 more uninitialized bytes.
<br>&gt;
<br>&gt; This means you either have to pass in a mutable string_view by ref=
erence or
<br>&gt; return a new string_view.
<br>
<br>IMO it's exactly the same with array_view.
<br>
<br></blockquote><div><br>I disagree. An array_view&lt;char&gt; is just an =
array which can store up to array_view&lt;char&gt;::size() characters. Modi=
fying the first N characters by a call to printf() or something else doesn'=
t mean anything for the type. Maybe you want to fill up the rest of the arr=
ay_view with something else after the printf call.<br><br>There are 2 objec=
ts under consideration here. One is the underlying buffer we will write to.=
 The other is the conceptual string that this data represents.<br><br>That'=
s why I like this design:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">string_view printf</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">array_view</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">&lt;char&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> buf</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> string_view fmt</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an></div></code></div><br>Its saying I will write up buf.size() characters =
into buf and return string_view which points to those characters.<br><br>We=
 don't need out parameters here or pass by reference. The 2 different types=
 have obvious meanings.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6820_868083016.1412265717708--

.

------=_Part_7226_1769287778.1412265892787
Content-Type: text/plain; charset=UTF-8

Just to clarify a bit more, the 2 concepts we are dealing with are "buffer"
and "string". array_view<char> and string_view separate those in an obvious
way.

--

---
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_7226_1769287778.1412265892787
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Just to clarify a bit more, the 2 concepts we are dealing with are "buffer" and "string". array_view&lt;char&gt; and string_view separate those in an obvious way.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_7226_1769287778.1412265892787--

.

------=_Part_6870_774252418.1412266050236
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 11:58:16 AM UTC-4, Ville Voutilainen wrote:
>
> On 2 October 2014 18:56, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
> >> "On its way to a TS" is _far_ away from being accepted. It's going to
> >> end up in a working draft
> >> of that TS at some point (but isn't there yet, as far as I
> >> understand), and it still needs to be balloted
> >> and published. And as much as people like to claim that TS (technical
> >> specification) is as official
> >> as an IS (international standard), the TS stuff lives in a namespace
> >> called std::experimental.
> >>
> >> So no, certainly not accepted.
> > Fair enough, sorry for the misunderstanding. Still having it on the way
> to a
> > TS is good enough for me to write a new proposal on top of it. New
> proposals
> > can also help show uses cases and flesh out design mistakes.
>
>
> Certainly, no disagreement there. It's plenty fine as a base for new
> proposals, I didn't
> mean to suggest that at all, just wanted to clarify the acceptance status.
>

Ville, do you think it would make sense to somehow officially track which
proposals cite others? When evaluating a particular proposal, this would
allow committee members to get a better picture of its importance and
implications.

--

---
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_6870_774252418.1412266050236
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 11:58:16 AM UTC-4, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2 Oct=
ober 2014 18:56, Matthew Fioravante &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"nxCJZchV3xEJ" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;=
">fmatth...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; "On its way to a TS" is _far_ away from being accepted. It's g=
oing to
<br>&gt;&gt; end up in a working draft
<br>&gt;&gt; of that TS at some point (but isn't there yet, as far as I
<br>&gt;&gt; understand), and it still needs to be balloted
<br>&gt;&gt; and published. And as much as people like to claim that TS (te=
chnical
<br>&gt;&gt; specification) is as official
<br>&gt;&gt; as an IS (international standard), the TS stuff lives in a nam=
espace
<br>&gt;&gt; called std::experimental.
<br>&gt;&gt;
<br>&gt;&gt; So no, certainly not accepted.
<br>&gt; Fair enough, sorry for the misunderstanding. Still having it on th=
e way to a
<br>&gt; TS is good enough for me to write a new proposal on top of it. New=
 proposals
<br>&gt; can also help show uses cases and flesh out design mistakes.
<br>
<br>
<br>Certainly, no disagreement there. It's plenty fine as a base for new
<br>proposals, I didn't
<br>mean to suggest that at all, just wanted to clarify the acceptance stat=
us.
<br></blockquote><div><br>Ville, do you think it would make sense to someho=
w officially track which proposals cite others? When evaluating a particula=
r proposal, this would allow committee members to get a better picture of i=
ts importance and implications.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6870_774252418.1412266050236--

.

On 2 October 2014 19:07, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> Ville, do you think it would make sense to somehow officially track which
> proposals cite others? When evaluating a particular proposal, this would
> allow committee members to get a better picture of its importance and
> implications.

I'm sure it would make sense, but someone would need to do the work, too.

--

---
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/.

.

On 2014-10-02 10:19, Matthew Fioravante wrote:
> On Thursday, October 2, 2014 4:23:14 AM UTC-4, Myriachan wrote:
>> Maybe it really would be reasonable to get a completely new serialization
>> library standardized around 2020. Something with a generic interface to
>> potentially handle input, output, and hashing from a single user-defined
>> interface function, with proper filtering stages and enough I/O savvy to
>> support sockets.
>
> We need this, we need it badly. But this is a HUGE project. 2017 is out,
> 2020 maybe out too.
> Just an off the cuff laundry list of things that need to be supported in
> such a library:
>
>    - Generic backend (fixed buffer, dynamic buffer, file, IPC, network
>    socket, etc..) implemented efficiently! (that is no returning copies of
>    std::string etc..)

Have you looked at QIODevice? I believe it supports all of these (IPC is
the only one I'm not sure if there is a concrete implementation; the
others I know it supports). Really, what you want is a stream built on
top of a buffer that implements virtual read() and write() and isn't
*required* to support anything beyond those.

Decoupling the stream from the I/O device also helps; QTextStream,
QBinaryStream, etc. are just mechanisms to take data and [de]serialize
it to/from a byte stream *and are agnostic* as to how the underlying
device is implemented. It's a cleaner and much more extensible design
that what is currently in <iostream>.

>       - Parsing libraries (csv, html, json, etc..)

I'm not convinced this should be in the standard, and certainly not in
the first pass. At any rate, separating the device from the stream would
solve this problem; just implement a new stream for whatever format you
need to read/write.

--
Matthew

--

---
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/.

.

--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 <fmatthew5876@gmail.com> 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;02, at 10:19 PM, Matthew Fioravante &lt;<a href=3D"mailto:fm=
atthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><ul style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;"><li>Generic backend (fixed buffer, dynamic buffer, file, IPC, network =
socket, etc..) implemented efficiently! (that is no returning copies of std=
::string etc..)</li></ul></blockquote><div>Networking libraries are a very =
active area of development, and it&rsquo;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&rsquo;s on hold right now.</div><blockquo=
te type=3D"cite"><ul style=3D"font-family: Helvetica; font-size: 12px; font=
-style: normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; text-indent:=
 0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px;"><li>Somehow support atomic messages=
 which don't get interleaved across multiple threads sharing a stream.<br><=
/li></ul></blockquote>I don&rsquo;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.<br><blockquote type=3D"cite"><ul style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><li>Global loca=
le setting using dynamic dispatch</li><li>Static locale setting which can b=
e inlined (the global locale thing destroys performance)<br></li></ul></blo=
ckquote>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.<br><blockquote type=3D"cite"><ul =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-=
variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:=
 none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px;"><li>A variadic printf() style formatting library built o=
n top of the underlying stream library</li><ul><li>Should be type safe</li>=
<li>Watch out for long compile times or too much code generation!</li><li><=
b>Must be as efficient as C printf!</b><br></li></ul></ul></blockquote>C pr=
intf efficiency is overrated. Also, such a library can probably exist outsi=
de the standard, in something like Boost, if it&rsquo;s redundant with a mo=
re modern interface.<br><blockquote type=3D"cite"><ul style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><l=
i>Parsing libraries (csv, html, json, etc..)<span class=3D"Apple-converted-=
space">&nbsp;</span><br></li></ul></blockquote>Likewise, these should be ex=
ternal components. There could be a follow-on TS.<br><blockquote type=3D"ci=
te"><ul style=3D"font-family: Helvetica; font-size: 12px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;"><li>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.</li></ul></blockq=
uote></div>That would require the entire returned string to fit inside the =
buffer. Also it requires the buffer to be in the application&rsquo;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 <font face=3D"C=
ourier">std::filebuf</font>, which is singularly the least broken part of i=
ostreams.<div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_D4C336AA-78C3-41A9-98C5-C7EECFD16F55--

.

On 2014-10-02 12:28, Ville Voutilainen wrote:
> On 2 October 2014 19:20, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>>>    - Generic backend (fixed buffer, dynamic buffer, file, IPC, network
>>>    socket, etc..) implemented efficiently! (that is no returning copies of
>>>    std::string etc..)
>> Have you looked at QIODevice? I believe it supports all of these (IPC is
>> the only one I'm not sure if there is a concrete implementation; the
>> others I know it supports). Really, what you want is a stream built on
>> top of a buffer that implements virtual read() and write() and isn't
>> *required* to support anything beyond those.
>
> I expect a fair number of people to shout bloody murder if someone proposes
> an i/o library that requires virtual functions to operate.

Well, that's too bloody bad; I guess they despise iostream for the same
reason? (Surprise, surprise, iostream *already uses virtuals*, in
exactly the manner I mentioned above).

There really is no way to provide an implementation that lets you pass a
generic stream to an algorithm regardless of the underlying device (and
I certainly hope we can all agree that this is a required feature!)
except virtual functions...

....or templates. We could template the streams on the underlying device,
giving us a combinatorial explosion of stream types, and then also
template *every single algorithm that uses a stream* to take any
stream-device combination.

Yeah. Never going to happen. That's *so* atrocious I am literally at a
loss for words.

Anyone that thinks generic I/O is going to happen without virtual
functions needs a strong dose of reality.

--
Matthew

--

---
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_7306_1255879757.1412270466839
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 12:57:34 PM UTC-4, Matthew Woehlke wrote:
>
>
> Anyone that thinks generic I/O is going to happen without virtual
> functions needs a strong dose of reality.
>
>
Matthew is absolutely right. You need dynamic dispatch to type erase the
underlying device, whether its a virtual, std::function, C function
pointer, or something else. Code that interacts with streams require
runtime polymorphism.

Virtuals are not the problem. If you call a virtual read() for every byte
then yes its slow and useless. If you call virtual read() for a large chunk
at a time (say 32K or whatever), the overhead of the virtual call becomes
epsilon. I have my own file parser which uses virtual for the IO backend
and only calls it when it needs more bytes form the device. Its at least 3
times faster than anything implementable using the standard library and the
virtual calls don't even show up on the profiler.

Saying "don't use virtual because virtual is bad Q.E.D" is dogma, not
science.

Also there are ways you can have your cake and eat it too:

struct device {
  virtual ssize_t read(void* p, size_t len) = 0;
};

struct net_device : public device {
  virtual ssize_t read(void* p, size_t len) override final;
};

net_device nd("some socket");

nd.read(/*something*/); //No virtual call due to final

device& d = net_device;
d.read(/*something*/); //Virtual call, but we get type erasure and don't
need templates.





--

---
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_7306_1255879757.1412270466839
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 12:57:34 PM UTC-4, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Anyone=
 that thinks generic I/O is going to happen without virtual
<br>functions needs a strong dose of reality.
<br>
<br></blockquote><div><br>Matthew is absolutely right. You need dynamic dis=
patch to type erase the underlying device, whether its a virtual, std::func=
tion, C function pointer, or something else. Code that interacts with strea=
ms require runtime polymorphism. <br><br>Virtuals are not the problem. If y=
ou call a virtual read() for every byte then yes its slow and useless. If y=
ou call virtual read() for a large chunk at a time (say 32K or whatever), t=
he overhead of the virtual call becomes epsilon. I have my own file parser =
which uses virtual for the IO backend and only calls it when it needs more =
bytes form the device. Its at least 3 times faster than anything implementa=
ble using the standard library and the virtual calls don't even show up on =
the profiler.<br><br>Saying "don't use virtual because virtual is bad Q.E.D=
" is dogma, not science.<br><br>Also there are ways you can have your cake =
and eat it too:<br><br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> device </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">vir=
tual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ssize=
_t read</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> size_t len</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> net_device </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">public</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> device </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> ssize_t read</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> size_t len</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">override</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">final</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>net_d=
evice nd</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"some socke=
t"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>nd</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">read</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">/*something*/</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">//No virtual call due to final</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br>device</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> net_device</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>d</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">read</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #800;" class=3D"styled-by-prettify">/*somethi=
ng*/</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//Virtual call, but we =
get type erasure and don't need templates.</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span></div></code></div><br><br><=
br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7306_1255879757.1412270466839--

.

On 2014-10-02 13:21, Matthew Fioravante wrote:
> On Thursday, October 2, 2014 12:57:34 PM UTC-4, Matthew Woehlke wrote:
>> Anyone that thinks generic I/O is going to happen without virtual
>> functions needs a strong dose of reality.
>
> Matthew is absolutely right. You need dynamic dispatch to type erase the
> underlying device, whether its a virtual, std::function, C function
> pointer, or something else. Code that interacts with streams require
> runtime polymorphism.
>
> Virtuals are not the problem. If you call a virtual read() for every byte
> then yes its slow and useless. If you call virtual read() for a large chunk
> at a time (say 32K or whatever), the overhead of the virtual call becomes
> epsilon.

....and indeed, I believe that QIODevice implements internal buffering,
probably for exactly this reason (but maybe not exclusively).

The low-level methods that actually perform the I/O (and are pure
virtual in the base class) are in fact protected methods (and do operate
on blocks). The user-level read/write methods, e.g. that would be used
by a stream wrapped are not virtual.

Some of open()/close()/etc. are public and virtual, but you've got other
issues if these are performance hot-spots...



Semi-related: can compilers optimize away a non-final virtual call if
the concrete type of the object is known? E.g.:

  MyDevice d;
  d.virtual_method(); // virtual dispatch would seem unnecessary here

--
Matthew

--

---
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_6969_280122226.1412271068819
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 1:29:14 PM UTC-4, Matthew Woehlke wrote:


> Semi-related: can compilers optimize away a non-final virtual call if
> the concrete type of the object is known? E.g.:
>
>   MyDevice d;
>   d.virtual_method(); // virtual dispatch would seem unnecessary here
>

yes they can and do.

--

---
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_6969_280122226.1412271068819
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br><br>On Thursday, October 2, 2014 1:29:14 PM UTC-4, Matthew Woehlke wrote:<br><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Semi-related: can compilers optimize away a non-final virtual call if
<br>the concrete type of the object is known? E.g.:
<br>
<br>&nbsp; MyDevice d;
<br>&nbsp; d.virtual_method(); // virtual dispatch would seem unnecessary here
<br></blockquote><div><br>yes they can and do. <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_6969_280122226.1412271068819--

.

On 2014-10-02 13:53, Ville Voutilainen wrote:
> On 2 October 2014 19:57, Matthew Woehlke wrote:
>> Anyone that thinks generic I/O is going to happen without virtual
>> functions needs a strong dose of reality.
>
> How many virtual functions does boost::asio use?

I'm not familiar with boost::asio (except for a certain dislike as my
passing experience with it has been with applications that use it
crashing and/or hanging in asio bowels).

That said... it looks like it isn't possible to pass an asio buffer to a
non-templated algorithm. That, as far as I am concerned, makes it nigh
unusable as a basic I/O library. Also, "not generic".

If something is going to replace iostream, I consider it a hard
requirement that I can pass "something" to a *non-templated* function
like 'Object::write(stream&)' (or 'device&'), regardless of what actual
I/O device is backing the passed-in stream/device. Yes, pedantically,
there are ways to do that without virtual methods, but those techniques
look and act suspiciously like virtual methods...

It may be that asio gets away with it because the 'stream' is just a
generic queue that has to be driven externally by a concrete device. But
that's a special case that only works because of the asynchronous
operation, which has its own set of issues. (Advantages too, but there
are still issues.)

Put another way, if you declare that there is One True Memory-Backed
Buffer that is the only thing you can do stream operations on, and that
the user must take additional steps to move data between this buffer and
an actual I/O device... then sure, you could make that work to some
extent without virtuals. Good luck getting it to read data on demand,
though. (Or you can use one of the aforementioned looks-like-a-virtual
techniques...)

--
Matthew

--

---
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/.

.

On 2014-10-02 14:24, Nevin Liber wrote:
> On 2 October 2014 13:17, Matthew Woehlke wrote:
>> That said... it looks like it isn't possible to pass an asio buffer to a
>> non-templated algorithm. That, as far as I am concerned, makes it nigh
>> unusable as a basic I/O library. Also, "not generic".
>
> My colleague, who is quite familiar with Asio and it's internals, says
> "this is completely false".
>
> Buffers have a concrete type, const_buffer and mutable_buffer, buffer
> *Sequences* are taken by template parameters.

I may be using terminology poorly. See my comments about One True Buffer
Type. It may work due to strong decoupling of the buffer and device
where the device drives the buffer(?). (In order to have the buffer
drive the device you'd need method pointers, which goes back to my "you
say bound method, I say virtual method" point.)

That only works for asynchronous I/O. There are all kinds of reasons why
that shouldn't become the *only* option for doing I/O... which puts us
back in the "we need (something that looks like) virtual methods" category.

--
Matthew

--

---
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/.

.

On 2014-10-02 17:27, Nevin Liber wrote:
> There is no One True Buffer Type in Boost.Asio.
>
> A const_buffer is:
>
> const_buffer
> {
>   // ...
>
>   const void* data_;
>   std::size_t size_;
> };

Looks suspiciously like a True Buffer Type to me. The point is, this
works because the thing that gets passed to algorithms (the buffer)
doesn't know how to read or write data.

> Your entire argument against Asio is basically a straw man, as evidenced by
> your statement "I'm not familiar with boost::asio".  If you aren't familiar
> with it, how can you argue for or against it's abstractions?

The arguments you refer to are not against boost::asio as such, but
against asynchronous I/O *in general*. I do have some familiarity with
that, thank you.

Anyway I consider that rather beside the point. If you have a way to
pass an I/O object to an algorithm that allows that algorithm to
*synchronously* read and/or write data without any knowledge of how
those operations are actually implemented (i.e. device agnosticism),
that *doesn't* use virtual methods or something similar, I'd love to see it.

--
Matthew

--

---
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/.

.