------=_Part_1744_548891612.1463995049516
Content-Type: multipart/alternative;
 boundary="----=_Part_1745_1136072123.1463995049516"

------=_Part_1745_1136072123.1463995049516
Content-Type: text/plain; charset=UTF-8

Hi,

I have frequently seen people inheriting from STL classes like std::string
or std::vector which usually is discouraged because of the lack of virtual
destructors (and virtual functions). Wouldn't it make sense to make all
classes in the STL which are not designed for inheritance final?

Cheers,
  Jens

--
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/435754c7-b507-473d-9d6e-491f3a298ed1%40isocpp.org.

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

<div dir=3D"ltr">Hi,<br><br>I have frequently seen people inheriting from S=
TL classes like std::string or std::vector which usually is discouraged bec=
ause of the lack of virtual destructors (and virtual functions). Wouldn&#39=
;t it make sense to make all classes in the STL which are not designed for =
inheritance final?<br><br>Cheers,<br>=C2=A0 Jens<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/435754c7-b507-473d-9d6e-491f3a298ed1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/435754c7-b507-473d-9d6e-491f3a298ed1=
%40isocpp.org</a>.<br />

------=_Part_1745_1136072123.1463995049516--

------=_Part_1744_548891612.1463995049516--

.

On 23 May 2016 at 12:17, jensa <jens.muaddib@gmail.com> wrote:
> Hi,
>
> I have frequently seen people inheriting from STL classes like std::string
> or std::vector which usually is discouraged because of the lack of virtual
> destructors (and virtual functions). Wouldn't it make sense to make all
> classes in the STL which are not designed for inheritance final?

No, because that breaks existing code where people wrap such types
without treating
them polymorphically. See
http://synesis.com.au/resources/articles/cpp/veneers.pdf.
It also makes it impossible to privately inherit such types, which has
much less to do
with virtual functions. So no, it doesn't make sense.

--
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/CAFk2RUY4UHJcE3ncMt9M%2BDx%2Br2iWbP%3Db0OE9JE33%3DOPrQ65yNw%40mail.gmail.com.

.

------=_Part_639_19241300.1464016472940
Content-Type: multipart/alternative;
 boundary="----=_Part_640_1291919370.1464016472941"

------=_Part_640_1291919370.1464016472941
Content-Type: text/plain; charset=UTF-8

`final` is not really to prevent people from deriving from non-polymorphic
types. Indeed, deriving from non-polymorphic types is perfectly fine, so
long as you know what you're doing.

`final` is primarily intended for polymorphic types, when you have a
derived class where it is fundamentally unreasonable for someone to derive
from it to modify its polymorphic interface. This would ensure that when
someone receives an instance of a derived class by type, they know exactly
what behavior they're going to get.

`final` would be far more appropriate for classes like `basic_ifstream`.
That would ensure that if you get a `basic_ifstream` class, you know you're
writing to a file.

Of course, we shouldn't do that. Not just because it would break existing
code for little gain. But because I lied when I said what that would do.
Thanks to `basic_istream::rdbuf`, you can *replace* the file buffer with
any buffer type you desire, so in fact you can't know that a
`basic_ifstream` class is writing to a file just from the type.

Which kinda makes the whole `basic_ifstream` class pretty pointless, and is
yet another reason why iostream is terribly designed...

--
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/68532dde-853a-449f-9f00-02383f4705db%40isocpp.org.

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

<div dir=3D"ltr">`final` is not really to prevent people from deriving from=
 non-polymorphic types. Indeed, deriving from non-polymorphic types is perf=
ectly fine, so long as you know what you&#39;re doing.<br><br>`final` is pr=
imarily intended for polymorphic types, when you have a derived class where=
 it is fundamentally unreasonable for someone to derive from it to modify i=
