Topic: Some words about a printf(3)-like interface
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 16 Dec 2012 00:11:21 -0600
Raw View
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
There is a big gap between a runtime string specification and the
compile-time type safety. And it becomes even harder to achieve both
when we need some "extensibility".
Anyway, let me just post my implementation of a printf(3)-like
interface on top of the C++ stream library here, for people who may
want to continue the "failure of iostreams" discussion but lacking a
good-enough example.
https://github.com/lichray/formatxx
Design choice: type-safety > standard-compliance > extensibility
Standard compliance checklist:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
* [CX] Arguments reordering "%n$" no
* Parameterized width and precision "%*.*f" not-yet
* [CX] The thousands' grouping flag "%'d" no
* The empty sign flag "% d" yes!
* The integer length specification "%.10d" yes!
* The length modifiers "%hd" ignored
* Hex float specifiers "%a" and "%A" limited by C++!
* Length output specifier "%n" not-yet, or just no
* [XSI] Wide char specifiers "%S" and "%C" as "%s" and "%c"
Items marked "yes" and all other specifications in the POSIX standard
are fully supported but limited to the fundamental types and
std::basic_string; items marked "no" won't be supported; the ones end
with "!" are not supported by Boost.Format. Precision on hex float
is ignored according to the C++ standard.
Any invalid, unsupported specifications will cause an invalid_argument
exception to be thrown at runtime; same for less/more arguments.
Type-safe conversions:
* signed to unsigned "%u"
* char_type to int_type "%d" "%i" "%u"
* int_type to char_type "%c"
These conversions are there for achieving reasonable representations.
Other behaviors, like "all specifications fallback to operator<<", are
the same as Boost.Format.
That's it. Suggestions, comments are welcome.
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBAgAGBQJQzWYJAAoJEDM1qsGtFE5ZQ4gH/3CW0qkhaCzvOsVdvTByELRc
IgzoQR1+HS7AvWRUQyAVw21zRh0Mt7q1OvQrarfXXQpPQyGmL1H4BJIxi27uwi7M
8MMzSDD1Fprs2Y6fE+s+2h9KhyBbDsllAK+KfxsM2v7BbPi89kTdLjUZrmW1z8b5
dR8GrDNj8N6BIHvbTLx7GXerQlFKDtnb6+0ytkm4kWLkm6cbLhIara9sICKYFkBo
ZaNb5UgamneXx032yUXNi7jD0H7SfdVon4I5CLY0qDjfvTP4/jcJOEnLHO/Eos4T
F5csPlA+HOX0pSHpYVGcqTF8W5RLi2h3gH/QtL6iiV6PMBmNtisuIGQV0YLe4iQ=
=smr3
-----END PGP SIGNATURE-----
--XsQoSWH+UP9D9v3l--
.
Author: stackmachine@hotmail.com
Date: Sun, 16 Dec 2012 06:08:26 -0800 (PST)
Raw View
------=_Part_270_9607766.1355666906124
Content-Type: text/plain; charset=ISO-8859-1
The idea of type-specifiers in the format string is just utterly broken. We
need new format strings with new, C++-like formatting options.
I've made a possible implementation some time ago here:
https://ideone.com/6Eoj9C
A single '%' represents the current argument, '%<n>' represents the nth
argument, %x, %o and %d act like iostream manipulators.
--
------=_Part_270_9607766.1355666906124
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The idea of type-specifiers in the format string is just utterly broken. We=
need new format strings with new, C++-like formatting options.<br>I've mad=
e a possible implementation some time ago here: <a href=3D"https://ideone.c=
om/6Eoj9C">https://ideone.com/6Eoj9C</a><br>A single '%' represents the cur=
rent argument, '%<n>' represents the nth argument, %x, %o and %d act =
like iostream manipulators.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_270_9607766.1355666906124--
.
Author: Herb Sutter <hsutter@microsoft.com>
Date: Sun, 16 Dec 2012 17:23:13 +0000
Raw View
--_000_c00661df25a54221923a673d1e1ecb72BN1PR03MB086namprd03pro_
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Yes, what everyone understands is that we want the type-safe type extensibi=
lity of iostreams with the convenience of printf formatting. (Put the negat=
ive way, we want "iostreams without iomanip" and "printf without type speci=
fiers.")
Have you seen/tried Boost.Format<http://www.boost.org/doc/libs/1_52_0/libs/=
format/doc/format.html>? AFAIK the only complaint is that the implementatio=
n is slow, which is not necessarily tied to the interface.
I would strongly encourage someone to propose Boost.Format for standardizat=
ion. To improve iostreams dramatically, IMO we need to do two things, and t=
his addresses one of them: make iomanip obsolete. (The other thing is to dr=
op the overhead of iostreams, which AIUI means: drop locale support or make=
it optional.)
Herb
From: stackmachine@hotmail.com [mailto:stackmachine@hotmail.com]
Sent: Sunday, December 16, 2012 6:08 AM
To: std-proposals@isocpp.org
Subject: [std-proposals] Re: Some words about a printf(3)-like interface
The idea of type-specifiers in the format string is just utterly broken. We=
need new format strings with new, C++-like formatting options.
I've made a possible implementation some time ago here: https://ideone.com/=
6Eoj9C
A single '%' represents the current argument, '%<n>' represents the nth arg=
ument, %x, %o and %d act like iostream manipulators.
--
--=20
--_000_c00661df25a54221923a673d1e1ecb72BN1PR03MB086namprd03pro_
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
..MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Yes, what everyone unders=
tands is that we want the type-safe type extensibility of iostreams with th=
e convenience of printf formatting. (Put the negative way,
we want “iostreams without iomanip” and “printf without =
type specifiers.”)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Have you seen/tried
<a href=3D"http://www.boost.org/doc/libs/1_52_0/libs/format/doc/format.html=
">Boost.Format</a>? AFAIK the only complaint is that the implementation is =
slow, which is not necessarily tied to the interface.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">I would strongly encourag=
e someone to propose Boost.Format for standardization. To improve iostreams=
dramatically, IMO we need to do two things, and this addresses
one of them: make iomanip obsolete. (The other thing is to drop the overhe=
ad of iostreams, which AIUI means: drop locale support or make it optional.=
)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Herb<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"=
;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:"Tahoma","sans-serif""> stackmac=
hine@hotmail.com [mailto:stackmachine@hotmail.com]
<br>
<b>Sent:</b> Sunday, December 16, 2012 6:08 AM<br>
<b>To:</b> std-proposals@isocpp.org<br>
<b>Subject:</b> [std-proposals] Re: Some words about a printf(3)-like inter=
face<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">The idea of type-specifiers in the format string is =
just utterly broken. We need new format strings with new, C++-like =
formatting options.<br>
I've made a possible implementation some time ago here: <a href=3D"https://=
ideone.com/6Eoj9C">
https://ideone.com/6Eoj9C</a><br>
A single '%' represents the current argument, '%<n>' represents the n=
th argument, %x, %o and %d act like iostream manipulators.<o:p></o:p></p>
<p class=3D"MsoNormal">-- <br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--_000_c00661df25a54221923a673d1e1ecb72BN1PR03MB086namprd03pro_--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 16 Dec 2012 12:19:41 -0600
Raw View
On Sun, Dec 16, 2012 at 11:23 AM, Herb Sutter <hsutter@microsoft.com> wrote=
:
> Yes, what everyone understands is that we want the type-safe type
> extensibility of iostreams with the convenience of printf formatting. (Pu=
t
> the negative way, we want =93iostreams without iomanip=94 and =93printf w=
ithout
> type specifiers.=94)
For me, even "%s" for everything is better, like what we seen in Python :)
> Have you seen/tried Boost.Format? AFAIK the only complaint is that the
> implementation is slow, which is not necessarily tied to the interface.
My version uses an one-time parsing + outputting, without any intermediate
storage (and that's why my version does not support arguments reordering),
which should make it reasonably faster than Boost.Format. However, extra
function calls and parsing overhead are not avoidable.
> I would strongly encourage someone to propose Boost.Format for
> standardization. To improve iostreams dramatically, IMO we need to do two
> things, and this addresses one of them: make iomanip obsolete.
Currently I found 3 problems:
1. How to report ill-formed arguments?
My choice is to throw exceptions; Boost.Format has an .exceptions() member.
To add an "formatbit" to basic_ios?
2. printf(3) compatibility?
Some printf(3) formatting can't be achieved in iostream without extra copyi=
ng.
Finally we may need to extend iostream itself!
3. scanf(3)?
Useless, but hard to reject.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sun, 16 Dec 2012 10:55:52 -0800 (PST)
Raw View
------=_Part_328_5711417.1355684152765
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 16, 2012 6:23:13 PM UTC+1, Herb Sutter wrote:
> Have you seen/tried Boost.Format<http://www.boost.org/doc/libs/1_52_0/libs/format/doc/format.html>?
> AFAIK the only complaint is that the implementation is slow, which is not
> necessarily tied to the interface.
>
char c = 65;
string s = (boost::format("%d") % c).str(); // as-is
string s2 = boost::format("%d", c); // desired (by me)
IMO the interface isn't great, with C++11 you can do better.
It's depends on iostream too much, the above example outputs 'A' AFAIK, it
should output 65 instead.
Output probably depends on locales too, which is also unwanted.
Olaf
--
------=_Part_328_5711417.1355684152765
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, December 16, 2012 6:23:13 PM UTC+1, Herb Sutter wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
Calibri, sans-serif; font-size: 11pt;">Have you seen/tried
</span><a href=3D"http://www.boost.org/doc/libs/1_52_0/libs/format/doc/form=
at.html" target=3D"_blank" style=3D"font-family: Calibri, sans-serif; font-=
size: 11pt;">Boost.Format</a><span style=3D"color: rgb(31, 73, 125); font-f=
amily: Calibri, sans-serif; font-size: 11pt;">? AFAIK the only complaint is=
that the implementation is slow, which is not necessarily tied to the inte=
rface.</span></p></div></div></blockquote><div>char c =3D 65;</div><div>str=
ing s =3D (boost::format("%d") % c).str(); // as-is</div><div>string s2 =3D=
boost::format("%d", c); // desired (by me)</div><div><br></div><div>IMO th=
e interface isn't great, with C++11 you can do better.</div><div>It's depen=
ds on iostream too much, the above example outputs 'A' AFAIK, it should out=
put 65 instead. </div><div>Output probably depends on locales too, whi=
ch is also unwanted.</div><div><br></div><div>Olaf</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_328_5711417.1355684152765--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 16 Dec 2012 13:27:17 -0600
Raw View
On Sun, Dec 16, 2012 at 12:55 PM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> char c = 65;
> string s = (boost::format("%d") % c).str(); // as-is
> string s2 = boost::format("%d", c); // desired (by me)
>
> IMO the interface isn't great, with C++11 you can do better.
> It's depends on iostream too much, the above example outputs 'A' AFAIK, it
> should output 65 instead.
#include "putf.h"
#include <iostream>
using std::string;
using stdex::putf;
using stdex::sputf;
int main() {
char c = 65;
string s = sputf("%d", c);
std::cout << s << std::endl; // 65, char_type -> int_type
std::cout << putf("%c\n", 65); // A, reversed.
}
> Output probably depends on locales too, which is also unwanted.
Locale won't changes your input; it may only change something like the
decimal point '.'. And you need to turned it on, anyway.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Sun, 16 Dec 2012 11:32:16 -0800 (PST)
Raw View
------=_Part_435_9591965.1355686336708
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 16, 2012 12:11:21 AM UTC-6, Zhihao Yuan wrote:
>
> There is a big gap between a runtime string specification and the
> compile-time type safety. And it becomes even harder to achieve both
> when we need some "extensibility".
>
> Anyway, let me just post my implementation of a printf(3)-like
> interface on top of the C++ stream library here, for people who may
> want to continue the "failure of iostreams" discussion but lacking a
> good-enough example.
>
> https://github.com/lichray/formatxx
>
> Design choice: type-safety > standard-compliance > extensibility
>
> Standard compliance checklist:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
>
> * [CX] Arguments reordering "%n$" no
> * Parameterized width and precision "%*.*f" not-yet
> * [CX] The thousands' grouping flag "%'d" no
> * The empty sign flag "% d" yes!
> * The integer length specification "%.10d" yes!
> * The length modifiers "%hd" ignored
> * Hex float specifiers "%a" and "%A" limited by C++!
> * Length output specifier "%n" not-yet, or just no
> * [XSI] Wide char specifiers "%S" and "%C" as "%s" and "%c"
>
> Items marked "yes" and all other specifications in the POSIX standard
> are fully supported but limited to the fundamental types and
> std::basic_string; items marked "no" won't be supported; the ones end
> with "!" are not supported by Boost.Format. Precision on hex float
> is ignored according to the C++ standard.
>
> Any invalid, unsupported specifications will cause an invalid_argument
> exception to be thrown at runtime; same for less/more arguments.
>
> Type-safe conversions:
>
> * signed to unsigned "%u"
> * char_type to int_type "%d" "%i" "%u"
> * int_type to char_type "%c"
>
> These conversions are there for achieving reasonable representations.
>
> Other behaviors, like "all specifications fallback to operator<<", are
> the same as Boost.Format.
>
> That's it. Suggestions, comments are welcome.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
Have you consider implementations that pass arguments via boost::fusion
(e.g. make_vector) or std::tuple, so that you can have a printf call that:
1. Has access to the type of each argument -- so that the specifier only
provides additional formatting instructions and errors can be
thrown/returned on mis-match, and so that you can use specialization to
allow printing of custom types...
2. The container provides a count of the arguments -- so that you can
throw/return (maybe static assert?) an error on too many / too few
(Someone out on Stack Overflow even posted a partial implementation of
this, but it can be vastly improved and simplified. See the dprintf
example:
http://stackoverflow.com/questions/455904/print-information-in-test-mode-but-not-in-normal-execution
)
I may be missing something, but in my experience the problems with printf
are those two specific things: Mis-matched parameters by type and number.
Also, if I can make a recommendation... Don't perpetuate the HORRIBLE %S
vs. %s. Microsoft did the right thing with %hs and %ls. This way they
mean the same thing regardless of whether or not the
format string is wide or not... I've seen countless mistakes with %S/%s.
I also agree that in general boost::format is a good solution, but I'd like
to see a printf/sprintf/fprintf/sscanf, etc. solution that was type safe
and could be a drop in replacement with static asserts for the millions of
lines of C++ code out there that already use this for legacy reasons.
-Andrew Sandoval
--
------=_Part_435_9591965.1355686336708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, December 16, 2012 12:11:21 AM UTC-6, Zhihao Yuan wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">There is a big gap between a runtime st=
ring specification and the
<br>compile-time type safety. And it becomes even harder to achieve b=
oth
<br>when we need some "extensibility".
<br>
<br>Anyway, let me just post my implementation of a printf(3)-like
<br>interface on top of the C++ stream library here, for people who may
<br>want to continue the "failure of iostreams" discussion but lacking a
<br>good-enough example.
<br>
<br><a href=3D"https://github.com/lichray/formatxx" target=3D"_blank">https=
://github.com/lichray/<wbr>formatxx</a>
<br>
<br>Design choice: type-safety > standard-compliance > extensibility
<br>
<br>Standard compliance checklist:
<br>
<br><a href=3D"http://pubs.opengroup.org/onlinepubs/9699919799/functions/pr=
intf.html" target=3D"_blank">http://pubs.opengroup.org/<wbr>onlinepubs/9699=
919799/<wbr>functions/printf.html</a>
<br>
<br> * [CX] Arguments reordering "%n$" &=
nbsp; no
<br> * Parameterized width and precision "%*.*f" &nbs=
p; not-yet
<br> * [CX] The thousands' grouping flag "%'d" =
no
<br> * The empty sign flag "% d" &n=
bsp;  =
; yes!
<br> * The integer length specification "%.10d"  =
; yes!
<br> * The length modifiers "%hd" &=
nbsp; &nbs=
p; <wbr>ignored
<br> * Hex float specifiers "%a" and "%A"  =
; limited =
by C++!
<br> * Length output specifier "%n"  =
; &n=
bsp; <wbr>not-yet, or just no
<br> * [XSI] Wide char specifiers "%S" and "%C"  =
; as "%s" and "%c"
<br>
<br>Items marked "yes" and all other specifications in the POSIX standard
<br>are fully supported but limited to the fundamental types and
<br>std::basic_string; items marked "no" won't be supported; the ones end
<br>with "!" are not supported by Boost.Format. Precision on hex floa=
t
<br>is ignored according to the C++ standard.
<br>
<br>Any invalid, unsupported specifications will cause an invalid_argument
<br>exception to be thrown at runtime; same for less/more arguments.
<br>
<br>Type-safe conversions:
<br>
<br> * signed to unsigned "%u"
<br> * char_type to int_type "%d" "%i" "%u"
<br> * int_type to char_type "%c"
<br>
<br>These conversions are there for achieving reasonable representations.
<br>
<br>Other behaviors, like "all specifications fallback to operator<<"=
, are
<br>the same as Boost.Format.
<br>
<br>That's it. Suggestions, comments are welcome.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote><div><br>Have you consider implementations that pass argum=
ents via boost::fusion (e.g. make_vector) or std::tuple, so that you can ha=
ve a printf call that:<br><ol><li>Has access to the type of each argument -=
- so that the specifier only provides additional formatting instructions an=
d errors can be thrown/returned on mis-match, and so that you can use speci=
alization to allow printing of custom types...<br></li><li>The container pr=
ovides a count of the arguments -- so that you can throw/return (maybe stat=
ic assert?) an error on too many / too few</li></ol><p>(Someone out on Stac=
k Overflow even posted a partial implementation of this, but it can be vast=
ly improved and simplified. See the dprintf example: <a href=3D"http:=
//stackoverflow.com/questions/455904/print-information-in-test-mode-but-not=
-in-normal-execution">http://stackoverflow.com/questions/455904/print-infor=
mation-in-test-mode-but-not-in-normal-execution</a>)</p><p><br></p><p>I may=
be missing something, but in my experience the problems with printf are th=
ose two specific things: Mis-matched parameters by type and number.</=
p><p></p><p>Also, if I can make a recommendation... Don't perpetuate =
the HORRIBLE %S vs. %s. Microsoft did the right thing with %hs and %l=
s. This way they mean the same thing regardless of whether or not the=
<br></p><p>format string is wide or not... I've seen countless mista=
kes with %S/%s.</p><p><br></p><p>I also agree that in general boost::format=
is a good solution, but I'd like to see a printf/sprintf/fprintf/sscanf, e=
tc. solution that was type safe and could be a drop in replacement with sta=
tic asserts for the millions of lines of C++ code out there that already us=
e this for legacy reasons.</p><p><br></p><p>-Andrew Sandoval<br></p><p><br>=
</p></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_435_9591965.1355686336708--
.
Author: Herb Sutter <hsutter@microsoft.com>
Date: Sun, 16 Dec 2012 19:48:20 +0000
Raw View
> > I would strongly encourage someone to propose Boost.Format for
I should have said "as a starting point for standardization" and/or "someth=
ing like Boost.Format." The main idea is we need to get POSIX/printf style =
formatting like all modern languages -- iomanip is a noble experiment that =
is nearly unused in the marketplace as far as I'm aware, and if so it has c=
learly failed.
BTW, one reason I think this is important is that formatting I/O is one of =
the first things you hit when teaching novices, and iomanip is embarrassing=
for anything requiring even basic formatting.
> (and that's why my version does not support arguments reordering),
My impression is that argument reordering is important for internationaliza=
tion -- the parameters may appear in different positions in different langu=
ages. Is it correct that it's universally desirable =3D=3D important enough=
to have by default?
Herb
> -----Original Message-----
> From: Zhihao Yuan [mailto:lichray@gmail.com]
> Sent: Sunday, December 16, 2012 10:20 AM
> To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Re: Some words about a printf(3)-like interf=
ace
>=20
> On Sun, Dec 16, 2012 at 11:23 AM, Herb Sutter <hsutter@microsoft.com>
> wrote:
> > Yes, what everyone understands is that we want the type-safe type
> > extensibility of iostreams with the convenience of printf formatting.
> > (Put the negative way, we want "iostreams without iomanip" and "printf
> > without type specifiers.")
>=20
> For me, even "%s" for everything is better, like what we seen in Python :=
)
>=20
> > Have you seen/tried Boost.Format? AFAIK the only complaint is that the
> > implementation is slow, which is not necessarily tied to the interface.
>=20
> My version uses an one-time parsing + outputting, without any intermediat=
e
> storage (and that's why my version does not support arguments reordering)=
,
> which should make it reasonably faster than Boost.Format. However, extra
> function calls and parsing overhead are not avoidable.
>=20
> > I would strongly encourage someone to propose Boost.Format for
> > standardization. To improve iostreams dramatically, IMO we need to do
> > two things, and this addresses one of them: make iomanip obsolete.
>=20
> Currently I found 3 problems:
>=20
> 1. How to report ill-formed arguments?
> My choice is to throw exceptions; Boost.Format has an .exceptions()
> member.
> To add an "formatbit" to basic_ios?
>=20
> 2. printf(3) compatibility?
> Some printf(3) formatting can't be achieved in iostream without extra
> copying.
> Finally we may need to extend iostream itself!
>=20
> 3. scanf(3)?
> Useless, but hard to reject.
>=20
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>=20
> --
>=20
>=20
>=20
>=20
--=20
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 16 Dec 2012 13:52:56 -0600
Raw View
On Sun, Dec 16, 2012 at 1:32 PM, Andrew Sandoval
<sandoval@netwaysglobal.com> wrote:
> Have you consider implementations that pass arguments via boost::fusion
> (e.g. make_vector) or std::tuple, so that you can have a printf call that:
I used std::tuple.
cout << putf("%d %u %s", -1, -1, "-1"); // arguments 1-n as a tuple
of T const&...
> Has access to the type of each argument -- so that the specifier only
> provides additional formatting instructions and errors can be
> thrown/returned on mis-match, and so that you can use specialization to
> allow printing of custom types...
That's all what I did.
> The container provides a count of the arguments -- so that you can
> throw/return (maybe static assert?) an error on too many / too few
I used exceptions. Return value is occupied. static_assert is impossible, since
the format specification is parsed at runtime.
> I may be missing something, but in my experience the problems with printf
> are those two specific things: Mis-matched parameters by type and number.
Very, hard, to decide. An additional "formatbit" (for .exceptions())
might help.
> Also, if I can make a recommendation... Don't perpetuate the HORRIBLE %S
> vs. %s.
I left %S -> %s (along with other length modifiers) as an
compatibility interface
to printf(3). I'd like to drop all of them :)
BTW, if Beman's String Interoperation Library get passed, we can do better.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3398.html
Thanks for your comments!
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 16 Dec 2012 14:14:11 -0600
Raw View
On Sun, Dec 16, 2012 at 1:48 PM, Herb Sutter <hsutter@microsoft.com> wrote:
>> (and that's why my version does not support arguments reordering),
>
> My impression is that argument reordering is important for internationalization -- the parameters may appear in different positions in different languages. Is it correct that it's universally desirable == important enough to have by default?
Yea, true. I forgot, although I wrote a program with catgets(3) before.
But I have to say, std::tuple<T const&...> is probably the only way to preserve
T...'s type, eg, something like a std::vector<reference_wrapper<T const>> is
impossibly. But, as you can see, for %n$, n is read at runtime, which can't be
served as an argument to get<N>(tuple)! Variadic template is a whole compile
time thing, unlike operator% or C's va_arg.
It's only doable if we limit the maximum n (NL_ARGMAX) to 9, like SysV, and
leave some poisoned specializations. I don't really like this approach anyway.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 16 Dec 2012 14:44:15 -0600
Raw View
On Sun, Dec 16, 2012 at 2:14 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> It's only doable if we limit the maximum n (NL_ARGMAX) to 9, like SysV, and
> leave some poisoned specializations. I don't really like this approach anyway.
Should be "It's only doable if we want a performance comparable to iomanip.",
since Boost.Format support the arbitrary reordering with a
std::vector<format_item_t> -- to store all of the format information
into a data-
structure -- reordering format instead of arguments -- this results in a big
runtime performance penalty, even the reordering is not used. My choice is to
print while parsing, so I only considered how to reorder the arguments.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Sun, 16 Dec 2012 23:12:23 +0100
Raw View
--047d7b15a1ef247f5904d0ff8ff5
Content-Type: text/plain; charset=ISO-8859-1
Hi,
On Sun, Dec 16, 2012 at 8:52 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> > The container provides a count of the arguments -- so that you can
> > throw/return (maybe static assert?) an error on too many / too few
>
> I used exceptions. Return value is occupied. static_assert is impossible,
> since
> the format specification is parsed at runtime.
>
This is might be a dumb question but isn't it possible to do such parsing
using constexpr?
See:
http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-part-i/
Joel Lamotte
--
--047d7b15a1ef247f5904d0ff8ff5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_extra">Hi,<br><br><div class=3D"gmail_quote">On Sun, De=
c 16, 2012 at 8:52 PM, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"mailto:=
lichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex">
<div class=3D"im">> The container provides a count of the arguments -- s=
o that you can<br>
> throw/return (maybe static assert?) an error on too many / too few<br>
<br>
</div>I used exceptions. =A0Return value is occupied. static_assert is impo=
ssible, since<br>
the format specification is parsed at runtime.<br>
<div class=3D"im"></div></blockquote></div><br></div><div class=3D"gmail_ex=
tra">This is might be a dumb question but isn't it possible to do such =
parsing using constexpr?=A0<br>See:=A0<a href=3D"http://akrzemi1.wordpress.=
com/2011/05/11/parsing-strings-at-compile-time-part-i/">http://akrzemi1.wor=
dpress.com/2011/05/11/parsing-strings-at-compile-time-part-i/</a></div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Joel Lamott=
e</div><div class=3D"gmail_extra"><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
--047d7b15a1ef247f5904d0ff8ff5--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 16 Dec 2012 16:31:28 -0600
Raw View
On Sun, Dec 16, 2012 at 4:12 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:
> This is might be a dumb question but isn't it possible to do such parsing
> using constexpr?
> See:
> http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-=
part-i/
Emm, this is possible. And safe. My only concern is that, does it make th=
e
compilation too slow? A variadic template is already slow enough. And,
though I +1 for a compile-time only specification, how about the (potential=
)
users?
I'm going to implement one in this approach anyway, for fun, at least. Tha=
nks
for your link!
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
.
Author: Martin Desharnais <martin.desharnais@gmail.com>
Date: Sun, 16 Dec 2012 17:34:59 -0800 (PST)
Raw View
------=_Part_775_14003370.1355708099292
Content-Type: text/plain; charset=ISO-8859-1
One might be interested to take a look at folly::format() (from
facebook[1]).
// Format supports printf-style format specifiers
std::cout << format("{0:05d} decimal = {0:04x} hex", 42);
// => "00042 decimal = 002a hex"
It is pretty similar to Boost.Format but have, in my opinion, a simpler
interface.
[1] https://github.com/facebook/folly/blob/master/folly/docs/Format.md
--
------=_Part_775_14003370.1355708099292
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
One might be interested to take a look at folly::format() (from facebook[1]=
).<br><br><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 18=
7, 187); background-color: rgb(250, 250, 250); word-wrap: break-word;"><cod=
e class=3D"prettyprint"></code><div class=3D"subprettyprint"><pre><span cla=
ss=3D"c1"><span style=3D"color: rgb(136, 0, 0);" class=3D"styled-by-prettif=
y">// Format supports printf-style format specifiers</span></span><span sty=
le=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span><span c=
lass=3D"n"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify=
">std</span></span><span class=3D"o"><span style=3D"color: rgb(102, 102, 0)=
;" class=3D"styled-by-prettify">::</span></span><span class=3D"n"><span sty=
le=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">cout</span></span>=
<span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><=
span class=3D"o"><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-b=
y-prettify"><<</span></span><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"styled-by-prettify"> </span><span class=3D"n"><span style=3D"color: rg=
b(0, 0, 0);" class=3D"styled-by-prettify">format</span></span><span class=
=3D"p"><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify=
">(</span></span><span class=3D"s"><span style=3D"color: rgb(0, 136, 0);" c=
lass=3D"styled-by-prettify">"{0:05d} decimal =3D {0:04x} hex"</span></span>=
<span class=3D"p"><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-=
by-prettify">,</span></span><span style=3D"color: rgb(0, 0, 0);" class=3D"s=
tyled-by-prettify"> </span><span class=3D"mi"><span style=3D"color: rgb(0, =
102, 102);" class=3D"styled-by-prettify">42</span></span><span class=3D"p">=
<span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);</s=
pan></span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify=
"><br></span><span class=3D"c1"><span style=3D"color: rgb(136, 0, 0);" clas=
s=3D"styled-by-prettify">// =3D> "00042 decimal =3D 002a hex"</span></sp=
an><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></=
span></pre></div></div><br>It is pretty similar to Boost.Format but have, i=
n my opinion, a simpler interface.<br><br>[1] https://github.com/facebook/f=
olly/blob/master/folly/docs/Format.md<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_775_14003370.1355708099292--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Mon, 17 Dec 2012 16:35:28 -0600
Raw View
On Sun, Dec 16, 2012 at 4:12 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:
> This is might be a dumb question but isn't it possible to do such parsing
> using constexpr?
> See:
> http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-=
part-i/
Sad. Tried, but failed.
Analysis:
Compile-time string representations:
* User-defined literals (<char...>) digits only
* constexpr (include user-defined string literals) ok
* boost::mpl::string no =
way
To use a constexpr string, we need a constexpr context. But, since an outp=
ut
function is bound to a stream, these functions provide no such context. Th=
e
T const&... arguments are not constexpr, either. The context has to be ous=
ide
the output function. A macro can duplicate the arguments into two contexts=
,
but I don't want to go that way.
So I choose to stay with with runtime specifications.
Current version:
* setstate(failbit) on the output stream instead of throwing
exceptions directly.
* Drop "%S" and "%C". (Andrew)
* Parametrized width and precision are supported "%*.*f".
-- So far, C99/C11 printf is fully supported (except "%n". meaningful?).
-- All others are POSIX extensions, like positional arguments %n$.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Mon, 17 Dec 2012 21:12:12 -0800 (PST)
Raw View
------=_Part_9_21804798.1355807532568
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 16, 2012 1:52:56 PM UTC-6, Zhihao Yuan wrote:
>
> On Sun, Dec 16, 2012 at 1:32 PM, Andrew Sandoval
> <sand...@netwaysglobal.com <javascript:>> wrote:
> > Have you consider implementations that pass arguments via boost::fusion
> > (e.g. make_vector) or std::tuple, so that you can have a printf call
> that:
>
> I used std::tuple.
>
> cout << putf("%d %u %s", -1, -1, "-1"); // arguments 1-n as a tuple
> of T const&...
>
> > Has access to the type of each argument -- so that the specifier only
> > provides additional formatting instructions and errors can be
> > thrown/returned on mis-match, and so that you can use specialization to
> > allow printing of custom types...
>
> That's all what I did.
>
> > The container provides a count of the arguments -- so that you can
> > throw/return (maybe static assert?) an error on too many / too few
>
> I used exceptions. Return value is occupied. static_assert is impossible,
> since
> the format specification is parsed at runtime.
>
> > I may be missing something, but in my experience the problems with
> printf
> > are those two specific things: Mis-matched parameters by type and
> number.
>
> Very, hard, to decide. An additional "formatbit" (for .exceptions())
> might help.
>
> > Also, if I can make a recommendation... Don't perpetuate the HORRIBLE
> %S
> > vs. %s.
>
> I left %S -> %s (along with other length modifiers) as an
> compatibility interface
> to printf(3). I'd like to drop all of them :)
>
> BTW, if Beman's String Interoperation Library get passed, we can do
> better.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3398.html
>
> Thanks for your comments!
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
Sorry, I should've looked closer at your implementation... I'm just too
short on time and still trying to find time to finish my proposal on RAII
objects.
As for exceptions -- I can't speak for everyone, but having to catch
exceptions for something like this is a real pain. It would be nice if we
could find a way to make static assertions work even if it required changes
to the language/compilers. If that is possible. Exceptions are fine, if
they can be optional. Just my opinion.
And on %S/%s, that is okay, but please at least add %hs and %ls, so that
there are specifiers that don't have fluctuating meanings.
Thanks,
Andrew Sandoval
--
------=_Part_9_21804798.1355807532568
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, December 16, 2012 1:52:56 PM UTC-6, Zhihao Yuan wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Sun, Dec 16, 2012 at 1:32 PM, Andrew =
Sandoval
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
eklJiXywj50J">sand...@netwaysglobal.com</a>> wrote:
<br>> Have you consider implementations that pass arguments via boost::f=
usion
<br>> (e.g. make_vector) or std::tuple, so that you can have a printf ca=
ll that:
<br>
<br>I used std::tuple.
<br>
<br> cout << putf("%d %u %s", -1, -1, "-1"); // arguments 1-n as=
a tuple
<br>of T const&...
<br>
<br>> Has access to the type of each argument -- so that the specifier o=
nly
<br>> provides additional formatting instructions and errors can be
<br>> thrown/returned on mis-match, and so that you can use specializati=
on to
<br>> allow printing of custom types...
<br>
<br>That's all what I did.
<br>
<br>> The container provides a count of the arguments -- so that you can
<br>> throw/return (maybe static assert?) an error on too many / too few
<br>
<br>I used exceptions. Return value is occupied. static_assert is imp=
ossible, since
<br>the format specification is parsed at runtime.
<br>
<br>> I may be missing something, but in my experience the problems with=
printf
<br>> are those two specific things: Mis-matched parameters by typ=
e and number.
<br>
<br>Very, hard, to decide. An additional "formatbit" (for .exceptions=
())
<br>might help.
<br>
<br>> Also, if I can make a recommendation... Don't perpetuate the=
HORRIBLE %S
<br>> vs. %s.
<br>
<br>I left %S -> %s (along with other length modifiers) as an
<br>compatibility interface
<br>to printf(3). I'd like to drop all of them :)
<br>
<br>BTW, if Beman's String Interoperation Library get passed, we can do bet=
ter.
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n339=
8.html" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/=
papers/2012/<wbr>n3398.html</a>
<br>
<br>Thanks for your comments!
<br>
<br>--
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote><div><br>Sorry, I should've looked closer at your implemen=
tation... I'm just too short on time and still trying to find time to=
finish my proposal on RAII objects.<br><br>As for exceptions -- I can't sp=
eak for everyone, but having to catch exceptions for something like this is=
a real pain. It would be nice if we could find a way to make static =
assertions work even if it required changes to the language/compilers. =
; If that is possible. Exceptions are fine, if they can be optional.&=
nbsp; Just my opinion.<br><br>And on %S/%s, that is okay, but please at lea=
st add %hs and %ls, so that there are specifiers that don't have fluctuatin=
g meanings.<br><br>Thanks,<br>Andrew Sandoval <br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_9_21804798.1355807532568--
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Mon, 17 Dec 2012 21:15:16 -0800 (PST)
Raw View
------=_Part_321_12010349.1355807716104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, December 16, 2012 4:31:28 PM UTC-6, Zhihao Yuan wrote:
>
> On Sun, Dec 16, 2012 at 4:12 PM, Klaim - Jo=EBl Lamotte <mjk...@gmail.com=
<javascript:>>=20
> wrote:=20
> > This is might be a dumb question but isn't it possible to do such=20
> parsing=20
> > using constexpr?=20
> > See:=20
> >=20
> http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-=
part-i/=20
>
> Emm, this is possible. And safe. My only concern is that, does it make=
=20
> the=20
> compilation too slow? A variadic template is already slow enough. And,=
=20
> though I +1 for a compile-time only specification, how about the=20
> (potential)=20
> users?=20
>
> I'm going to implement one in this approach anyway, for fun, at least.=20
> Thanks=20
> for your link!=20
>
> --=20
> Zhihao Yuan, ID lichray=20
> The best way to predict the future is to invent it.=20
> ___________________________________________________=20
> 4BSD -- http://4bsd.biz/=20
>
It looks like you didn't have success with this, but compile-time shouldn't=
=20
be a factor. That can be worried about by the compiler vendor and the=20
users.
-Andrew Sandoval=20
--=20
------=_Part_321_12010349.1355807716104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, December 16, 2012 4:31:28 PM UTC-6, Zhihao Yuan wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Sun, Dec 16, 2012 at 4:12 PM, Klaim -=
Jo=EBl Lamotte <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"zp2NoSdnQnoJ">mjk...@gmail.com</a>> wrote:
<br>> This is might be a dumb question but isn't it possible to do such =
parsing
<br>> using constexpr?
<br>> See:
<br>> <a href=3D"http://akrzemi1.wordpress.com/2011/05/11/parsing-string=
s-at-compile-time-part-i/" target=3D"_blank">http://akrzemi1.wordpress.com/=
<wbr>2011/05/11/parsing-strings-at-<wbr>compile-time-part-i/</a>
<br>
<br>Emm, this is possible. And safe. My only concern is that, d=
oes it make the
<br>compilation too slow? A variadic template is already slow enough.=
And,
<br>though I +1 for a compile-time only specification, how about the (poten=
tial)
<br>users?
<br>
<br>I'm going to implement one in this approach anyway, for fun, at least. =
Thanks
<br>for your link!
<br>
<br>--
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote><div><br>It looks like you didn't have success with this, =
but compile-time shouldn't be a factor. That can be worried about by =
the compiler vendor and the users.<br>-Andrew Sandoval <br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_321_12010349.1355807716104--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Mon, 17 Dec 2012 23:44:53 -0600
Raw View
On Mon, Dec 17, 2012 at 11:12 PM, Andrew Sandoval
<sandoval@netwaysglobal.com> wrote:
> Sorry, I should've looked closer at your implementation... I'm just too
> short on time and still trying to find time to finish my proposal on RAII
> objects.
Good luck!
> As for exceptions -- I can't speak for everyone, but having to catch
> exceptions for something like this is a real pain. It would be nice if we
> could find a way to make static assertions work even if it required changes
> to the language/compilers. If that is possible. Exceptions are fine, if
> they can be optional. Just my opinion.
Already moved to setstate(failbit), as seen in other formatted output functions.
> And on %S/%s, that is okay, but please at least add %hs and %ls, so that
> there are specifiers that don't have fluctuating meanings.
%S and %C are now removed, since they are X/Open POSIX extensions.
All length modifiers (hh, h, l, ll, L, j, z, t) are parsed and ignored.
I'm considering a next step: is a scanf(3)-like interface worth to have?
AFAIK, very few people knows how to use scanf(3) correctly. White spaces,
cleaning up input errors, all of these are tricky. Any thoughts?
/*
* Real problem:
* My sputf() returns a string, but a sscanf(3)-equivalent can't!
*/
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.