Topic: Ideas about next gen iostreams library
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 15 Feb 2019 07:58:29 +1000
Raw View
--000000000000fb80500581e1c258
Content-Type: text/plain; charset="UTF-8"
There are numerous complaints about iostreams, not the least of which is
around performance.
Here is a quick sketch of an approach/framework for adding a new iostreams
library:
1. We define two new concepts InputStream and OutputStream with the
required functionality of new iostreams library streams.
2. For backward compatibility, we extend std::istream and std::ostream as
required (without ABI breakage) such that they implement these concepts.
3. Types can define how they are streamed in terms of the concepts from
(1). Something like:
struct S { int x; float f; };
constexpr OutputStream& operator<<(OutputStream auto& o, S s) {
return o << s.x << ':' << s.f;
}
(Notice that because of (2), the designer of S doesn't have to define a
separate std::ostream& version of operator<<)
4. We define new classes that are fast (and/or compile-time)
implementations of InputStream and OutputStream for stdin/stdout, strings,
files and so on. Up until bikeshedding like std::new_cout,
std::new_ostringstream, std::new_ofstream etc.
How is this sounding so far? Thoughts?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail.gmail.com.
--000000000000fb80500581e1c258
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There are numerous complaints about iostreams, not the lea=
st of which is around performance.<div><br></div><div>Here is a quick sketc=
h of an approach/framework for adding a new iostreams library:</div><div><b=
r></div><div>1. We define two new concepts InputStream and OutputStream wit=
h the required functionality of new iostreams library streams.<br><div><br>=
</div></div><div>2. For backward compatibility, we extend std::istream and =
std::ostream as required (without ABI breakage) such that they implement th=
ese concepts.</div><div><br></div><div>3. Types can define how they are str=
eamed in terms of the concepts from (1).=C2=A0 Something like:</div><div><b=
r></div><div>struct S { int x; float f; };</div><div><br></div><div>constex=
pr OutputStream& operator<<(OutputStream auto& o, S s) {</div=
><div>=C2=A0 =C2=A0return o << s.x << ':' << s.f;=
</div><div>}</div><div><br></div><div>(Notice that because of (2), the desi=
gner of S doesn't have to define a separate std::ostream& version o=
f operator<<)</div><div><br></div><div>4. We define new classes that =
are fast (and/or compile-time) implementations of InputStream and OutputStr=
eam for stdin/stdout, strings, files and so on.=C2=A0 Up until bikeshedding=
like std::new_cout, std::new_ostringstream, std::new_ofstream etc.</div><d=
iv><br></div><div>How is this sounding so far?=C2=A0 Thoughts?</div><div><b=
r></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9J=
gvW5%3D1AgoepEsL6GdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%=
2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail.gmail.com</a>.<br />
--000000000000fb80500581e1c258--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 14 Feb 2019 17:11:02 -0500
Raw View
--000000000000d629f90581e1efdb
Content-Type: text/plain; charset="UTF-8"
On Thu, Feb 14, 2019 at 4:58 PM Andrew Tomazos <andrewtomazos@gmail.com>
wrote:
> There are numerous complaints about iostreams, not the least of which is
> around performance.
>
> Here is a quick sketch of an approach/framework for adding a new iostreams
> library:
>
> 1. We define two new concepts InputStream and OutputStream with the
> required functionality of new iostreams library streams.
>
> 2. For backward compatibility, we extend std::istream and std::ostream as
> required (without ABI breakage) such that they implement these concepts.
>
> 3. Types can define how they are streamed in terms of the concepts from
> (1). Something like:
>
> struct S { int x; float f; };
>
> constexpr OutputStream& operator<<(OutputStream auto& o, S s) {
> return o << s.x << ':' << s.f;
> }
>
>
OK, this looks similar to what I do now, so I guess that makes it easy to
adopt.
(Notice that because of (2), the designer of S doesn't have to define a
> separate std::ostream& version of operator<<)
>
> 4. We define new classes that are fast (and/or compile-time)
> implementations of InputStream and OutputStream for stdin/stdout, strings,
> files and so on. Up until bikeshedding like std::new_cout,
> std::new_ostringstream, std::new_ofstream etc.
>
>
Given that the above looks the same as how iostreams work, how will these
new things be faster, and why can't current iostreams be just as fast?
Is there some about the above syntax or Concepts that "unlocks" this
newfound speed, or is the syntax and concepts orthogonal to speed
improvements?
> How is this sounding so far? Thoughts?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivA%3D82RyE%3DyvFqAF_tZCqaBnjsVZP75BrQF43-0SnAiOQ%40mail.gmail.com.
--000000000000d629f90581e1efdb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 14, 2019 at 4:58 PM Andre=
w Tomazos <<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmai=
l.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr">There are numerous complaints about iostreams, not th=
e least of which is around performance.<div><br></div><div>Here is a quick =
sketch of an approach/framework for adding a new iostreams library:</div><d=
iv><br></div><div>1. We define two new concepts InputStream and OutputStrea=
m with the required functionality of new iostreams library streams.<br><div=
><br></div></div><div>2. For backward compatibility, we extend std::istream=
and std::ostream as required (without ABI breakage) such that they impleme=
nt these concepts.</div><div><br></div><div>3. Types can define how they ar=
e streamed in terms of the concepts from (1).=C2=A0 Something like:</div><d=
iv><br></div><div>struct S { int x; float f; };</div><div><br></div><div>co=
nstexpr OutputStream& operator<<(OutputStream auto& o, S s) {=
</div><div>=C2=A0 =C2=A0return o << s.x << ':' <<=
s.f;</div><div>}</div><div><br></div></div></blockquote><div><br></div><di=
v>OK, this looks similar to what I do now, so I guess that makes it easy to=
adopt.</div><div><br></div><div> <br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div></div><div>(Notice that because of=
(2), the designer of S doesn't have to define a separate std::ostream&=
amp; version of operator<<)</div><div><br></div><div>4. We define new=
classes that are fast (and/or compile-time) implementations of InputStream=
and OutputStream for stdin/stdout, strings, files and so on.=C2=A0 Up unti=
l bikeshedding like std::new_cout, std::new_ostringstream, std::new_ofstrea=
m etc.</div><div><br></div></div></blockquote><div><br></div><div>Given tha=
t the above looks the same as how iostreams work, how will these new things=
be faster, and why can't current iostreams be just as fast?</div><div>=
Is there some about the above syntax or Concepts that "unlocks" t=
his newfound speed, or is the syntax and concepts orthogonal to speed impro=
vements?</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div></div><div>How is this sounding =
so far?=C2=A0 Thoughts?</div><div><br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9J=
gvW5%3D1AgoepEsL6GdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail=
..gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div=
></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivA%3D82RyE%3DyvFqAF_tZCqaBnjsV=
ZP75BrQF43-0SnAiOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivA%3D8=
2RyE%3DyvFqAF_tZCqaBnjsVZP75BrQF43-0SnAiOQ%40mail.gmail.com</a>.<br />
--000000000000d629f90581e1efdb--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 15 Feb 2019 08:19:36 +1000
Raw View
--00000000000074d0a70581e20e52
Content-Type: text/plain; charset="UTF-8"
On Fri, Feb 15, 2019 at 8:11 AM Tony V E <tvaneerd@gmail.com> wrote:
>
>
> On Thu, Feb 14, 2019 at 4:58 PM Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>> There are numerous complaints about iostreams, not the least of which is
>> around performance.
>>
>> Here is a quick sketch of an approach/framework for adding a new
>> iostreams library:
>>
>> 1. We define two new concepts InputStream and OutputStream with the
>> required functionality of new iostreams library streams.
>>
>> 2. For backward compatibility, we extend std::istream and std::ostream as
>> required (without ABI breakage) such that they implement these concepts.
>>
>> 3. Types can define how they are streamed in terms of the concepts from
>> (1). Something like:
>>
>> struct S { int x; float f; };
>>
>> constexpr OutputStream& operator<<(OutputStream auto& o, S s) {
>> return o << s.x << ':' << s.f;
>> }
>>
>>
> OK, this looks similar to what I do now, so I guess that makes it easy to
> adopt.
>
>
> (Notice that because of (2), the designer of S doesn't have to define a
>> separate std::ostream& version of operator<<)
>>
>> 4. We define new classes that are fast (and/or compile-time)
>> implementations of InputStream and OutputStream for stdin/stdout, strings,
>> files and so on. Up until bikeshedding like std::new_cout,
>> std::new_ostringstream, std::new_ofstream etc.
>>
>>
> Given that the above looks the same as how iostreams work, how will these
> new things be faster, and why can't current iostreams be just as fast?
> Is there some about the above syntax or Concepts that "unlocks" this
> newfound speed, or is the syntax and concepts orthogonal to speed
> improvements?
>
std::ostream is a concrete type that uses run-time polymorphism, so my
understanding was that creating a more primitive concept OutputStream would
enable us to inline and remove run-time polymorphism overhead from the
interface. Is this not correct?
Separately, it also gives us the opportunity to make "breaking" changes to
the stream interface for the new iostreams library, without breaking
existing code.
>
>
>
>> How is this sounding so far? Thoughts?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> Be seeing you,
> Tony
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivA%3D82RyE%3DyvFqAF_tZCqaBnjsVZP75BrQF43-0SnAiOQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivA%3D82RyE%3DyvFqAF_tZCqaBnjsVZP75BrQF43-0SnAiOQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLG1rjwQX3hxbMVhphpAV0XJ2WwVdTBeCfOSybV2uz1Hw%40mail.gmail.com.
--00000000000074d0a70581e20e52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 15, 2019 at 8:11 AM Tony =
V E <<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Thu, Feb 14, 2019 at 4:58 PM Andrew Tomazos &=
lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomaz=
os@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr">There are numerous complaints about iostreams,=
not the least of which is around performance.<div><br></div><div>Here is a=
quick sketch of an approach/framework for adding a new iostreams library:<=
/div><div><br></div><div>1. We define two new concepts InputStream and Outp=
utStream with the required functionality of new iostreams library streams.<=
br><div><br></div></div><div>2. For backward compatibility, we extend std::=
istream and std::ostream as required (without ABI breakage) such that they =
implement these concepts.</div><div><br></div><div>3. Types can define how =
they are streamed in terms of the concepts from (1).=C2=A0 Something like:<=
/div><div><br></div><div>struct S { int x; float f; };</div><div><br></div>=
<div>constexpr OutputStream& operator<<(OutputStream auto& o,=
S s) {</div><div>=C2=A0 =C2=A0return o << s.x << ':' &=
lt;< s.f;</div><div>}</div><div><br></div></div></blockquote><div><br></=
div><div>OK, this looks similar to what I do now, so I guess that makes it =
easy to adopt.</div><div><br></div><div> <br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div>(Notice that bec=
ause of (2), the designer of S doesn't have to define a separate std::o=
stream& version of operator<<)</div><div><br></div><div>4. We def=
ine new classes that are fast (and/or compile-time) implementations of Inpu=
tStream and OutputStream for stdin/stdout, strings, files and so on.=C2=A0 =
Up until bikeshedding like std::new_cout, std::new_ostringstream, std::new_=
ofstream etc.</div><div><br></div></div></blockquote><div><br></div><div>Gi=
ven that the above looks the same as how iostreams work, how will these new=
things be faster, and why can't current iostreams be just as fast?</di=
v><div>Is there some about the above syntax or Concepts that "unlocks&=
quot; this newfound speed, or is the syntax and concepts orthogonal to spee=
d improvements?</div></div></div></blockquote><div><br></div><div>std::ostr=
eam is a concrete type that uses run-time polymorphism, so my understanding=
was that creating a more primitive concept OutputStream would enable us to=
inline and remove run-time polymorphism overhead from the interface.=C2=A0=
Is this not correct?</div><div><br></div><div>Separately, it also gives us=
the opportunity to make "breaking" changes to the stream interfa=
ce for the new iostreams library, without breaking existing code.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_quote"><div><br></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div>How=
is this sounding so far?=C2=A0 Thoughts?</div><div><br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9J=
gvW5%3D1AgoepEsL6GdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAB%2B4KHK%2BYKUVDGxtc-hW80jZTBtwPh9JgvW5%3D1AgoepEsL6GdA%40mail=
..gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail-m_3087843075168930643gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivA%3D82RyE%3DyvFqAF_tZCqaBnjsV=
ZP75BrQF43-0SnAiOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAOHCbivA%3D82RyE%3DyvFqAF_tZCqaBnjsVZP75BrQF43-0SnAiOQ%40mail.gma=
il.com</a>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLG1rjwQX3hxbMVhphpAV0XJ2WwVd=
TBeCfOSybV2uz1Hw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLG1rjw=
QX3hxbMVhphpAV0XJ2WwVdTBeCfOSybV2uz1Hw%40mail.gmail.com</a>.<br />
--00000000000074d0a70581e20e52--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 16 Feb 2019 19:35:17 -0800 (PST)
Raw View
------=_Part_196_513944184.1550374517245
Content-Type: multipart/alternative;
boundary="----=_Part_197_148037320.1550374517245"
------=_Part_197_148037320.1550374517245
Content-Type: text/plain; charset="UTF-8"
On Thursday, February 14, 2019 at 5:19:51 PM UTC-5, Andrew Tomazos wrote:
>
>
>
> On Fri, Feb 15, 2019 at 8:11 AM Tony V E <tvan...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Thu, Feb 14, 2019 at 4:58 PM Andrew Tomazos <andrew...@gmail.com
>> <javascript:>> wrote:
>>
>>> There are numerous complaints about iostreams, not the least of which is
>>> around performance.
>>>
>>> Here is a quick sketch of an approach/framework for adding a new
>>> iostreams library:
>>>
>>> 1. We define two new concepts InputStream and OutputStream with the
>>> required functionality of new iostreams library streams.
>>>
>>> 2. For backward compatibility, we extend std::istream and std::ostream
>>> as required (without ABI breakage) such that they implement these concepts.
>>>
>>> 3. Types can define how they are streamed in terms of the concepts from
>>> (1). Something like:
>>>
>>> struct S { int x; float f; };
>>>
>>> constexpr OutputStream& operator<<(OutputStream auto& o, S s) {
>>> return o << s.x << ':' << s.f;
>>> }
>>>
>>>
>> OK, this looks similar to what I do now, so I guess that makes it easy to
>> adopt.
>>
>>
>> (Notice that because of (2), the designer of S doesn't have to define a
>>> separate std::ostream& version of operator<<)
>>>
>>> 4. We define new classes that are fast (and/or compile-time)
>>> implementations of InputStream and OutputStream for stdin/stdout, strings,
>>> files and so on. Up until bikeshedding like std::new_cout,
>>> std::new_ostringstream, std::new_ofstream etc.
>>>
>>>
>> Given that the above looks the same as how iostreams work, how will these
>> new things be faster, and why can't current iostreams be just as fast?
>> Is there some about the above syntax or Concepts that "unlocks" this
>> newfound speed, or is the syntax and concepts orthogonal to speed
>> improvements?
>>
>
> std::ostream is a concrete type that uses run-time polymorphism, so my
> understanding was that creating a more primitive concept OutputStream would
> enable us to inline and remove run-time polymorphism overhead from the
> interface. Is this not correct?
>
Isn't that a question you ought to have the answer to? You are proposing
that we make a new version of the API; it makes sense that step 1 of that
process is to figure out what exactly went wrong with the old one.
It is conventional wisdom that the entire iostreams stack is slow and
cannot be implemented in a not-slow way. But I don't really trust
conventional wisdom, not when it comes to trying to remake something. I've
seen claims that it's due to polymorphism, but those are just claims, not
facts. It could be due to having locale stuff built-in and effectively
required. It could be due to a poor interface in the stream buffer type. Or
some combination of all of these factors.
I don't really understand much about the streambuf-based API, so I can't go
about providing an implementation of it or to do some assembly analysis to
find out where the performance is really going. But until a proper autopsy
is done, I think it would be premature to entertain any particular
"improved" design aesthetic.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0b218a47-3cb7-4482-949a-32339d0df0f2%40isocpp.org.
------=_Part_197_148037320.1550374517245
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, February 14, 2019 at 5:19:51 PM UTC-5=
, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">On Fri, Feb 15, 2019 at 8:11 AM Tony V E <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"FURp_DTRGgAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">tvan...@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Thu, Feb 14, 2019 at 4:58 PM Andrew Tomazos <<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FURp_DTRGgAJ" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">andrew...@gmail.co=
m</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr">There are numerous complaints about iostreams, not the le=
ast of which is around performance.<div><br></div><div>Here is a quick sket=
ch of an approach/framework for adding a new iostreams library:</div><div><=
br></div><div>1. We define two new concepts InputStream and OutputStream wi=
th the required functionality of new iostreams library streams.<br><div><br=
></div></div><div>2. For backward compatibility, we extend std::istream and=
std::ostream as required (without ABI breakage) such that they implement t=
hese concepts.</div><div><br></div><div>3. Types can define how they are st=
reamed in terms of the concepts from (1).=C2=A0 Something like:</div><div><=
br></div><div>struct S { int x; float f; };</div><div><br></div><div>conste=
xpr OutputStream& operator<<(OutputStream auto& o, S s) {</di=
v><div>=C2=A0 =C2=A0return o << s.x << ':' << s.f=
;</div><div>}</div><div><br></div></div></blockquote><div><br></div><div>OK=
, this looks similar to what I do now, so I guess that makes it easy to ado=
pt.</div><div><br></div><div> <br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><div>(Notice that because of (2)=
, the designer of S doesn't have to define a separate std::ostream&=
version of operator<<)</div><div><br></div><div>4. We define new cla=
sses that are fast (and/or compile-time) implementations of InputStream and=
OutputStream for stdin/stdout, strings, files and so on.=C2=A0 Up until bi=
keshedding like std::new_cout, std::new_ostringstream, std::new_ofstream et=
c.</div><div><br></div></div></blockquote><div><br></div><div>Given that th=
e above looks the same as how iostreams work, how will these new things be =
faster, and why can't current iostreams be just as fast?</div><div>Is t=
here some about the above syntax or Concepts that "unlocks" this =
newfound speed, or is the syntax and concepts orthogonal to speed improveme=
nts?</div></div></div></blockquote><div><br></div><div>std::ostream is a co=
ncrete type that uses run-time polymorphism, so my understanding was that c=
reating a more primitive concept OutputStream would enable us to inline and=
remove run-time polymorphism overhead from the interface.=C2=A0 Is this no=
t correct?</div></div></div></blockquote><div><br></div><div>Isn't that=
a question you ought to have the answer to? You are proposing that we make=
a new version of the API; it makes sense that step 1 of that process is to=
figure out what exactly went wrong with the old one.<br><br>It is conventi=
onal wisdom that the entire iostreams stack is slow and cannot be implement=
ed in a not-slow way. But I don't really trust conventional wisdom, not=
when it comes to trying to remake something. I've seen claims that it&=
#39;s due to polymorphism, but those are just claims, not facts. It could b=
e due to having locale stuff built-in and effectively required. It could be=
due to a poor interface in the stream buffer type. Or some combination of =
all of these factors.<br><br>I don't really understand much about the s=
treambuf-based API, so I can't go about providing an implementation of =
it or to do some assembly analysis to find out where the performance is rea=
lly going. But until a proper autopsy is done, I think it would be prematur=
e to entertain any particular "improved" design aesthetic.</div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0b218a47-3cb7-4482-949a-32339d0df0f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0b218a47-3cb7-4482-949a-32339d0df0f2=
%40isocpp.org</a>.<br />
------=_Part_197_148037320.1550374517245--
------=_Part_196_513944184.1550374517245--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 17 Feb 2019 13:59:56 +1000
Raw View
--000000000000578dd305820f0b76
Content-Type: text/plain; charset="UTF-8"
On Sun, Feb 17, 2019 at 1:35 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Thursday, February 14, 2019 at 5:19:51 PM UTC-5, Andrew Tomazos wrote:
>>
>>
>>
>> On Fri, Feb 15, 2019 at 8:11 AM Tony V E <tvan...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Feb 14, 2019 at 4:58 PM Andrew Tomazos <andrew...@gmail.com>
>>> wrote:
>>>
>>>> There are numerous complaints about iostreams, not the least of which
>>>> is around performance.
>>>>
>>>> Here is a quick sketch of an approach/framework for adding a new
>>>> iostreams library:
>>>>
>>>> 1. We define two new concepts InputStream and OutputStream with the
>>>> required functionality of new iostreams library streams.
>>>>
>>>> 2. For backward compatibility, we extend std::istream and std::ostream
>>>> as required (without ABI breakage) such that they implement these concepts.
>>>>
>>>> 3. Types can define how they are streamed in terms of the concepts from
>>>> (1). Something like:
>>>>
>>>> struct S { int x; float f; };
>>>>
>>>> constexpr OutputStream& operator<<(OutputStream auto& o, S s) {
>>>> return o << s.x << ':' << s.f;
>>>> }
>>>>
>>>>
>>> OK, this looks similar to what I do now, so I guess that makes it easy
>>> to adopt.
>>>
>>>
>>> (Notice that because of (2), the designer of S doesn't have to define a
>>>> separate std::ostream& version of operator<<)
>>>>
>>>> 4. We define new classes that are fast (and/or compile-time)
>>>> implementations of InputStream and OutputStream for stdin/stdout, strings,
>>>> files and so on. Up until bikeshedding like std::new_cout,
>>>> std::new_ostringstream, std::new_ofstream etc.
>>>>
>>>>
>>> Given that the above looks the same as how iostreams work, how will
>>> these new things be faster, and why can't current iostreams be just as fast?
>>> Is there some about the above syntax or Concepts that "unlocks" this
>>> newfound speed, or is the syntax and concepts orthogonal to speed
>>> improvements?
>>>
>>
>> std::ostream is a concrete type that uses run-time polymorphism, so my
>> understanding was that creating a more primitive concept OutputStream would
>> enable us to inline and remove run-time polymorphism overhead from the
>> interface. Is this not correct?
>>
>
> Isn't that a question you ought to have the answer to? You are proposing
> that we make a new version of the API; it makes sense that step 1 of that
> process is to figure out what exactly went wrong with the old one.
>
> It is conventional wisdom that the entire iostreams stack is slow and
> cannot be implemented in a not-slow way.
>
Did you mean "CAN be implemented in a not-slow way" ?
> But I don't really trust conventional wisdom, not when it comes to trying
> to remake something. I've seen claims that it's due to polymorphism, but
> those are just claims, not facts. It could be due to having locale stuff
> built-in and effectively required. It could be due to a poor interface in
> the stream buffer type. Or some combination of all of these factors.
>
> I don't really understand much about the streambuf-based API, so I can't
> go about providing an implementation of it or to do some assembly analysis
> to find out where the performance is really going. But until a proper
> autopsy is done, I think it would be premature to entertain any particular
> "improved" design aesthetic.
>
I've seen performance tests. I think it is because of run-time
polymorphism (dispatch and suppressing inlining) and locales. Yes, if this
proceeded further, it should be confirmed and proven.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHJU%2B-BJoowT-k4ek-C1qOn8ayEKG1-Vwaruu3kj8QOV%2BQ%40mail.gmail.com.
--000000000000578dd305820f0b76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 17, 2019 at 1:35 PM Nicol=
Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><br><br>On Thursday, February 14, 2019 at 5:19:51 PM UTC-5, Andr=
ew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Fri, Feb 15, 2019 at 8:11 AM Tony V E <<a rel=3D"nofollow">t=
van...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Thu, Feb 14, 2019 at 4:58 PM Andrew To=
mazos <<a rel=3D"nofollow">andrew...@gmail.com</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">There are=
numerous complaints about iostreams, not the least of which is around perf=
ormance.<div><br></div><div>Here is a quick sketch of an approach/framework=
for adding a new iostreams library:</div><div><br></div><div>1. We define =
two new concepts InputStream and OutputStream with the required functionali=
ty of new iostreams library streams.<br><div><br></div></div><div>2. For ba=
ckward compatibility, we extend std::istream and std::ostream as required (=
without ABI breakage) such that they implement these concepts.</div><div><b=
r></div><div>3. Types can define how they are streamed in terms of the conc=
epts from (1).=C2=A0 Something like:</div><div><br></div><div>struct S { in=
t x; float f; };</div><div><br></div><div>constexpr OutputStream& opera=
tor<<(OutputStream auto& o, S s) {</div><div>=C2=A0 =C2=A0return =
o << s.x << ':' << s.f;</div><div>}</div><div><br=
></div></div></blockquote><div><br></div><div>OK, this looks similar to wha=
t I do now, so I guess that makes it easy to adopt.</div><div><br></div><di=
v> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div></div><div>(Notice that because of (2), the designer of S doesn&#=
39;t have to define a separate std::ostream& version of operator<<=
;)</div><div><br></div><div>4. We define new classes that are fast (and/or =
compile-time) implementations of InputStream and OutputStream for stdin/std=
out, strings, files and so on.=C2=A0 Up until bikeshedding like std::new_co=
ut, std::new_ostringstream, std::new_ofstream etc.</div><div><br></div></di=
v></blockquote><div><br></div><div>Given that the above looks the same as h=
ow iostreams work, how will these new things be faster, and why can't c=
urrent iostreams be just as fast?</div><div>Is there some about the above s=
yntax or Concepts that "unlocks" this newfound speed, or is the s=
yntax and concepts orthogonal to speed improvements?</div></div></div></blo=
ckquote><div><br></div><div>std::ostream is a concrete type that uses run-t=
ime polymorphism, so my understanding was that creating a more primitive co=
ncept OutputStream would enable us to inline and remove run-time polymorphi=
sm overhead from the interface.=C2=A0 Is this not correct?</div></div></div=
></blockquote><div><br></div><div>Isn't that a question you ought to ha=
ve the answer to? You are proposing that we make a new version of the API; =
it makes sense that step 1 of that process is to figure out what exactly we=
nt wrong with the old one.<br><br>It is conventional wisdom that the entire=
iostreams stack is slow and cannot be implemented in a not-slow way.</div>=
</div></blockquote><div><br></div><div>Did you mean "CAN be implemente=
d in a not-slow way" ?</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>But I don't really trust=
conventional wisdom, not when it comes to trying to remake something. I=
9;ve seen claims that it's due to polymorphism, but those are just clai=
ms, not facts. It could be due to having locale stuff built-in and effectiv=
ely required. It could be due to a poor interface in the stream buffer type=
.. Or some combination of all of these factors.<br></div></div></blockquote>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>I don't really understand much about the streambuf-based =
API, so I can't go about providing an implementation of it or to do som=
e assembly analysis to find out where the performance is really going. But =
until a proper autopsy is done, I think it would be premature to entertain =
any particular "improved" design aesthetic.</div></div></blockquo=
te><div><br></div><div>I've seen performance tests.=C2=A0 I think it is=
because of run-time polymorphism (dispatch and suppressing inlining) and l=
ocales.=C2=A0 Yes, if this proceeded further, it should be confirmed and pr=
oven.</div><div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHJU%2B-BJoowT-k4ek-C1qOn8ayEK=
G1-Vwaruu3kj8QOV%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHJU=
%2B-BJoowT-k4ek-C1qOn8ayEKG1-Vwaruu3kj8QOV%2BQ%40mail.gmail.com</a>.<br />
--000000000000578dd305820f0b76--
.