ts polymorphic interface. This would ensure that when someone receives an i=
nstance of a derived class by type, they know exactly what behavior they&#3=
9;re going to get.<br><br>`final` would be far more appropriate for classes=
 like `basic_ifstream`. That would ensure that if you get a `basic_ifstream=
` class, you know you&#39;re writing to a file.<br><br>Of course, we should=
n&#39;t do that. Not just because it would break existing code for little g=
ain. But because I lied when I said what that would do. Thanks to `basic_is=
tream::rdbuf`, you can <i>replace</i> the file buffer with any buffer type =
you desire, so in fact you can&#39;t know that a `basic_ifstream` class is =
writing to a file just from the type.<br><br>Which kinda makes the whole `b=
asic_ifstream` class pretty pointless, and is yet another reason why iostre=
am is terribly designed...<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/68532dde-853a-449f-9f00-02383f4705db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/68532dde-853a-449f-9f00-02383f4705db=
%40isocpp.org</a>.<br />

------=_Part_640_1291919370.1464016472941--

------=_Part_639_19241300.1464016472940--

.

--Apple-Mail-9B729992-3DF6-4691-8912-6A0D2D0E6AAF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



> On 23 May 2016, at 16:14, Nicol Bolas <jmckesson@gmail.com> wrote:
> Of course, we shouldn't do that. Not just because it would break existing=
 code for little gain. But because I lied when I said what that would do. T=
hanks to `basic_istream::rdbuf`, you can replace the file buffer with any b=
uffer type you desire, so in fact you can't know that a `basic_ifstream` cl=
ass is writing to a file just from the type.
>=20
> Which kinda makes the whole `basic_ifstream` class pretty pointless, and =
is yet another reason why iostream is terribly designed...

It is a truly terrible design that IOstreams separated the reader interface=
 (std::istream) and the source inteface (std::streambuf) and also provided =
a way to construct a concrete entity thereof (std::ifstream)! Likewise for =
output and combined input/output (*). Other languages much more reasonably =
do exactly the same but do not provide the convenience interface to create =
both of the entities together in ways they are often used. Oh, wait - it ac=
tually makes IOstreams much more convenient to use for the typical use case=
s while not sacrificing any of the flexibility.

There are problems with IOstreams but this "terrible design" you critize is=
 actually not one of them.

(*) I do realize that the streams are also templatized on the character typ=
e. That is, however, not a fault of stream but rather a fault of the idea t=
o have different character types. Supporting streams for multiple character=
 types is merely the logical consequence.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/AA43FBA2-61AA-4D8F-9DE6-99812FA1F3F0%40gmail.com=
..

--Apple-Mail-9B729992-3DF6-4691-8912-6A0D2D0E6AAF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div><br>On 2=
3 May 2016, at 16:14, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com=
">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote type=3D"cite"><di=
v><div dir=3D"ltr">Of course, we shouldn't do that. Not just because it wou=
ld break existing code for little gain. But because I lied when I said what=
 that would do. Thanks to `basic_istream::rdbuf`, you can <i>replace</i> th=
e file buffer with any buffer type you desire, so in fact you can't know th=
at a `basic_ifstream` class is writing to a file just from the type.<br><br=
>Which kinda makes the whole `basic_ifstream` class pretty pointless, and i=
s yet another reason why iostream is terribly designed...</div>
</div></blockquote><br><div>It is a truly terrible design that IOstreams se=
parated the reader interface (std::istream) and the source inteface (std::s=
treambuf) and also provided a way to construct a concrete entity thereof (s=
td::ifstream)! Likewise for output and combined input/output (*). Other lan=
guages much more reasonably do exactly the same but do not provide the conv=
enience interface to create both of the entities together in ways they are =
often used. Oh, wait - it actually makes IOstreams much more convenient to =
use for the typical use cases while not sacrificing any of the flexibility.=
</div><div><br></div><div>There are problems with IOstreams but this "terri=
ble design" you critize is actually not one of them.</div><div><br></div><d=
iv>(*) I do realize that the streams are also templatized on the character =
type. That is, however, not a fault of stream but rather a fault of the ide=
a to have different character types. Supporting streams for multiple charac=
ter types is merely the logical consequence.</div></body></html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/AA43FBA2-61AA-4D8F-9DE6-99812FA1F3F0%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/AA43FBA2-61AA-4D8F-9DE6-99812FA1F3F0%=
40gmail.com</a>.<br />

