Topic: std::num_get/put overloads
Author: David Krauss <potswa@gmail.com>
Date: Wed, 13 Aug 2014 14:08:25 +0800
Raw View
--Apple-Mail=_497C877C-8ED0-470D-9D8F-6E3453C2AA58
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
<locale>, and therefore <iostream>, specifically provides for numeric I/O o=
ver the set of standard, non-character integer types. __int128_t support or=
std::int8_t would be a non-conforming extension. This is too strict. All i=
nteger types should be supported.
The functions which implement the parsing are virtual, but not pure virtual=
, so there's no risk of making user-derived classes abstract. Implicit inte=
ger conversions don't work due to overload ambiguity, so no user code alrea=
dy passes arguments not covered by the existing overloads (e.g., char).
It's true that user-derived classes would not be able to portably provide i=
dentical coverage, and C locale behavior would surprisingly result from pas=
sing an unsupported argument, but locale facet derivation is quite an unpop=
ular paradigm.
Is there anything else that could break?
--=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=_497C877C-8ED0-470D-9D8F-6E3453C2AA58
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;"><font face=3D"Courier"=
><locale></font>, and therefore <font face=3D"Courier"><iostream&g=
t;</font>, specifically provides for numeric I/O over the set of standard, =
non-character integer types. <font face=3D"Courier">__int128_t</font> suppo=
rt or <font face=3D"Courier">std::int8_t</font> would be a non-conforming e=
xtension. This is too strict. All integer types should be supported.<div><b=
r></div><div>The functions which implement the parsing are virtual, but not=
pure virtual, so there’s no risk of making user-derived classes abst=
ract. Implicit integer conversions don’t work due to overload ambigui=
ty, so no user code already passes arguments not covered by the existing ov=
erloads (e.g., <font face=3D"Courier">char</font>).</div><div><br></div><di=
v>It’s true that user-derived classes would not be able to portably p=
rovide identical coverage, and C locale behavior would surprisingly result =
from passing an unsupported argument, but locale facet derivation is quite =
an unpopular paradigm.</div><div><br></div><div>Is there anything else that=
could break?</div><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" 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=_497C877C-8ED0-470D-9D8F-6E3453C2AA58--
.