Topic: Better than printf
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Fri, 1 Feb 2013 20:19:32 +0000
Raw View
--e89a8ff1c2541efe9604d4af763c
Content-Type: multipart/alternative; boundary=e89a8ff1c2541efe9304d4af763a
--e89a8ff1c2541efe9304d4af763a
Content-Type: text/plain; charset=ISO-8859-1
Zhiahao,
Why not allow something like this:
double x1 = 1e-10;
double y1 = 12345.678910111213;
double z1 = 123456e5;
unsigned h1 = 0x8ABCDEF;
int i1 = -123456789;
unsigned i2 = +3456789;
std::cout << fmt::f(x1,10) << "*" << fmt::f(y1,10) << "*" <<
fmt::f(z1,10) << std::endl;
std::cout << fmt::f(x1,10,20) << "*" << fmt::f(y1,10,20) << "*" <<
fmt::f(z1,10,20) << std::endl;
std::cout << fmt::E(x1) << "*" << fmt::E(y1) << "*" << fmt::E(z1) <<
std::endl;
std::cout << fmt::E(x1,8) << "*" << fmt::E(y1,8) << "*" << fmt::E(z1,8)
<< std::endl;
std::cout << fmt::E(x1,20) << "*" << fmt::E(y1,20) << "*" <<
fmt::E(z1,20) << std::endl;
td::cout << "100->(8):" << fmt::o(100,5,true) << std::endl;
std::cout << "100->(8): " << fmt::base(8,100,8) << std::endl;
std::cout << "100->(16):" << fmt::base(16,100,8) << std::endl;
std::cout << "100->(4): " << fmt::base(4,100,8) << std::endl;
I have attached the file with implementation and demostration.
Can we have something really convenient!?
Regards,
Mikhail.
On 31 January 2013 03:57, Zhihao Yuan <lichray@gmail.com> wrote:
> Dear committee members:
>
> Thanks to the Visa-waiver status of China and my OPT status,
> I can not leave U.S. For short, I need someone to champion my
> proposal
>
> "A printf-like Interface for the Streams Library"
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3506.html
>
> and, probably, my newly uploaded draft
> "Relaxed switch statement"
> http://students.cs.niu.edu/~z1565938/switch.html
>
> The text of the first proposal is relatively lengthy, but the idea is
> quite simple and clear. Same as the second proposal. If someone
> is interested, I have enough time to discuss the papers with you.
>
> Thanks for help.
>
> Best Regards,
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--e89a8ff1c2541efe9304d4af763a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Zhiahao,</div><div>=A0</div><div>Why not allow something like this:</d=
iv><div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff" f=
ace=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">double x1 =3D 1e=
-10;<br>=A0=A0=A0 double y1 =3D 12345.678910111213;<br>
=A0=A0=A0 double z1 =3D 123456e5;</font></font></font></div><div><font colo=
r=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas"><=
font color=3D"#0000ff" face=3D"Consolas">=A0=A0=A0 unsigned h1 =3D 0x8ABCDE=
F;<br>=A0=A0=A0 int i1 =3D -123456789;<br>
=A0=A0=A0 unsigned i2 =3D +3456789;=A0=A0 </font></font></font></div><div><=
font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff" face=3D"Co=
nsolas"><font color=3D"#0000ff" face=3D"Consolas">=A0=A0=A0 std::cout <&=
lt; fmt::f(x1,10) << "*" << fmt::f(y1,10) << &q=
uot;*" << fmt::f(z1,10) << std::endl;<br>
=A0=A0=A0 std::cout << fmt::f(x1,10,20) << "*" <&l=
t; fmt::f(y1,10,20) << "*" << fmt::f(z1,10,20) <&l=
t; std::endl;</font></font></font></div><div><font color=3D"#0000ff" face=
=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#000=
0ff" face=3D"Consolas">=A0=A0=A0 std::cout << fmt::E(x1) << &qu=
ot;*" << fmt::E(y1) << "*" << fmt::E(z1) &=
lt;< std::endl;<br>
=A0=A0=A0 std::cout << fmt::E(x1,8) << "*" << f=
mt::E(y1,8) << "*" << fmt::E(z1,8) << std::endl=
;<br>=A0=A0=A0 std::cout << fmt::E(x1,20) << "*" <=
< fmt::E(y1,20) << "*" << fmt::E(z1,20) << s=
td::endl;=A0=A0=A0 </font></font></font></div>
<div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff" face=
=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">=A0=A0=A0 td::cout =
<< "100->(8):" << fmt::o(100,5,true) << std:=
:endl;<br>=A0=A0=A0 std::cout << "100->(8): " << f=
mt::base(8,100,8) << std::endl;<br>
=A0=A0=A0 std::cout << "100->(16):" << fmt::base(1=
6,100,8) << std::endl;<br>=A0=A0=A0 std::cout << "100->=
(4): " << fmt::base(4,100,8) << std::endl;</font></font></=
font></div>
<div><font color=3D"#0000ff" face=3D"Consolas"></font>=A0</div><div><font c=
olor=3D"#0000ff" face=3D"Consolas">I have attached the file with implementa=
tion and demostration.</font></div><div><font color=3D"#0000ff" face=3D"Con=
solas">Can we have something really convenient!?</font></div>
<div><font color=3D"#0000ff" face=3D"Consolas"></font>=A0</div><div><font c=
olor=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas=
"><font color=3D"#0000ff" face=3D"Consolas"></font></font></font>=A0</div><=
div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff" face=
=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">Regards,</font></fo=
nt></font></div>
<div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff" face=
=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">Mikhail.</font></fo=
nt></font></div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0=
000ff" face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas"><p>
=A0</p></font></font></font><div class=3D"gmail_quote">On 31 January 2013 0=
3:57, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"mailto:lichray@gmail.com=
" target=3D"_blank">lichray@gmail.com</a>></span> wrote:<br><blockquote =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid" class=3D"gmail_qu=
ote">
Dear committee members:<br>
<br>
Thanks to the Visa-waiver status of China and my OPT status,<br>
I can not leave U.S. =A0For short, I need someone to champion my<br>
proposal<br>
<br>
"A printf-like Interface for the Streams Library"<br>
<a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3506.ht=
ml" target=3D"_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/20=
13/n3506.html</a><br>
<br>
and, probably, my newly uploaded draft<br>
"Relaxed switch statement"<br>
<a href=3D"http://students.cs.niu.edu/~z1565938/switch.html" target=3D"_bla=
nk">http://students.cs.niu.edu/~z1565938/switch.html</a><br>
<br>
The text of the first proposal is relatively lengthy, but the idea is<br>
quite simple and clear. =A0Same as the second proposal. =A0If someone<br>
is interested, I have enough time to discuss the papers with you.<br>
<br>
Thanks for help.<br>
<br>
Best Regards,<br>
<br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<br>
</font></span></blockquote></div><br>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8ff1c2541efe9304d4af763a--
--e89a8ff1c2541efe9604d4af763c
Content-Type: text/x-c++src; charset=US-ASCII; name="output_format.cpp"
Content-Disposition: attachment; filename="output_format.cpp"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcnrzdjs0
Ly8gb3V0cHV0X2Zvcm1hdC5jcHAgOiBEZWZpbmVzIHRoZSBlbnRyeSBwb2ludCBmb3IgdGhlIGNv
bnNvbGUgYXBwbGljYXRpb24uDQovLw0KDQojaW5jbHVkZSA8aW9zdHJlYW0+DQojaW5jbHVkZSA8
aW9tYW5pcD4NCiNpbmNsdWRlIDxzdHJpbmc+DQoNCi8vIENyZWF0ZSB3aXRoIHRlbXBsYXRlcw0K
bmFtZXNwYWNlIGZtdA0KeyAgICANCiAgICBzdHJ1Y3QgZg0KICAgIHsNCiAgICAgICAgICAgICAg
ICANCiAgICAgICAgbG9uZyBkb3VibGUgbV92YWx1ZTsgICAgICAgIA0KICAgICAgICBpbnQgbV9k
aWdpdHM7DQogICAgICAgIGludCBtX3dpZHRoOw0KICAgICAgICBmKGxvbmcgZG91YmxlIHgsIGlu
dCBkaWdpdHMsIGludCB3aWR0aCA9IDApOm1fdmFsdWUoeCksbV9kaWdpdHMoZGlnaXRzKSxtX3dp
ZHRoKHdpZHRoKXt9ICAgICAgICANCiAgICAgICAgZnJpZW5kIHN0ZDo6b3N0cmVhbSYgb3BlcmF0
b3I8PChzdGQ6Om9zdHJlYW0mIGMsIGNvbnN0IGYmIHYpDQogICAgICAgIHsgICAgICAgICAgICAg
ICAgICAgICAgICANCiAgICAgICAgICAgIGMgPDwgc3RkOjpmaXhlZCA8PCBzdGQ6OnNldHByZWNp
c2lvbih2Lm1fZGlnaXRzKSA8PCBzdGQ6OnNldHcodi5tX3dpZHRoKSA8PCB2Lm1fdmFsdWU7DQog
ICAgICAgICAgICBjLnVuc2V0Zigoc3RkOjppb3NfYmFzZTo6Zm10ZmxhZ3MpLTEpOw0KICAgICAg
ICAgICAgcmV0dXJuIGM7DQogICAgICAgIH0NCiAgICB9Ow0KICAgIA0KICAgIHN0cnVjdCBFDQog
ICAgew0KICAgICAgICAgICAgICAgIA0KICAgICAgICBsb25nIGRvdWJsZSBtX3ZhbHVlOyAgICAg
ICAgICAgICAgICANCiAgICAgICAgaW50IG1fd2lkdGg7DQogICAgICAgIEUobG9uZyBkb3VibGUg
eCwgaW50IHdpZHRoID0gMjMpOm1fdmFsdWUoeCksbV93aWR0aCh3aWR0aCl7fSAgICAgICAgDQog
ICAgICAgIGZyaWVuZCBzdGQ6Om9zdHJlYW0mIG9wZXJhdG9yPDwoc3RkOjpvc3RyZWFtJiBjLCBj
b25zdCBFJiBmKQ0KICAgICAgICB7ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgaW50IHdp
ZHRoID0gZi5tX3dpZHRoOw0KICAgICAgICAgICAgaWYgKHdpZHRoIDwgOSkgd2lkdGggPSA5Ow0K
ICAgICAgICAgICAgaW50IGRpZ2l0cyA9IHdpZHRoIC0gODsNCiAgICAgICAgICAgIGMgPDwgc3Rk
Ojp1cHBlcmNhc2UgPDwgc3RkOjpzY2llbnRpZmljIDw8IHN0ZDo6c2hvd3BvcyA8PCBzdGQ6OnNl
dHByZWNpc2lvbihkaWdpdHMpIDw8IHN0ZDo6c2V0dyh3aWR0aCkgPDwgZi5tX3ZhbHVlOw0KICAg
ICAgICAgICAgYy51bnNldGYoKHN0ZDo6aW9zX2Jhc2U6OmZtdGZsYWdzKS0xKTsNCiAgICAgICAg
ICAgIHJldHVybiBjOw0KICAgICAgICB9DQogICAgfTsNCiAgIA0KICAgIHN0cnVjdCBlDQogICAg
ew0KICAgICAgICAgICAgICAgIA0KICAgICAgICBsb25nIGRvdWJsZSBtX3ZhbHVlOyAgICAgICAg
ICAgICAgICANCiAgICAgICAgaW50IG1fd2lkdGg7ICAgICAgICANCiAgICAgICAgZShsb25nIGRv
dWJsZSB4LCBpbnQgd2lkdGggPSAyMyk6bV92YWx1ZSh4KSxtX3dpZHRoKHdpZHRoKXt9ICAgICAg
ICANCiAgICAgICAgZnJpZW5kIHN0ZDo6b3N0cmVhbSYgb3BlcmF0b3I8PChzdGQ6Om9zdHJlYW0m
IGMsIGNvbnN0IGUmIGYpDQogICAgICAgIHsgICAgICAgICAgICAgDQogICAgICAgICAgICBpbnQg
d2lkdGggPSBmLm1fd2lkdGg7DQogICAgICAgICAgICBpZiAod2lkdGggPCA5KSB3aWR0aCA9IDk7
DQogICAgICAgICAgICBpbnQgZGlnaXRzID0gd2lkdGggLSA4Ow0KICAgICAgICAgICAgYyA8PCBz
dGQ6Om5vdXBwZXJjYXNlIDw8IHN0ZDo6c2NpZW50aWZpYyA8PCBzdGQ6OnNob3dwb3MgPDwgc3Rk
OjpzZXRwcmVjaXNpb24oZGlnaXRzKSAgPDwgc3RkOjpzZXR3KHdpZHRoKSA8PCBmLm1fdmFsdWU7
DQogICAgICAgICAgICBjLnVuc2V0Zigoc3RkOjppb3NfYmFzZTo6Zm10ZmxhZ3MpLTEpOw0KICAg
ICAgICAgICAgcmV0dXJuIGM7DQogICAgICAgIH0NCiAgICB9Ow0KDQogICAgc3RydWN0IHgNCiAg
ICB7DQogICAgICAgICAgICAgICAgDQogICAgICAgIGxvbmcgbG9uZyB1bnNpZ25lZCBtX3ZhbHVl
OyAgICAgICAgDQogICAgICAgIGludCBtX3dpZHRoOw0KICAgICAgICBib29sIG1fc2hvd0Jhc2U7
DQogICAgICAgIHgobG9uZyBsb25nIHVuc2lnbmVkIGgsIGludCB3aWR0aCwgYm9vbCBzaG93QmFz
ZSA9IGZhbHNlKTptX3ZhbHVlKGgpLG1fd2lkdGgod2lkdGgpLG1fc2hvd0Jhc2Uoc2hvd0Jhc2Up
e30gICAgICAgIA0KICAgICAgICBmcmllbmQgc3RkOjpvc3RyZWFtJiBvcGVyYXRvcjw8KHN0ZDo6
b3N0cmVhbSYgYywgY29uc3QgeCYgZikNCiAgICAgICAgeyANCiAgICAgICAgICAgaW50IHdpZHRo
ID0gZi5tX3dpZHRoOw0KICAgICAgICAgICBpZiAoZi5tX3Nob3dCYXNlKSB3aWR0aC09IDI7DQog
ICAgICAgICAgIHJldHVybiBjIDw8IChmLm1fc2hvd0Jhc2UgPyAiMHgiIDogIiIpIDw8IHN0ZDo6
bm91cHBlcmNhc2UgPDwgc3RkOjpoZXggPDwgc3RkOjpzZXRmaWxsKCcwJykgPDwgc3RkOjpub3Vw
cGVyY2FzZSA8PCBzdGQ6OnNldHcod2lkdGgpIDw8IGYubV92YWx1ZSAgPDwgc3RkOjpkZWM7DQog
ICAgICAgICAgIGMudW5zZXRmKChzdGQ6Omlvc19iYXNlOjpmbXRmbGFncyktMSk7DQogICAgICAg
ICAgIHJldHVybiBjOw0KICAgICAgICB9DQogICAgfTsNCg0KICAgIHN0cnVjdCBYDQogICAgew0K
ICAgICAgICAgICAgICAgIA0KICAgICAgICBsb25nIGxvbmcgdW5zaWduZWQgbV92YWx1ZTsgICAg
ICAgIA0KICAgICAgICBpbnQgbV93aWR0aDsNCiAgICAgICAgYm9vbCBtX3Nob3dCYXNlOw0KICAg
ICAgICBYKGxvbmcgbG9uZyB1bnNpZ25lZCBoLCBpbnQgd2lkdGgsIGJvb2wgc2hvd0Jhc2UgPSBm
YWxzZSk6bV92YWx1ZShoKSxtX3dpZHRoKHdpZHRoKSxtX3Nob3dCYXNlKHNob3dCYXNlKXt9ICAg
ICAgICANCiAgICAgICAgZnJpZW5kIHN0ZDo6b3N0cmVhbSYgb3BlcmF0b3I8PChzdGQ6Om9zdHJl
YW0mIGMsIGNvbnN0IFgmIGYpDQogICAgICAgIHsgIA0KICAgICAgICAgICAgaW50IHdpZHRoID0g
Zi5tX3dpZHRoOw0KICAgICAgICAgICBpZiAoZi5tX3Nob3dCYXNlKSB3aWR0aC09IDI7DQogICAg
ICAgICAgICByZXR1cm4gYyA8PCAoZi5tX3Nob3dCYXNlID8gIjB4IiA6ICIiKSAgPDwgc3RkOjpo
ZXggPDwgc3RkOjpzZXRmaWxsKCcwJykgPDwgc3RkOjp1cHBlcmNhc2UgPDwgc3RkOjpzZXR3KHdp
ZHRoKSA8PCBmLm1fdmFsdWUgIDw8IHN0ZDo6ZGVjOw0KICAgICAgICAgICAgYy51bnNldGYoKHN0
ZDo6aW9zX2Jhc2U6OmZtdGZsYWdzKS0xKTsNCiAgICAgICAgICAgIHJldHVybiBjOw0KICAgICAg
ICB9DQogICAgfTsNCg0KICAgIHN0cnVjdCBvDQogICAgew0KICAgICAgICAgICAgICAgIA0KICAg
ICAgICBsb25nIGxvbmcgdW5zaWduZWQgbV92YWx1ZTsgICAgICAgIA0KICAgICAgICBpbnQgbV93
aWR0aDsNCiAgICAgICAgYm9vbCBtX3Nob3dCYXNlOw0KICAgICAgICBvKGxvbmcgbG9uZyB1bnNp
Z25lZCBoLCBpbnQgd2lkdGgsIGJvb2wgc2hvd0Jhc2UgPSBmYWxzZSk6bV92YWx1ZShoKSxtX3dp
ZHRoKHdpZHRoKSxtX3Nob3dCYXNlKHNob3dCYXNlKXt9ICAgICAgICANCiAgICAgICAgZnJpZW5k
IHN0ZDo6b3N0cmVhbSYgb3BlcmF0b3I8PChzdGQ6Om9zdHJlYW0mIGMsIGNvbnN0IG8mIGYpDQog
ICAgICAgIHsgICANCiAgICAgICAgICAgaW50IHdpZHRoID0gZi5tX3dpZHRoOw0KICAgICAgICAg
ICBpZiAoZi5tX3Nob3dCYXNlKSB3aWR0aC0tOw0KICAgICAgICAgICByZXR1cm4gYyA8PCAoZi5t
X3Nob3dCYXNlID8gIjAiIDogIiIpIDw8IHN0ZDo6bm91cHBlcmNhc2UgPDwgc3RkOjpvY3QgPDwg
c3RkOjpzZXRmaWxsKCcwJykgPDwgc3RkOjpub3VwcGVyY2FzZSA8PCBzdGQ6OnNldHcod2lkdGgp
IDw8IGYubV92YWx1ZSA8PCBzdGQ6OmRlYzsNCiAgICAgICAgICAgYy51bnNldGYoKHN0ZDo6aW9z
X2Jhc2U6OmZtdGZsYWdzKS0xKTsNCiAgICAgICAgICAgcmV0dXJuIGM7DQogICAgICAgIH0NCiAg
ICB9OyAgICANCg0KICAgIHN0cnVjdCBkDQogICAgew0KICAgICAgICAgICAgICAgIA0KICAgICAg
ICBsb25nIGxvbmcgaW50IG1fdmFsdWU7ICAgICAgICANCiAgICAgICAgaW50IG1fd2lkdGg7ICAg
ICAgICANCiAgICAgICAgZChsb25nIGxvbmcgaW50IHgsIGludCB3aWR0aCA9IDApOm1fdmFsdWUo
eCksbV93aWR0aCh3aWR0aCl7fSAgICAgICAgDQogICAgICAgIGZyaWVuZCBzdGQ6Om9zdHJlYW0m
IG9wZXJhdG9yPDwoc3RkOjpvc3RyZWFtJiBjLCBjb25zdCBkJiBmKQ0KICAgICAgICB7ICAgICAg
ICAgICAgDQogICAgICAgICAgICByZXR1cm4gYyA8PCAgc3RkOjpkZWMgPDwgc3RkOjpzZXRmaWxs
KCcgJykgPDwgc3RkOjpzZXR3KGYubV93aWR0aCkgPDwgZi5tX3ZhbHVlOw0KICAgICAgICAgICAg
Yy51bnNldGYoKHN0ZDo6aW9zX2Jhc2U6OmZtdGZsYWdzKS0xKTsNCiAgICAgICAgICAgIHJldHVy
biBjOw0KICAgICAgICB9DQogICAgfTsNCg0KICAgIHN0cnVjdCB1DQogICAgew0KICAgICAgICAg
ICAgICAgIA0KICAgICAgICBsb25nIGxvbmcgdW5zaWduZWQgbV92YWx1ZTsgICAgICAgIA0KICAg
ICAgICBpbnQgbV93aWR0aDsgICAgICAgIA0KICAgICAgICB1KGxvbmcgbG9uZyB1bnNpZ25lZCB4
LCBpbnQgd2lkdGggPSAwKTptX3ZhbHVlKHgpLG1fd2lkdGgod2lkdGgpe30gICAgICAgIA0KICAg
ICAgICBmcmllbmQgc3RkOjpvc3RyZWFtJiBvcGVyYXRvcjw8KHN0ZDo6b3N0cmVhbSYgYywgY29u
c3QgdSYgZikNCiAgICAgICAgeyAgICAgICAgICAgIA0KICAgICAgICAgICAgcmV0dXJuIGMgPDwg
IHN0ZDo6ZGVjIDw8IHN0ZDo6c2V0ZmlsbCgnICcpIDw8IHN0ZDo6c2V0dyhmLm1fd2lkdGgpIDw8
IGYubV92YWx1ZTsNCiAgICAgICAgICAgIGMudW5zZXRmKChzdGQ6Omlvc19iYXNlOjpmbXRmbGFn
cyktMSk7DQogICAgICAgICAgICByZXR1cm4gYzsNCiAgICAgICAgfQ0KICAgIH07DQoNCiAgICBz
dHJ1Y3QgYmFzZQ0KICAgIHsNCiAgICAgICAgdW5zaWduZWQgbV9iYXNlOyAgIA0KICAgICAgICBs
b25nIGxvbmcgdW5zaWduZWQgbV92YWx1ZTsgICAgICAgIA0KICAgICAgICBpbnQgbV93aWR0aDsg
IA0KICAgICAgICBzdGF0aWMgY2hhciBjb252ZXJ0KHVuc2lnbmVkIGspDQogICAgICAgIHsNCiAg
ICAgICAgICAgIGlmIChrIDw9IDkpIHJldHVybiAoY2hhcikoaysgKHVuc2lnbmVkKScwJyk7DQog
ICAgICAgICAgICByZXR1cm4gKGNoYXIpKChrLTEwKSsgKHVuc2lnbmVkKSdhJyk7DQogICAgICAg
IH0NCg0KICAgICAgICBiYXNlKHVuc2lnbmVkIG5iYXNlLCBsb25nIGxvbmcgdW5zaWduZWQgeCwg
aW50IHdpZHRoID0gMjApOm1fYmFzZShuYmFzZSksIG1fdmFsdWUoeCksbV93aWR0aCh3aWR0aCl7
fSAgICAgICAgDQogICAgICAgIGZyaWVuZCBzdGQ6Om9zdHJlYW0mIG9wZXJhdG9yPDwoc3RkOjpv
c3RyZWFtJiBjLCBjb25zdCBiYXNlJiBmKQ0KICAgICAgICB7ICAgDQogICAgICAgICAgICBpbnQg
Zl93aWR0aCA9IGYubV93aWR0aCAtIDM7DQogICAgICAgICAgICBpZiAoZi5tX2Jhc2UgPiA5KSBm
X3dpZHRoLS07DQogICAgICAgICAgICBpbnQgd2lkdGggPSBmX3dpZHRoOw0KICAgICAgICAgICAg
aWYgKHdpZHRoIDwgNjQpIHdpZHRoID0gNjQ7DQogICAgICAgICAgICBzdGQ6OnN0cmluZyBzKHdp
ZHRoKzEsJzAnKTsNCiAgICAgICAgICAgIHNbd2lkdGhdID0gJ1wwJzsNCiAgICAgICAgICAgIGlu
dCBpID0gd2lkdGgtMTsNCiAgICAgICAgICAgIGxvbmcgbG9uZyB1bnNpZ25lZCB2ID0gZi5tX3Zh
bHVlOw0KICAgICAgICAgICAgd2hpbGUgKGk+MCAmJiB2ICE9IDApDQogICAgICAgICAgICB7DQog
ICAgICAgICAgICAgICAgc1tpXSA9IGNvbnZlcnQodiAlIGYubV9iYXNlKTsNCiAgICAgICAgICAg
ICAgICB2IC89IGYubV9iYXNlOw0KICAgICAgICAgICAgICAgIGktLTsNCiAgICAgICAgICAgIH0N
CiAgICAgICAgICAgIGkrKzsNCiAgICAgICAgICAgIGlmICgod2lkdGgtaSkgPCBmX3dpZHRoKQ0K
ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIGkgPSB3aWR0aCAtIGZfd2lkdGg7DQogICAg
ICAgICAgICB9DQogICAgICAgICAgICByZXR1cm4gYyA8PCAgIigiIDw8IGYubV9iYXNlIDw8ICIp
IiA8PCBzLnN1YnN0cihpKTsNCiAgICAgICAgICAgIGMudW5zZXRmKChzdGQ6Omlvc19iYXNlOjpm
bXRmbGFncyktMSk7DQogICAgICAgICAgICByZXR1cm4gYzsNCiAgICAgICAgfQ0KICAgIH07DQoN
CiAgICBzdHJ1Y3QgQmFzZQ0KICAgIHsNCiAgICAgICAgdW5zaWduZWQgbV9iYXNlOyAgIA0KICAg
ICAgICBsb25nIGxvbmcgdW5zaWduZWQgbV92YWx1ZTsgICAgICAgIA0KICAgICAgICBpbnQgbV93
aWR0aDsgIA0KICAgICAgICBzdGF0aWMgY2hhciBjb252ZXJ0KHVuc2lnbmVkIGspDQogICAgICAg
IHsNCiAgICAgICAgICAgIGlmIChrIDw9IDkpIHJldHVybiAoY2hhcikoaysgKHVuc2lnbmVkKScw
Jyk7DQogICAgICAgICAgICByZXR1cm4gKGNoYXIpKChrLTEwKSsgKHVuc2lnbmVkKSdBJyk7DQog
ICAgICAgIH0NCg0KICAgICAgICBCYXNlKHVuc2lnbmVkIG5iYXNlLCBsb25nIGxvbmcgdW5zaWdu
ZWQgeCwgaW50IHdpZHRoID0gMCk6bV9iYXNlKG5iYXNlKSwgbV92YWx1ZSh4KSxtX3dpZHRoKHdp
ZHRoKXt9ICAgICAgICANCiAgICAgICAgZnJpZW5kIHN0ZDo6b3N0cmVhbSYgb3BlcmF0b3I8PChz
dGQ6Om9zdHJlYW0mIGMsIGNvbnN0IEJhc2UmIGYpDQogICAgICAgIHsgICANCiAgICAgICAgICAg
IGludCBmX3dpZHRoID0gZi5tX3dpZHRoIC0gMzsNCiAgICAgICAgICAgIGlmIChmLm1fYmFzZSA+
IDkpIGZfd2lkdGgtLTsNCiAgICAgICAgICAgIGludCB3aWR0aCA9IGZfd2lkdGg7DQogICAgICAg
ICAgICBpZiAod2lkdGggPCA2NCkgd2lkdGggPSA2NDsNCiAgICAgICAgICAgIHN0ZDo6c3RyaW5n
IHMod2lkdGgrMSwnMCcpOw0KICAgICAgICAgICAgc1t3aWR0aF0gPSAnXDAnOw0KICAgICAgICAg
ICAgaW50IGkgPSB3aWR0aC0xOw0KICAgICAgICAgICAgbG9uZyBsb25nIHVuc2lnbmVkIHYgPSBm
Lm1fdmFsdWU7DQogICAgICAgICAgICB3aGlsZSAoaT4wICYmIHYgIT0gMCkNCiAgICAgICAgICAg
IHsNCiAgICAgICAgICAgICAgICBzW2ldID0gY29udmVydCh2ICUgZi5tX2Jhc2UpOw0KICAgICAg
ICAgICAgICAgIHYgLz0gZi5tX2Jhc2U7DQogICAgICAgICAgICAgICAgaS0tOw0KICAgICAgICAg
ICAgfQ0KICAgICAgICAgICAgaSsrOw0KICAgICAgICAgICAgaWYgKCh3aWR0aC1pKSA8IGZfd2lk
dGgpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgaSA9IHdpZHRoIC0gZl93aWR0aDsN
CiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIHJldHVybiBjIDw8ICAiKCIgPDwgZi5tX2Jhc2Ug
PDwgIikiIDw8IHMuc3Vic3RyKGkpOw0KICAgICAgICAgICAgYy51bnNldGYoKHN0ZDo6aW9zX2Jh
c2U6OmZtdGZsYWdzKS0xKTsNCiAgICAgICAgICAgIHJldHVybiBjOw0KICAgICAgICB9DQogICAg
fTsNCn0NCg0KDQppbnQgbWFpbigpDQp7DQogICAgZG91YmxlIHgxID0gMWUtMTA7DQogICAgZG91
YmxlIHkxID0gMTIzNDUuNjc4OTEwMTExMjEzOw0KICAgIGRvdWJsZSB6MSA9IDEyMzQ1NmU1Ow0K
DQogICAgdW5zaWduZWQgaDEgPSAweDhBQkNERUY7DQogICAgaW50IGkxID0gLTEyMzQ1Njc4OTsN
CiAgICB1bnNpZ25lZCBpMiA9ICszNDU2Nzg5Ow0KICAgIA0KICAgIHN0ZDo6Y291dCA8PCAibm8g
Zm9ybWF0OiAiIDw8IGkxIDw8ICIgIiA8PCBpMiA8PCAiICIgPDwgaDEgPDwgIiAiIDw8IHgxIDw8
IHN0ZDo6ZW5kbDsNCg0KICAgIHN0ZDo6Y291dCA8PCBmbXQ6OmYoeDEsMTApIDw8ICIqIiA8PCBm
bXQ6OmYoeTEsMTApIDw8ICIqIiA8PCBmbXQ6OmYoejEsMTApIDw8IHN0ZDo6ZW5kbDsNCiAgICBz
dGQ6OmNvdXQgPDwgZm10OjpmKHgxLDEwLDIwKSA8PCAiKiIgPDwgZm10OjpmKHkxLDEwLDIwKSA8
PCAiKiIgPDwgZm10OjpmKHoxLDEwLDIwKSA8PCBzdGQ6OmVuZGw7DQoNCiAgICBzdGQ6OmNvdXQg
PDwgZm10OjpFKHgxKSA8PCAiKiIgPDwgZm10OjpFKHkxKSA8PCAiKiIgPDwgZm10OjpFKHoxKSA8
PCBzdGQ6OmVuZGw7DQogICAgc3RkOjpjb3V0IDw8IGZtdDo6RSh4MSw4KSA8PCAiKiIgPDwgZm10
OjpFKHkxLDgpIDw8ICIqIiA8PCBmbXQ6OkUoejEsOCkgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6
Y291dCA8PCBmbXQ6OkUoeDEsMjApIDw8ICIqIiA8PCBmbXQ6OkUoeTEsMjApIDw8ICIqIiA8PCBm
bXQ6OkUoejEsMjApIDw8IHN0ZDo6ZW5kbDsNCg0KICAgIA0KDQogICAgc3RkOjpjb3V0IDw8ICJu
byBmb3JtYXQ6ICIgPDwgaTEgPDwgIiAiIDw8IGkyIDw8ICIgIiA8PCBoMSA8PCAiICIgPDwgeDEg
PDwgc3RkOjplbmRsOw0KDQogICAgc3RkOjpjb3V0IDw8IGZtdDo6eChoMSw4LHRydWUpIDw8IDI0
NTYgPDwgIiAiIDw8IGZtdDo6eChoMSw4KSA8PCBzdGQ6OmVuZGw7DQogICAgc3RkOjpjb3V0IDw8
ICJubyBmb3JtYXQ6ICIgPDwgaTEgPDwgIiAiIDw8IGkyIDw8ICIgIiA8PCBoMSA8PCAiICIgPDwg
eDEgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6Y291dCA8PCBmbXQ6OlgoaDEsOCx0cnVlKSA8PCAy
NDU2IDw8ICIgIiA8PCBmbXQ6OlgoaDEsOCkgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6Y291dCA8
PCBmbXQ6OmYoeDEsMTApIDw8ICIqIiA8PCBmbXQ6OmYoeTEsMTApIDw8ICIqIiA8PCBmbXQ6OmYo
ejEsMTApIDw8IHN0ZDo6ZW5kbDsNCiAgICBzdGQ6OmNvdXQgPDwgIm5vIGZvcm1hdDogIiA8PCBp
MSA8PCAiICIgPDwgaTIgPDwgIiAiIDw8IGgxIDw8ICIgIiA8PCB4MSA8PCBzdGQ6OmVuZGw7DQog
ICAgc3RkOjpjb3V0IDw8ICJubyBmb3JtYXQ6ICIgPDwgaTEgPDwgIiAiIDw8IGkyIDw8ICIgIiA8
PCBoMSA8PCAiICIgPDwgeDEgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6Y291dCA8PCBmbXQ6OmQo
aTEsMjApIDw8ICIgIiA8PCBmbXQ6OnUoaTIsMTApIDw8IHN0ZDo6ZW5kbDsNCiAgICBzdGQ6OmNv
dXQgPDwgZm10OjpkKGkxKSA8PCAiICIgPDwgZm10Ojp1KGkyKSA8PCBzdGQ6OmVuZGw7DQogICAg
c3RkOjpjb3V0IDw8ICJubyBmb3JtYXQ6ICIgPDwgaTEgPDwgIiAiIDw8IGkyIDw8ICIgIiA8PCBo
MSA8PCAiICIgPDwgeDEgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6Y291dCA8PCAiMTAwLT4oOCk6
IiA8PCBmbXQ6Om8oMTAwLDUsdHJ1ZSkgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6Y291dCA8PCAi
MTAwLT4oOCk6ICIgPDwgZm10OjpiYXNlKDgsMTAwLDgpIDw8IHN0ZDo6ZW5kbDsNCiAgICBzdGQ6
OmNvdXQgPDwgIjEwMC0+KDE2KToiIDw8IGZtdDo6YmFzZSgxNiwxMDAsOCkgPDwgc3RkOjplbmRs
Ow0KICAgIHN0ZDo6Y291dCA8PCAiMTAwLT4oNCk6ICIgPDwgZm10OjpiYXNlKDQsMTAwLDgpIDw8
IHN0ZDo6ZW5kbDsNCiAgICBzdGQ6OmNvdXQgPDwgIjEwMC0+KDcpOiAiIDw8IGZtdDo6YmFzZSg3
LDEwMCw4KSA8PCBzdGQ6OmVuZGw7DQogICAgc3RkOjpjb3V0IDw8ICIxMDAtPigxMCk6IiA8PCBm
bXQ6OmJhc2UoMTAsMTAwLDgpIDw8IHN0ZDo6ZW5kbDsNCg0KICAgIHN0ZDo6Y291dCA8PCAiMTAw
LT4oOCk6ICIgPDwgZm10OjpiYXNlKDgsMTAwLDYpIDw8IHN0ZDo6ZW5kbDsNCiAgICBzdGQ6OmNv
dXQgPDwgIjEwMC0+KDE2KToiIDw8IGZtdDo6YmFzZSgxNiwxMDAsNikgPDwgc3RkOjplbmRsOw0K
ICAgIHN0ZDo6Y291dCA8PCAiMTAwLT4oNCk6ICIgPDwgZm10OjpiYXNlKDQsMTAwLDYpIDw8IHN0
ZDo6ZW5kbDsNCiAgICBzdGQ6OmNvdXQgPDwgIjEwMC0+KDcpOiAiIDw8IGZtdDo6YmFzZSg3LDEw
MCw2KSA8PCBzdGQ6OmVuZGw7DQogICAgc3RkOjpjb3V0IDw8ICIxMDAtPigxMCk6IiA8PCBmbXQ6
OmJhc2UoMTAsMTAwLDYpIDw8IHN0ZDo6ZW5kbDsNCg0KICAgIHN0ZDo6Y291dCA8PCAiMjU1LT4o
MTYpOiIgPDwgZm10OjpiYXNlKDE2LDI1NSw2KSA8PCBzdGQ6OmVuZGw7DQogICAgc3RkOjpjb3V0
IDw8ICIyNTUtPigxNik6IiA8PCBmbXQ6OkJhc2UoMTYsMjU1LDYpIDw8IHN0ZDo6ZW5kbDsNCiAg
ICBzdGQ6OmNvdXQgPDwgIjIyNC0+KDE1KToiIDw8IGZtdDo6YmFzZSgxNSwyMjQsNikgPDwgc3Rk
OjplbmRsOw0KICAgIHN0ZDo6Y291dCA8PCAiMjI0LT4oMTUpOiIgPDwgZm10OjpCYXNlKDE1LDIy
NCw2KSA8PCBzdGQ6OmVuZGw7DQoNCiAgICB1bnNpZ25lZCBsb25nIGxvbmcgeiA9IDB4RkZGRkZG
RkZGRkZGRkZGRjsNCg0KICAgIHN0ZDo6Y291dCA8PCAiei0+KDE2KToiIDw8IGZtdDo6YmFzZSgx
Nix6KSA8PCBzdGQ6OmVuZGw7DQogICAgc3RkOjpjb3V0IDw8ICJ6LT4oMTYpOiIgPDwgZm10OjpC
YXNlKDE2LHopIDw8IHN0ZDo6ZW5kbDsNCiAgICBzdGQ6OmNvdXQgPDwgInotPigxNSk6IiA8PCBm
bXQ6OmJhc2UoMTUseikgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6Y291dCA8PCAiei0+KDE1KToi
IDw8IGZtdDo6QmFzZSgxNSx6KSA8PCBzdGQ6OmVuZGw7DQoNCiAgICBzdGQ6OmNvdXQgPDwgInot
PigxNik6IiA8PCBmbXQ6OmJhc2UoMTYseiwyNSkgPDwgc3RkOjplbmRsOw0KICAgIHN0ZDo6Y291
dCA8PCAiei0+KDE2KToiIDw8IGZtdDo6QmFzZSgxNix6LDI1KSA8PCBzdGQ6OmVuZGw7DQogICAg
c3RkOjpjb3V0IDw8ICJ6LT4oMTUpOiIgPDwgZm10OjpiYXNlKDE1LHosMjUpIDw8IHN0ZDo6ZW5k
bDsNCiAgICBzdGQ6OmNvdXQgPDwgInotPigxNSk6IiA8PCBmbXQ6OkJhc2UoMTUseiwyNSkgPDwg
c3RkOjplbmRsOw0KICAgIA0KCXJldHVybiAwOw0KfQ0KDQo=
--e89a8ff1c2541efe9604d4af763c--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Fri, 1 Feb 2013 15:14:38 -0600
Raw View
On Fri, Feb 1, 2013 at 2:19 PM, Mikhail Semenov
<mikhailsemenov1957@gmail.com> wrote:
> std::cout << fmt::f(x1,10) << "*" << fmt::f(y1,10) << "*" <<
> fmt::f(z1,10) << std::endl;
1. Only width/precision are supported.
2. Syntax heavy when those flags are not intended to be configurable,
compared with
std::cout << std::putf("%10f", x1) // ...
, considering `putf` only needs to appear once to print everything.
3. If you want them to be configurable at runtime,
std::cout << std::putf("%*f", 10, x1) // ...
also works.
> Can we have something really convenient!?
One major benefit of "printf" is that you can compress the formatting
into one string, at one place, so that the code readers can ignore the
remaining arguments. From this point of view, I regard your way to be
indifferent from the iomanips...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Sat, 2 Feb 2013 07:45:11 -0800 (PST)
Raw View
------=_Part_1162_23761885.1359819911673
Content-Type: text/plain; charset=ISO-8859-1
On Friday, February 1, 2013 3:14:38 PM UTC-6, Zhihao Yuan wrote:
>
> On Fri, Feb 1, 2013 at 2:19 PM, Mikhail Semenov
> <mikhailse...@gmail.com <javascript:>> wrote:
> > std::cout << fmt::f(x1,10) << "*" << fmt::f(y1,10) << "*" <<
> > fmt::f(z1,10) << std::endl;
>
> 1. Only width/precision are supported.
> 2. Syntax heavy when those flags are not intended to be configurable,
> compared with
>
> std::cout << std::putf("%10f", x1) // ...
>
> , considering `putf` only needs to appear once to print everything.
>
> 3. If you want them to be configurable at runtime,
>
> std::cout << std::putf("%*f", 10, x1) // ...
>
> also works.
>
> > Can we have something really convenient!?
>
> One major benefit of "printf" is that you can compress the formatting
> into one string, at one place, so that the code readers can ignore the
> remaining arguments. From this point of view, I regard your way to be
> indifferent from the iomanips...
>
> I have to agree. I know there is a general dislike for printf and format
specifiers, but I believe that Zhihao's proposal fixes most of the problems
-- at least the ones I find to be most problematic in real world code.
(e.g. type safety and missing parameters).
It may be because of years of use and experience, but I find the iostreams
approach of using the << operator to be tedious, cluttering, and much
harder to read. It's not that printf format strings can't also be hard to
read -- they certainly can, but I would argue that most of the time -- the
simple ones are still easier to read than a similar iostream & iomanip
compound format statement.
And again, one of the realities here is that you are never going to rid C++
of printfs. There is simply too much history behind it -- too much
existing code, and too many APIs etc. that model it. So, why not offer up
a method of doing it that addresses the original problems without
completely changing the paradigm? If you haven't yet, it is very likely
you will someday work on a code base that contains thousands of lines of
printf, sprintfs, etc. You can spend a large portion of your life
refactoing those to use iostreams or something entirely new that breaks up
the format string the way iostreams does, or you can just be glad that
there is a C++ alternative that in most cases can replace the original
printf's with a simple global search and replace operation.
I hope that is helpful.
-Andrew Sandoval
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1162_23761885.1359819911673
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, February 1, 2013 3:14:38 PM UTC-6, Zhihao Yuan wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Fri, Feb 1, 2013 at 2:19 PM, Mikhail S=
emenov
<br><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
D75SveE1vl0J">mikhailse...@gmail.com</a>> wrote:
<br>> std::cout << fmt::f(x1,10) << "*" <&l=
t; fmt::f(y1,10) << "*" <<
<br>> fmt::f(z1,10) << std::endl;
<br>
<br>1. Only width/precision are supported.
<br>2. Syntax heavy when those flags are not intended to be configurable,
<br> compared with
<br>
<br> std::cout << std::putf("%10f", x1) // ...
<br>
<br> , considering `putf` only needs to appear once to print everythi=
ng.
<br>
<br>3. If you want them to be configurable at runtime,
<br>
<br> std::cout << std::putf("%*f", 10, x1) // ...
<br>
<br> also works.
<br>
<br>> Can we have something really convenient!?
<br>
<br>One major benefit of "printf" is that you can compress the formatting
<br>into one string, at one place, so that the code readers can ignore the
<br>remaining arguments. From this point of view, I regard your way t=
o be
<br>indifferent from the iomanips...
<br>
<br></blockquote><div>I have to agree. I know there is a general disl=
ike for printf and format specifiers, but I believe that Zhihao's proposal =
fixes most of the problems -- at least the ones I find to be most problemat=
ic in real world code. (e.g. type safety and missing parameters).<br>=
<br>It may be because of years of use and experience, but I find the iostre=
ams approach of using the << operator to be tedious, cluttering, and =
much harder to read. It's not that printf format strings can't also b=
e hard to read -- they certainly can, but I would argue that most of the ti=
me -- the simple ones are still easier to read than a similar iostream &=
; iomanip compound format statement.<br><br>And again, one of the realities=
here is that you are never going to rid C++ of printfs. There is sim=
ply too much history behind it -- too much existing code, and too many APIs=
etc. that model it. So, why not offer up a method of doing it that a=
ddresses the original problems without completely changing the paradigm?&nb=
sp; If you haven't yet, it is very likely you will someday work on a code b=
ase that contains thousands of lines of printf, sprintfs, etc. You ca=
n spend a large portion of your life refactoing those to use iostreams or s=
omething entirely new that breaks up the format string the way iostreams do=
es, or you can just be glad that there is a C++ alternative that in most ca=
ses can replace the original printf's with a simple global search and repla=
ce operation.<br><br>I hope that is helpful.<br>-Andrew Sandoval<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1162_23761885.1359819911673--
.
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Sat, 2 Feb 2013 19:11:11 +0000
Raw View
--e89a8fb1fac87dfb5c04d4c29ff2
Content-Type: text/plain; charset=ISO-8859-1
Andrew,
I disagree. What Zhihao is proposing is not using printf, but some
nostalgia for printf, using printf features.
Why bother adapting old code to those features. Leave it be!
I used printf in the past for over 10 years. Now I am working for a company
where we don't use any C input/output routines at all.
By I found some C++ features (setw, setprecision, hex, dec, setfill) are a
bit tedious to use. You have to write a lot: so I wrote
some simple routines to make it easier to output values. I think it's
better to explicitly state for each value what format you want to use.
Regards,
Mikhail.
On 2 February 2013 15:45, Andrew Sandoval <sandoval@netwaysglobal.com>wrote:
> On Friday, February 1, 2013 3:14:38 PM UTC-6, Zhihao Yuan wrote:
>
>> On Fri, Feb 1, 2013 at 2:19 PM, Mikhail Semenov
>> <mikhailse...@gmail.com> wrote:
>> > std::cout << fmt::f(x1,10) << "*" << fmt::f(y1,10) << "*" <<
>> > fmt::f(z1,10) << std::endl;
>>
>> 1. Only width/precision are supported.
>> 2. Syntax heavy when those flags are not intended to be configurable,
>> compared with
>>
>> std::cout << std::putf("%10f", x1) // ...
>>
>> , considering `putf` only needs to appear once to print everything.
>>
>> 3. If you want them to be configurable at runtime,
>>
>> std::cout << std::putf("%*f", 10, x1) // ...
>>
>> also works.
>>
>> > Can we have something really convenient!?
>>
>> One major benefit of "printf" is that you can compress the formatting
>> into one string, at one place, so that the code readers can ignore the
>> remaining arguments. From this point of view, I regard your way to be
>> indifferent from the iomanips...
>>
>> I have to agree. I know there is a general dislike for printf and format
> specifiers, but I believe that Zhihao's proposal fixes most of the problems
> -- at least the ones I find to be most problematic in real world code.
> (e.g. type safety and missing parameters).
>
> It may be because of years of use and experience, but I find the iostreams
> approach of using the << operator to be tedious, cluttering, and much
> harder to read. It's not that printf format strings can't also be hard to
> read -- they certainly can, but I would argue that most of the time -- the
> simple ones are still easier to read than a similar iostream & iomanip
> compound format statement.
>
> And again, one of the realities here is that you are never going to rid
> C++ of printfs. There is simply too much history behind it -- too much
> existing code, and too many APIs etc. that model it. So, why not offer up
> a method of doing it that addresses the original problems without
> completely changing the paradigm? If you haven't yet, it is very likely
> you will someday work on a code base that contains thousands of lines of
> printf, sprintfs, etc. You can spend a large portion of your life
> refactoing those to use iostreams or something entirely new that breaks up
> the format string the way iostreams does, or you can just be glad that
> there is a C++ alternative that in most cases can replace the original
> printf's with a simple global search and replace operation.
>
> I hope that is helpful.
> -Andrew Sandoval
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--e89a8fb1fac87dfb5c04d4c29ff2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Andrew,</div><div>=A0</div><div>=A0</div><div>I disagree. What Zhihao =
is proposing is not using printf, but some nostalgia for printf, using prin=
tf features.</div><div>Why bother adapting old code to those features. Leav=
e it be!</div>
<div>=A0</div><div>I=A0used printf in the past for over 10 years. Now I am =
working for a company where we don't use any C input/output routines at=
all.</div><div>By I found some C++ features (setw, setprecision, hex, dec,=
setfill) are a bit tedious to use. You have to write a lot: so I wrote</di=
v>
<div>some simple routines to make it easier to output values. I think it=
9;s better to explicitly state for each value what format you want to use.<=
/div><div>=A0</div><div>Regards,</div><div>Mikhail.<br><br></div><div class=
=3D"gmail_quote">
On 2 February 2013 15:45, Andrew Sandoval <span dir=3D"ltr"><<a href=3D"=
mailto:sandoval@netwaysglobal.com" target=3D"_blank">sandoval@netwaysglobal=
..com</a>></span> wrote:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid" class=3D"gmail_quote">
<div class=3D"im">On Friday, February 1, 2013 3:14:38 PM UTC-6, Zhihao Yuan=
wrote:</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex=
;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style=
:solid" class=3D"gmail_quote">
<div class=3D"im">On Fri, Feb 1, 2013 at 2:19 PM, Mikhail Semenov
<br></div><div class=3D"im"><<a>mikhailse...@gmail.com</a>> wrote:
<br>> =A0 =A0 std::cout << fmt::f(x1,10) << "*" &l=
t;< fmt::f(y1,10) << "*" <<
<br>> fmt::f(z1,10) << std::endl;
<br>
<br>1. Only width/precision are supported.
<br>2. Syntax heavy when those flags are not intended to be configurable,
<br>=A0 compared with
<br>
<br>=A0 std::cout << std::putf("%10f", x1) // ...
<br>
<br>=A0 , considering `putf` only needs to appear once to print everything.
<br>
<br>3. If you want them to be configurable at runtime,
<br>
<br>=A0 std::cout << std::putf("%*f", 10, x1) // ...
<br>
<br>=A0 also works.
<br>
<br>> Can we have something really convenient!?
<br>
<br>One major benefit of "printf" is that you can compress the fo=
rmatting
<br>into one string, at one place, so that the code readers can ignore the
<br>remaining arguments. =A0From this point of view, I regard your way to b=
e
<br>indifferent from the iomanips...
<br>
<br></div></blockquote><div>I have to agree.=A0 I know there is a general d=
islike for printf and format specifiers, but I believe that Zhihao's pr=
oposal fixes most of the problems -- at least the ones I find to be most pr=
oblematic in real world code.=A0 (e.g. type safety and missing parameters).=
<br>
<br>It may be because of years of use and experience, but I find the iostre=
ams approach of using the << operator to be tedious, cluttering, and =
much harder to read.=A0 It's not that printf format strings can't a=
lso be hard to read -- they certainly can, but I would argue that most of t=
he time -- the simple ones are still easier to read than a similar iostream=
& iomanip compound format statement.<br>
<br>And again, one of the realities here is that you are never going to rid=
C++ of printfs.=A0 There is simply too much history behind it -- too much =
existing code, and too many APIs etc. that model it.=A0 So, why not offer u=
p a method of doing it that addresses the original problems without complet=
ely changing the paradigm?=A0 If you haven't yet, it is very likely you=
will someday work on a code base that contains thousands of lines of print=
f, sprintfs, etc.=A0 You can spend a large portion of your life refactoing =
those to use iostreams or something entirely new that breaks up the format =
string the way iostreams does, or you can just be glad that there is a C++ =
alternative that in most cases can replace the original printf's with a=
simple global search and replace operation.<br>
<br>I hope that is helpful.<span class=3D"HOEnZb"><font color=3D"#888888"><=
br>-Andrew Sandoval<br></font></span></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
=A0<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%2Bunsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8fb1fac87dfb5c04d4c29ff2--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sat, 2 Feb 2013 14:04:23 -0600
Raw View
On Sat, Feb 2, 2013 at 1:11 PM, Mikhail Semenov
<mikhailsemenov1957@gmail.com> wrote:
> I disagree. What Zhihao is proposing is not using printf, but some nostalgia
> for printf, using printf features.
Printf-like IO formatting contributes to new code; Python, Java, F#,
whatever language you can think of.
> Why bother adapting old code to those features. Leave it be!
When printing fundamental types, `putf` add no features comparing
to `printf`. They have differences of course. For example, if the old
code uses printf(3) in a wrong way (relying on an UB), `putf` will give
you a well-defined but different result. So it's your choices how to
deal with the old code; `putf` just gives you the ability.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Sat, 2 Feb 2013 13:53:11 -0800 (PST)
Raw View
------=_Part_141_12633541.1359841991664
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 2, 2013 1:11:11 PM UTC-6, Mikhail Semenov wrote:
>
> Andrew,
>
>
> I disagree. What Zhihao is proposing is not using printf, but some
> nostalgia for printf, using printf features.
> Why bother adapting old code to those features. Leave it be!
>
> I used printf in the past for over 10 years. Now I am working for a
> company where we don't use any C input/output routines at all.
> By I found some C++ features (setw, setprecision, hex, dec, setfill) are a
> bit tedious to use. You have to write a lot: so I wrote
> some simple routines to make it easier to output values. I think it's
> better to explicitly state for each value what format you want to use.
>
> Regards,
> Mikhail.
>
Letting that old code "be", just doesn't happen in the real world. Bug
fixes (maintenance) means it's going to be updated, often erroneously.
Also, the search for existing bugs often reveals problems in printfs (and
the like), that are only hit on exceptional cases, making them difficult to
catch in testing.
I'm not saying this is the perfect solution, but I do believe it is a good
one. Replacements like boost::format shouldn't be discarded because of
this, but maybe it will help ease the transition.
-Andrew Sandoval
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_141_12633541.1359841991664
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, February 2, 2013 1:11:11 PM UTC-6, Mikhail Semenov wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div>Andrew,</div><div> </div>=
<div> </div><div>I disagree. What Zhihao is proposing is not using pri=
ntf, but some nostalgia for printf, using printf features.</div><div>Why bo=
ther adapting old code to those features. Leave it be!</div>
<div> </div><div>I used printf in the past for over 10 years. Now=
I am working for a company where we don't use any C input/output routines =
at all.</div><div>By I found some C++ features (setw, setprecision, hex, de=
c, setfill) are a bit tedious to use. You have to write a lot: so I wrote</=
div>
<div>some simple routines to make it easier to output values. I think it's =
better to explicitly state for each value what format you want to use.</div=
><div> </div><div>Regards,</div><div>Mikhail.<br></div></blockquote><d=
iv><br>Letting that old code "be", just doesn't happen in the real world.&n=
bsp; Bug fixes (maintenance) means it's going to be updated, often erroneou=
sly. Also, the search for existing bugs often reveals problems in pri=
ntfs (and the like), that are only hit on exceptional cases, making them di=
fficult to catch in testing.<br><br>I'm not saying this is the perfect solu=
tion, but I do believe it is a good one. Replacements like boost::for=
mat shouldn't be discarded because of this, but maybe it will help ease the=
transition.<br><br>-Andrew Sandoval <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_141_12633541.1359841991664--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Sat, 2 Feb 2013 14:38:49 -0800 (PST)
Raw View
------=_Part_850_16794240.1359844729486
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, February 2, 2013 8:11:11 PM UTC+1, Mikhail Semenov wrote:
>
> Andrew,
>
>
> I disagree. What Zhihao is proposing is not using printf, but some
> nostalgia for printf, using printf features.
> Why bother adapting old code to those features. Leave it be!
>
> I used printf in the past for over 10 years. Now I am working for a
> company where we don't use any C input/output routines at all.
> By I found some C++ features (setw, setprecision, hex, dec, setfill) are a
> bit tedious to use. You have to write a lot: so I wrote
> some simple routines to make it easier to output values. I think it's
> better to explicitly state for each value what format you want to use.
>
> Regards,
> Mikhail.
>
> On 2 February 2013 15:45, Andrew Sandoval <sand...@netwaysglobal.com<javascript:>
> > wrote:
>
>> On Friday, February 1, 2013 3:14:38 PM UTC-6, Zhihao Yuan wrote:
>>
>>> On Fri, Feb 1, 2013 at 2:19 PM, Mikhail Semenov
>>> <mikhailse...@gmail.com> wrote:
>>> > std::cout << fmt::f(x1,10) << "*" << fmt::f(y1,10) << "*" <<
>>> > fmt::f(z1,10) << std::endl;
>>>
>>> 1. Only width/precision are supported.
>>> 2. Syntax heavy when those flags are not intended to be configurable,
>>> compared with
>>>
>>> std::cout << std::putf("%10f", x1) // ...
>>>
>>> , considering `putf` only needs to appear once to print everything.
>>>
>>> 3. If you want them to be configurable at runtime,
>>>
>>> std::cout << std::putf("%*f", 10, x1) // ...
>>>
>>> also works.
>>>
>>> > Can we have something really convenient!?
>>>
>>> One major benefit of "printf" is that you can compress the formatting
>>> into one string, at one place, so that the code readers can ignore the
>>> remaining arguments. From this point of view, I regard your way to be
>>> indifferent from the iomanips...
>>>
>>> I have to agree. I know there is a general dislike for printf and
>> format specifiers, but I believe that Zhihao's proposal fixes most of the
>> problems -- at least the ones I find to be most problematic in real world
>> code. (e.g. type safety and missing parameters).
>>
>> It may be because of years of use and experience, but I find the
>> iostreams approach of using the << operator to be tedious, cluttering, and
>> much harder to read. It's not that printf format strings can't also be
>> hard to read -- they certainly can, but I would argue that most of the time
>> -- the simple ones are still easier to read than a similar iostream &
>> iomanip compound format statement.
>>
>> And again, one of the realities here is that you are never going to rid
>> C++ of printfs. There is simply too much history behind it -- too much
>> existing code, and too many APIs etc. that model it. So, why not offer up
>> a method of doing it that addresses the original problems without
>> completely changing the paradigm? If you haven't yet, it is very likely
>> you will someday work on a code base that contains thousands of lines of
>> printf, sprintfs, etc. You can spend a large portion of your life
>> refactoing those to use iostreams or something entirely new that breaks up
>> the format string the way iostreams does, or you can just be glad that
>> there is a C++ alternative that in most cases can replace the original
>> printf's with a simple global search and replace operation.
>>
>> I hope that is helpful.
>> -Andrew Sandoval
>>
>> --
>>
>> ---
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>>
>>
>>
>
>
For what it's worth, I like the string to be separate from my data (like
with printf), rather than be interleaved with the things I'm trying to
output (like with std::iostreams). Your proposal doesn't fix that, Zhihau
Yuan's does.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_850_16794240.1359844729486
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, February 2, 2013 8:11:11 PM UTC+1, Mikhail Semenov wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div>Andrew,</div><div>&nbs=
p;</div><div> </div><div>I disagree. What Zhihao is proposing is not u=
sing printf, but some nostalgia for printf, using printf features.</div><di=
v>Why bother adapting old code to those features. Leave it be!</div>
<div> </div><div>I used printf in the past for over 10 years. Now=
I am working for a company where we don't use any C input/output routines =
at all.</div><div>By I found some C++ features (setw, setprecision, hex, de=
c, setfill) are a bit tedious to use. You have to write a lot: so I wrote</=
div>
<div>some simple routines to make it easier to output values. I think it's =
better to explicitly state for each value what format you want to use.</div=
><div> </div><div>Regards,</div><div>Mikhail.<br><br></div><div class=
=3D"gmail_quote">
On 2 February 2013 15:45, Andrew Sandoval <span dir=3D"ltr"><<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"jzvxjI13CAQJ">sand.=
...@netwaysglobal.com</a>></span> wrote:<br><blockquote style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid" class=3D"gmail_quote">
<div>On Friday, February 1, 2013 3:14:38 PM UTC-6, Zhihao Yuan wrote:</div>=
<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class=
=3D"gmail_quote">
<div>On Fri, Feb 1, 2013 at 2:19 PM, Mikhail Semenov
<br></div><div><<a>mikhailse...@gmail.com</a>> wrote:
<br>> std::cout << fmt::f(x1,10) << "*" <&l=
t; fmt::f(y1,10) << "*" <<
<br>> fmt::f(z1,10) << std::endl;
<br>
<br>1. Only width/precision are supported.
<br>2. Syntax heavy when those flags are not intended to be configurable,
<br> compared with
<br>
<br> std::cout << std::putf("%10f", x1) // ...
<br>
<br> , considering `putf` only needs to appear once to print everythi=
ng.
<br>
<br>3. If you want them to be configurable at runtime,
<br>
<br> std::cout << std::putf("%*f", 10, x1) // ...
<br>
<br> also works.
<br>
<br>> Can we have something really convenient!?
<br>
<br>One major benefit of "printf" is that you can compress the formatting
<br>into one string, at one place, so that the code readers can ignore the
<br>remaining arguments. From this point of view, I regard your way t=
o be
<br>indifferent from the iomanips...
<br>
<br></div></blockquote><div>I have to agree. I know there is a genera=
l dislike for printf and format specifiers, but I believe that Zhihao's pro=
posal fixes most of the problems -- at least the ones I find to be most pro=
blematic in real world code. (e.g. type safety and missing parameters=
).<br>
<br>It may be because of years of use and experience, but I find the iostre=
ams approach of using the << operator to be tedious, cluttering, and =
much harder to read. It's not that printf format strings can't also b=
e hard to read -- they certainly can, but I would argue that most of the ti=
me -- the simple ones are still easier to read than a similar iostream &=
; iomanip compound format statement.<br>
<br>And again, one of the realities here is that you are never going to rid=
C++ of printfs. There is simply too much history behind it -- too mu=
ch existing code, and too many APIs etc. that model it. So, why not o=
ffer up a method of doing it that addresses the original problems without c=
ompletely changing the paradigm? If you haven't yet, it is very likel=
y you will someday work on a code base that contains thousands of lines of =
printf, sprintfs, etc. You can spend a large portion of your life ref=
actoing those to use iostreams or something entirely new that breaks up the=
format string the way iostreams does, or you can just be glad that there i=
s a C++ alternative that in most cases can replace the original printf's wi=
th a simple global search and replace operation.<br>
<br>I hope that is helpful.<span><font color=3D"#888888"><br>-Andrew Sandov=
al<br></font></span></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jzvxjI13CAQJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"jzvxjI13CAQJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/?hl=3Den</a>.<br>
<br>
<br>
</div></div></blockquote></div><br></blockquote><div><br></div><div>For wha=
t it's worth, I like the string to be separate from my data (like with prin=
tf), rather than be interleaved with the things I'm trying to output (like =
with std::iostreams). Your proposal doesn't fix that, Zhihau Yuan's does.</=
div>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_850_16794240.1359844729486--
.
Author: Fabio Fracassi <f.fracassi@gmx.net>
Date: Mon, 04 Feb 2013 10:05:27 +0100
Raw View
This is a multi-part message in MIME format.
--------------020203030801020307010004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/1/13 9:19 PM, Mikhail Semenov wrote:
> Zhiahao,
> Why not allow something like this:
> double x1 = 1e-10;
> double y1 = 12345.678910111213;
> double z1 = 123456e5;
> unsigned h1 = 0x8ABCDEF;
> int i1 = -123456789;
> unsigned i2 = +3456789;
> std::cout << fmt::f(x1,10) << "*" << fmt::f(y1,10) << "*" <<
> fmt::f(z1,10) << std::endl;
> std::cout << fmt::f(x1,10,20) << "*" << fmt::f(y1,10,20) << "*" <<
> fmt::f(z1,10,20) << std::endl;
> std::cout << fmt::E(x1) << "*" << fmt::E(y1) << "*" << fmt::E(z1) <<
> std::endl;
> std::cout << fmt::E(x1,8) << "*" << fmt::E(y1,8) << "*" <<
> fmt::E(z1,8) << std::endl;
> std::cout << fmt::E(x1,20) << "*" << fmt::E(y1,20) << "*" <<
> fmt::E(z1,20) << std::endl;
> td::cout << "100->(8):" << fmt::o(100,5,true) << std::endl;
> std::cout << "100->(8): " << fmt::base(8,100,8) << std::endl;
> std::cout << "100->(16):" << fmt::base(16,100,8) << std::endl;
> std::cout << "100->(4): " << fmt::base(4,100,8) << std::endl;
> I have attached the file with implementation and demostration.
> Can we have something really convenient!?
>
How do you do i18n with this? You realy need a format string with
reorderable arguments for this.
Besides, using operator<< can really hamper compile times, in comparison
with a typesafe printf
On the whole I think the printf proposal is the right way to go.
regards
Fabio
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--------------020203030801020307010004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 2/1/13 9:19 PM, Mikhail Semenov
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAMeU-s0MetXtZTBmHuENpHQCvADebF8DyXg8MyGVm6TUUMOk_g@mail.gmail.=
com"
type=3D"cite">
<div>Zhiahao,</div>
<div>=A0</div>
<div>Why not allow something like this:</div>
<div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff=
"
face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">dou=
ble
x1 =3D 1e-10;<br>
=A0=A0=A0 double y1 =3D 12345.678910111213;<br>
=A0=A0=A0 double z1 =3D 123456e5;</font></font></font></div>
<div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff=
"
face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">=A0=
=A0=A0
unsigned h1 =3D 0x8ABCDEF;<br>
=A0=A0=A0 int i1 =3D -123456789;<br>
=A0=A0=A0 unsigned i2 =3D +3456789;=A0=A0 </font></font></fon=
t></div>
<div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff=
"
face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">=A0=
=A0=A0
std::cout << fmt::f(x1,10) << "*" <<
fmt::f(y1,10) << "*" << fmt::f(z1,10) <<
std::endl;<br>
=A0=A0=A0 std::cout << fmt::f(x1,10,20) << "*"
<< fmt::f(y1,10,20) << "*" <<
fmt::f(z1,10,20) << std::endl;</font></font></font></di=
v>
<div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff=
"
face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">=A0=
=A0=A0
std::cout << fmt::E(x1) << "*" <<
fmt::E(y1) << "*" << fmt::E(z1) <<
std::endl;<br>
=A0=A0=A0 std::cout << fmt::E(x1,8) << "*" <&l=
t;
fmt::E(y1,8) << "*" << fmt::E(z1,8) <<
std::endl;<br>
=A0=A0=A0 std::cout << fmt::E(x1,20) << "*" <&=
lt;
fmt::E(y1,20) << "*" << fmt::E(z1,20) <<
std::endl;=A0=A0=A0 </font></font></font></div>
<div><font color=3D"#0000ff" face=3D"Consolas"><font color=3D"#0000ff=
"
face=3D"Consolas"><font color=3D"#0000ff" face=3D"Consolas">=A0=
=A0=A0
td::cout << "100->(8):" <<
fmt::o(100,5,true) << std::endl;<br>
=A0=A0=A0 std::cout << "100->(8): " <<
fmt::base(8,100,8) << std::endl;<br>
=A0=A0=A0 std::cout << "100->(16):" <<
fmt::base(16,100,8) << std::endl;<br>
=A0=A0=A0 std::cout << "100->(4): " <<
fmt::base(4,100,8) << std::endl;</font></font></font></=
div>
<div>=A0</div>
<div><font color=3D"#0000ff" face=3D"Consolas">I have attached the
file with implementation and demostration.</font></div>
<div><font color=3D"#0000ff" face=3D"Consolas">Can we have something
really convenient!?</font></div>
<div>=A0</div>
<br>
</blockquote>
How do you do i18n with this? You realy need a format string with
reorderable arguments for this.<br>
Besides, using operator<< can really hamper compile times, in
comparison with a typesafe printf<br>
<br>
On the whole I think the printf proposal is the right way to go.=A0 <br=
>
<br>
regards<br>
<br>
Fabio<br>
<br>
</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------020203030801020307010004--
.
Author: jamin.hanson@googlemail.com
Date: Tue, 9 Apr 2013 06:09:06 -0700 (PDT)
Raw View
------=_Part_61_14657407.1365512946178
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, 2 February 2013 22:38:49 UTC, Sylvester Hesp wrote:
>
>
> For what it's worth, I like the string to be separate from my data (like
> with printf), rather than be interleaved with the things I'm trying to
> output (like with std::iostreams). Your proposal doesn't fix that, Zhihau
> Yuan's does.
>
I too prefer the printf approach compared to iostreams. However, I think we
are missing a trick here. The reason that the printf type formatters exist
is because of the lack of type information for varargs in C. We could
therefore lose the type specifier (%s, %d etc.) and simply have %. Of
course the additional formatting info could be kept, such as the syntax for
leading zeros on integers, date formatting etc.
I have written a tfb::db::sprintf() function for work that takes that idea
further and actually uses the C# style {0}, {1} etc. The reason I went in
that direction is because someone at work mentioned it is annoying to
specify the same variable multiple times when it is needed repeatedly in a
call (and because we are introducing modules written in C#). I believe
boost::format supports a syntax of %1, %2 etc. which may be less
contentious!
And yes, all implemented without variadic template support... The VC++
update can't come soon enough.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_61_14657407.1365512946178
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, 2 February 2013 22:38:49 UTC, Sylvester Hesp wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><br><div>For what it's worth, I like the=
string to be separate from my data (like with printf), rather than be inte=
rleaved with the things I'm trying to output (like with std::iostreams). Yo=
ur proposal doesn't fix that, Zhihau Yuan's does.</div></blockquote><div><b=
r></div><div>I too prefer the printf approach compared to iostreams. Howeve=
r, I think we are missing a trick here. The reason that the printf type for=
matters exist is because of the lack of type information for varargs in C. =
We could therefore lose the type specifier (%s, %d etc.) and simply have %.=
Of course the additional formatting info could be kept, such as the syntax=
for leading zeros on integers, date formatting etc.</div><div><br></div><d=
iv>I have written a tfb::db::sprintf() function for work that takes that id=
ea further and actually uses the C# style {0}, {1} etc. The reason I went i=
n that direction is because someone at work mentioned it is annoying to spe=
cify the same variable multiple times when it is needed repeatedly in a cal=
l (and because we are introducing modules written in C#). I believe boost::=
format supports a syntax of %1, %2 etc. which may be less contentious!</div=
><div><br></div><div>And yes, all implemented without variadic template sup=
port... The VC++ update can't come soon enough.</div>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_61_14657407.1365512946178--
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Tue, 9 Apr 2013 06:29:25 -0700 (PDT)
Raw View
------=_Part_53_28467502.1365514165862
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, April 9, 2013 8:09:06 AM UTC-5, jamin....@googlemail.com wrote:
>
> On Saturday, 2 February 2013 22:38:49 UTC, Sylvester Hesp wrote:
>>
>>
>> For what it's worth, I like the string to be separate from my data (like
>> with printf), rather than be interleaved with the things I'm trying to
>> output (like with std::iostreams). Your proposal doesn't fix that, Zhihau
>> Yuan's does.
>>
>
> I too prefer the printf approach compared to iostreams. However, I think
> we are missing a trick here. The reason that the printf type formatters
> exist is because of the lack of type information for varargs in C. We could
> therefore lose the type specifier (%s, %d etc.) and simply have %. Of
> course the additional formatting info could be kept, such as the syntax for
> leading zeros on integers, date formatting etc.
>
> I have written a tfb::db::sprintf() function for work that takes that idea
> further and actually uses the C# style {0}, {1} etc. The reason I went in
> that direction is because someone at work mentioned it is annoying to
> specify the same variable multiple times when it is needed repeatedly in a
> call (and because we are introducing modules written in C#). I believe
> boost::format supports a syntax of %1, %2 etc. which may be less
> contentious!
>
Knowing the type is only half of the problem. An integer can be printed as
%i, %u, and %x or %X, just to name a few. printf formatting takes care of
that without awkward and long <iomanip> insertions, like setw, hex, dec,
etc. The only part of this you can solve by knowing the type is whether or
not is should be signed. Either that or we need a new built-in type of
"hexadecimal" values of varying bit-widths.
This is most likely the #1 reason that we still use printf formatting in
C++ -- the formatting is easier to control, and it's easier to remember and
use in general. The proposal deals with the safety problems.
-Andrew Sandoval
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_53_28467502.1365514165862
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, April 9, 2013 8:09:06 AM UTC-5, jamin....@googlemail.com wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, 2 February 2013 2=
2:38:49 UTC, Sylvester Hesp wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><br><div>For what it's worth, I like the string to be separate from my dat=
a (like with printf), rather than be interleaved with the things I'm trying=
to output (like with std::iostreams). Your proposal doesn't fix that, Zhih=
au Yuan's does.</div></blockquote><div><br></div><div>I too prefer the prin=
tf approach compared to iostreams. However, I think we are missing a trick =
here. The reason that the printf type formatters exist is because of the la=
ck of type information for varargs in C. We could therefore lose the type s=
pecifier (%s, %d etc.) and simply have %. Of course the additional formatti=
ng info could be kept, such as the syntax for leading zeros on integers, da=
te formatting etc.</div><div><br></div><div>I have written a tfb::db::sprin=
tf() function for work that takes that idea further and actually uses the C=
# style {0}, {1} etc. The reason I went in that direction is because someon=
e at work mentioned it is annoying to specify the same variable multiple ti=
mes when it is needed repeatedly in a call (and because we are introducing =
modules written in C#). I believe boost::format supports a syntax of %1, %2=
etc. which may be less contentious!</div></blockquote><div><br>Knowing the=
type is only half of the problem. An integer can be printed as %i, %=
u, and %x or %X, just to name a few. printf formatting takes care of =
that without awkward and long <iomanip> insertions, like setw, hex, d=
ec, etc. The only part of this you can solve by knowing the type is w=
hether or not is should be signed. Either that or we need a new built=
-in type of "hexadecimal" values of varying bit-widths.<br><br>This is most=
likely the #1 reason that we still use printf formatting in C++ -- the for=
matting is easier to control, and it's easier to remember and use in genera=
l. The proposal deals with the safety problems.<br><br>-Andrew Sandov=
al<br> <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_53_28467502.1365514165862--
.
Author: jamin.hanson@googlemail.com
Date: Tue, 9 Apr 2013 07:00:58 -0700 (PDT)
Raw View
------=_Part_5380_32210904.1365516058763
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, 9 April 2013 14:29:25 UTC+1, Andrew Sandoval wrote:
>
> On Tuesday, April 9, 2013 8:09:06 AM UTC-5, jamin....@googlemail.comwrote:
>>
>> On Saturday, 2 February 2013 22:38:49 UTC, Sylvester Hesp wrote:
>>>
>>>
>>> For what it's worth, I like the string to be separate from my data (like
>>> with printf), rather than be interleaved with the things I'm trying to
>>> output (like with std::iostreams). Your proposal doesn't fix that, Zhihau
>>> Yuan's does.
>>>
>>
>> I too prefer the printf approach compared to iostreams. However, I think
>> we are missing a trick here. The reason that the printf type formatters
>> exist is because of the lack of type information for varargs in C. We could
>> therefore lose the type specifier (%s, %d etc.) and simply have %. Of
>> course the additional formatting info could be kept, such as the syntax for
>> leading zeros on integers, date formatting etc.
>>
>> I have written a tfb::db::sprintf() function for work that takes that
>> idea further and actually uses the C# style {0}, {1} etc. The reason I went
>> in that direction is because someone at work mentioned it is annoying to
>> specify the same variable multiple times when it is needed repeatedly in a
>> call (and because we are introducing modules written in C#). I believe
>> boost::format supports a syntax of %1, %2 etc. which may be less
>> contentious!
>>
>
> Knowing the type is only half of the problem. An integer can be printed
> as %i, %u, and %x or %X, just to name a few. printf formatting takes care
> of that without awkward and long <iomanip> insertions, like setw, hex, dec,
> etc. The only part of this you can solve by knowing the type is whether or
> not is should be signed. Either that or we need a new built-in type of
> "hexadecimal" values of varying bit-widths.
>
> This is most likely the #1 reason that we still use printf formatting in
> C++ -- the formatting is easier to control, and it's easier to remember and
> use in general. The proposal deals with the safety problems.
>
> -Andrew Sandoval
>
I don't see why a type specifier is needed when default formatting is
required. I accept all the formatting overrides are still needed, just like
they always have been.
Looking at https://github.com/lichray/formatxx/blob/proposal/example.cc it
looks like %1, %2 etc. is already supported.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_5380_32210904.1365516058763
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, 9 April 2013 14:29:25 UTC+1, Andrew Sandoval wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Tuesday, April 9, 2013 8:09:06 AM UTC-=
5, <a>jamin....@googlemail.com</a> wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">On Saturday, 2 February 2013 22:38:49 UTC, Sylvester Hesp wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><br><div>For what it's worth, I like th=
e string to be separate from my data (like with printf), rather than be int=
erleaved with the things I'm trying to output (like with std::iostreams). Y=
our proposal doesn't fix that, Zhihau Yuan's does.</div></blockquote><div><=
br></div><div>I too prefer the printf approach compared to iostreams. Howev=
er, I think we are missing a trick here. The reason that the printf type fo=
rmatters exist is because of the lack of type information for varargs in C.=
We could therefore lose the type specifier (%s, %d etc.) and simply have %=
.. Of course the additional formatting info could be kept, such as the synta=
x for leading zeros on integers, date formatting etc.</div><div><br></div><=
div>I have written a tfb::db::sprintf() function for work that takes that i=
dea further and actually uses the C# style {0}, {1} etc. The reason I went =
in that direction is because someone at work mentioned it is annoying to sp=
ecify the same variable multiple times when it is needed repeatedly in a ca=
ll (and because we are introducing modules written in C#). I believe boost:=
:format supports a syntax of %1, %2 etc. which may be less contentious!</di=
v></blockquote><div><br>Knowing the type is only half of the problem. =
An integer can be printed as %i, %u, and %x or %X, just to name a few.&nbs=
p; printf formatting takes care of that without awkward and long <iomani=
p> insertions, like setw, hex, dec, etc. The only part of this you=
can solve by knowing the type is whether or not is should be signed. =
Either that or we need a new built-in type of "hexadecimal" values of vary=
ing bit-widths.<br><br>This is most likely the #1 reason that we still use =
printf formatting in C++ -- the formatting is easier to control, and it's e=
asier to remember and use in general. The proposal deals with the saf=
ety problems.<br><br>-Andrew Sandoval<br></div></blockquote><div><br></div>=
<div>I don't see why a type specifier is needed when default formatting is =
required. I accept all the formatting overrides are still needed, just like=
they always have been.</div><div><br></div><div>Looking at https://github.=
com/lichray/formatxx/blob/proposal/example.cc it looks like %1, %2 etc. is =
already supported.</div>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_5380_32210904.1365516058763--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 9 Apr 2013 10:16:25 -0400
Raw View
On Tue, Apr 9, 2013 at 10:00 AM, <jamin.hanson@googlemail.com> wrote:
> I don't see why a type specifier is needed when default formatting is
> required. I accept all the formatting overrides are still needed, just like
> they always have been.
>
> Looking at https://github.com/lichray/formatxx/blob/proposal/example.cc it
> looks like %1, %2 etc. is already supported.
Not really. The full specification is like %1$d, which is compatible with
the POSIX printf's positional arguments.
However, we are also analyzing some possibilities to extend the format,
https://github.com/lichray/formatxx/issues/2
and some plans happen to be able to "drop" the type specifier.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: jamin.hanson@googlemail.com
Date: Tue, 9 Apr 2013 07:47:18 -0700 (PDT)
Raw View
------=_Part_395_12247517.1365518838430
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, 9 April 2013 15:16:25 UTC+1, Zhihao Yuan wrote:
>
> On Tue, Apr 9, 2013 at 10:00 AM, <jamin....@googlemail.com <javascript:>>
> wrote:
> > I don't see why a type specifier is needed when default formatting is
> > required. I accept all the formatting overrides are still needed, just
> like
> > they always have been.
> >
> > Looking at https://github.com/lichray/formatxx/blob/proposal/example.ccit
> > looks like %1, %2 etc. is already supported.
>
> Not really. The full specification is like %1$d, which is compatible with
> the POSIX printf's positional arguments.
>
> However, we are also analyzing some possibilities to extend the format,
>
> https://github.com/lichray/formatxx/issues/2
>
> and some plans happen to be able to "drop" the type specifier.
>
> --
> Zhihao Yuan, ID lichray
Thanks for the info Zhihao
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_395_12247517.1365518838430
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, 9 April 2013 15:16:25 UTC+1, Zhihao Yuan wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On Tue, Apr 9, 2013 at 10:00 AM, <<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"yAJ7sEs7iW=
MJ">jamin....@googlemail.com</a>> wrote:
<br>> I don't see why a type specifier is needed when default formatting=
is
<br>> required. I accept all the formatting overrides are still needed, =
just like
<br>> they always have been.
<br>>
<br>> Looking at <a href=3D"https://github.com/lichray/formatxx/blob/pro=
posal/example.cc" target=3D"_blank">https://github.com/lichray/formatxx/blo=
b/proposal/example.cc</a> it
<br>> looks like %1, %2 etc. is already supported.
<br>
<br>Not really. The full specification is like %1$d, which is compati=
ble with
<br>the POSIX printf's positional arguments.
<br>
<br>However, we are also analyzing some possibilities to extend the format,
<br>
<br><a href=3D"https://github.com/lichray/formatxx/issues/2" target=3D"_bla=
nk">https://github.com/lichray/formatxx/issues/2</a>
<br>
<br>and some plans happen to be able to "drop" the type specifier.
<br>
<br>--
<br>Zhihao Yuan, ID lichray</blockquote><div><br></div><div>Thanks for the =
info Zhihao </div>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_395_12247517.1365518838430--
.