--Apple-Mail-9B729992-3DF6-4691-8912-6A0D2D0E6AAF--

.

------=_Part_2066_7044909.1464030813253
Content-Type: multipart/alternative;
 boundary="----=_Part_2067_808096358.1464030813253"

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

On Monday, May 23, 2016 at 2:34:41 PM UTC-4, Dietmar K=C3=BChl wrote:
>
> On 23 May 2016, at 16:14, Nicol Bolas <jmck...@gmail.com <javascript:>>=
=20
> wrote:
>
> Of course, we shouldn't do that. Not just because it would break existing=
=20
> code for little gain. But because I lied when I said what that would do.=
=20
> Thanks to `basic_istream::rdbuf`, you can *replace* the file buffer with=
=20
> any buffer type you desire, so in fact you can't know that a=20
> `basic_ifstream` class is writing to a file just from the type.
>
> Which kinda makes the whole `basic_ifstream` class pretty pointless, and=
=20
> is yet another reason why iostream is terribly designed...
>
>
> It is a truly terrible design that IOstreams separated the reader=20
> interface (std::istream) and the source inteface (std::streambuf) and als=
o=20
> provided a way to construct a concrete entity thereof (std::ifstream)!
>

That's not the design I was referring to. I was referring to the fact that=
=20
`istream` forces every derived class to be able to use any stream buffer,=
=20
whether it wants to or not. There is nothing about the separation of stream=
=20
from buffer that requires that every stream type be able to work with any=
=20
buffer instance *dynamically*.

Among the many consequences of this is that calling any virtual functions=
=20
on an `istream`-derived class is always at least two virtual calls: the=20
virtual call into `istream` and the virtual call(s) from `istream` into=20
`streambuf`.

There's no reason for a type that is ostensibly for file access=20
(`ifstream`) to be able to be used with non-file buffer types. This=20
"flexibility" is not only pointless (have you ever written code that does=
=20
that?), but it's basically lying to the user.

Likewise for output and combined input/output (*). Other languages much=20
> more reasonably do exactly the same but do not provide the convenience=20
> interface to create both of the entities together in ways they are often=
=20
> used. Oh, wait - it actually makes IOstreams much more convenient to use=
=20
> for the typical use cases while not sacrificing any of the flexibility.
>

While simultaneously breaking C++'s cardinal design ethic: don't pay for=20
what you don't use. If you want a stream type that allows you to=20
dynamically attach it to different buffers, fine. But that shouldn't be=20
built into *every stream*. There should have been `istream` and=20
`dyn_istream`, with the latter allowing the user to provide a stream. The=
=20
former would only allow the stream to be created internally.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7922fc81-53b1-4866-8c8c-5a5c7c10c61d%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, May 23, 2016 at 2:34:41 PM UTC-4, Dietmar K=C3=
=BChl wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto">=
<div></div><div>On 23 May 2016, at 16:14, Nicol Bolas &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-K7yMlXcDQAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&=
gt; wrote:<br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">Of cour=
se, we shouldn&#39;t do that. Not just because it would break existing code=
 for little gain. But because I lied when I said what that would do. Thanks=
 to `basic_istream::rdbuf`, you can <i>replace</i> the file buffer with any=
 buffer type you desire, so in fact you can&#39;t know that a `basic_ifstre=
am` class is writing to a file just from the type.<br><br>Which kinda makes=
 the whole `basic_ifstream` class pretty pointless, and is yet another reas=
on why iostream is terribly designed...</div>
</div></blockquote><br><div>It is a truly terrible design that IOstreams se=
parated the reader interface (std::istream) and the source inteface (std::s=
treambuf) and also provided a way to construct a concrete entity thereof (s=
td::ifstream)!</div></div></blockquote><div><br>That&#39;s not the design I=
 was referring to. I was referring to the fact that `istream` forces every =
derived class to be able to use any stream buffer, whether it wants to or n=
ot. There is nothing about the separation of stream from buffer that requir=
es that every stream type be able to work with any buffer instance <i>dynam=
ically</i>.<br><br>Among the many consequences of this is that calling any =
virtual functions on an `istream`-derived class is always at least two virt=
ual calls: the virtual call into `istream` and the virtual call(s) from `is=
tream` into `streambuf`.<br><br>There&#39;s no reason for a type that is os=
tensibly for file access (`ifstream`) to be able to be used with non-file b=
uffer types. This &quot;flexibility&quot; is not only pointless (have you e=
ver written code that does that?), but it&#39;s basically lying to the user=
..<br><br></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"aut=
o"><div>Likewise for output and combined input/output (*). Other languages =
much more reasonably do exactly the same but do not provide the convenience=
 interface to create both of the entities together in ways they are often u=
sed. Oh, wait - it actually makes IOstreams much more convenient to use for=
 the typical use cases while not sacrificing any of the flexibility.</div><=
/div></blockquote><div><br>While simultaneously breaking C++&#39;s cardinal=
 design ethic: don&#39;t pay for what you don&#39;t use. If you want a stre=
am type that allows you to dynamically attach it to different buffers, fine=
.. But that shouldn&#39;t be built into <i>every stream</i>. There should ha=
ve been `istream` and `dyn_istream`, with the latter allowing the user to p=
rovide a stream. The former would only allow the stream to be created inter=
nally.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7922fc81-53b1-4866-8c8c-5a5c7c10c61d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7922fc81-53b1-4866-8c8c-5a5c7c10c61d=
%40isocpp.org</a>.<br />

------=_Part_2067_808096358.1464030813253--

------=_Part_2066_7044909.1464030813253--

.

--Apple-Mail-693AD8FA-7402-45C4-B5CB-D4D8F6308387
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



> On 23 May 2016, at 20:13, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
>> On Monday, May 23, 2016 at 2:34:41 PM UTC-4, Dietmar K=C3=BChl wrote:
>>> On 23 May 2016, at 16:14, Nicol Bolas <jmck...@gmail.com> wrote:
>>> Of course, we shouldn't do that. Not just because it would break existi=
ng code for little gain. But because I lied when I said what that would do.=
 Thanks to `basic_istream::rdbuf`, you can replace the file buffer with any=
 buffer type you desire, so in fact you can't know that a `basic_ifstream` =
class is writing to a file just from the type.
>>>=20
>>> Which kinda makes the whole `basic_ifstream` class pretty pointless, an=
d is yet another reason why iostream is terribly designed...
>>=20
>> It is a truly terrible design that IOstreams separated the reader interf=
ace (std::istream) and the source inteface (std::streambuf) and also provid=
ed a way to construct a concrete entity thereof (std::ifstream)!
>=20
> That's not the design I was referring to. I was referring to the fact tha=
t `istream` forces every derived class to be able to use any stream buffer,=
 whether it wants to or not. There is nothing about the separation of strea=
m from buffer that requires that every stream type be able to work with any=
 buffer instance dynamically.
>=20
> Among the many consequences of this is that calling any virtual functions=
 on an `istream`-derived class is always at least two virtual calls: the vi=
rtual call into `istream` and the virtual call(s) from `istream` into `stre=
ambuf`.
>=20
> There's no reason for a type that is ostensibly for file access (`ifstrea=
m`) to be able to be used with non-file buffer types. This "flexibility" is=
 not only pointless (have you ever written code that does that?), but it's =
basically lying to the user.
>=20
>> Likewise for output and combined input/output (*). Other languages much =
more reasonably do exactly the same but do not provide the convenience inte=
rface to create both of the entities together in ways they are often used. =
Oh, wait - it actually makes IOstreams much more convenient to use for the =
typical use cases while not sacrificing any of the flexibility.
>=20
> While simultaneously breaking C++'s cardinal design ethic: don't pay for =
what you don't use. If you want a stream type that allows you to dynamicall=
y attach it to different buffers, fine. But that shouldn't be built into ev=
ery stream. There should have been `istream` and `dyn_istream`, with the la=
tter allowing the user to provide a stream. The former would only allow the=
 stream to be created internally.

Which of the std::istream functions is virtual exactly? (other than the des=
tuctor) Since it is desirable to have just one stream type, having a concre=
te class actually makes sense. Whether the buffer should be changable may b=
e questionable but since the stream buffer can be of any type anyway there =
is actually nothing gained by removing the ability to inject a filter.

If you feel criticising thing please make at least an attempt to have a loo=
k at what is actually done.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5F8DD636-C2EA-4F79-9FFA-ACF4252AFC98%40gmail.com=
..

--Apple-Mail-693AD8FA-7402-45C4-B5CB-D4D8F6308387
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div><br>On 2=
3 May 2016, at 20:13, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com=
">jmckesson@gmail.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"=
><div><div dir=3D"ltr">On Monday, May 23, 2016 at 2:34:41 PM UTC-4, Dietmar=
 K=C3=BChl wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div></div><div>On 23 May 2016, at 16:14, Nicol Bolas &lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-K7yMlXcDQAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>&gt; wrote=
:<br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">Of course, we sh=
ouldn't do that. Not just because it would break existing code for little g=
ain. But because I lied when I said what that would do. Thanks to `basic_is=
tream::rdbuf`, you can <i>replace</i> the file buffer with any buffer type =
you desire, so in fact you can't know that a `basic_ifstream` class is writ=
ing to a file just from the type.<br><br>Which kinda makes the whole `basic=
_ifstream` class pretty pointless, and is yet another reason why iostream i=
s terribly designed...</div>
</div></blockquote><br><div>It is a truly terrible design that IOstreams se=
parated the reader interface (std::istream) and the source inteface (std::s=
treambuf) and also provided a way to construct a concrete entity thereof (s=
td::ifstream)!</div></div></blockquote><div><br>That's not the design I was=
 referring to. I was referring to the fact that `istream` forces every deri=
ved class to be able to use any stream buffer, whether it wants to or not. =
There is nothing about the separation of stream from buffer that requires t=
hat every stream type be able to work with any buffer instance <i>dynamical=
ly</i>.<br><br>Among the many consequences of this is that calling any virt=
ual functions on an `istream`-derived class is always at least two virtual =
calls: the virtual call into `istream` and the virtual call(s) from `istrea=
m` into `streambuf`.<br><br>There's no reason for a type that is ostensibly=
 for file access (`ifstream`) to be able to be used with non-file buffer ty=
pes. This "flexibility" is not only pointless (have you ever written code t=
hat does that?), but it's basically lying to the user.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div>Likewise for o=
utput and combined input/output (*). Other languages much more reasonably d=
o exactly the same but do not provide the convenience interface to create b=
oth of the entities together in ways they are often used. Oh, wait - it act=
ually makes IOstreams much more convenient to use for the typical use cases=
 while not sacrificing any of the flexibility.</div></div></blockquote><div=
><br>While simultaneously breaking C++'s cardinal design ethic: don't pay f=
or what you don't use. If you want a stream type that allows you to dynamic=
ally attach it to different buffers, fine. But that shouldn't be built into=
 <i>every stream</i>. There should have been `istream` and `dyn_istream`, w=
ith the latter allowing the user to provide a stream. The former would only=
 allow the stream to be created internally.</div></div>
</div></blockquote><br><div>Which of the std::istream functions is virtual =
exactly? (other than the destuctor) Since it is desirable to have just one =
stream type, having a concrete class actually makes sense. Whether the buff=
er should be changable may be questionable but since the stream buffer can =
be of any type anyway there is actually nothing gained by removing the abil=
ity to inject a filter.</div><div><br></div><div>If you feel criticising th=
ing please make at least an attempt to have a look at what is actually done=
..</div></body></html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5F8DD636-C2EA-4F79-9FFA-ACF4252AFC98%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5F8DD636-C2EA-4F79-9FFA-ACF4252AFC98%=
40gmail.com</a>.<br />

--Apple-Mail-693AD8FA-7402-45C4-B5CB-D4D8F6308387--

.