Topic: Variadic append for std::string
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 28 Dec 2016 00:50:40 -0800 (PST)
Raw View
------=_Part_291_1255964154.1482915040773
Content-Type: multipart/alternative;
boundary="----=_Part_292_312049759.1482915040773"
------=_Part_292_312049759.1482915040773
Content-Type: text/plain; charset=UTF-8
Hi,
One frequently needs to append stuff to strings, but the standard way
(s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
A variadic append() for std::string seems like the obvious solution.
It could support string_view, integers, maybe floats
but without formatting options..
It could even be extensible by calling append(s, t);
append(s, "A", "B", 42);
Would this be useful for the C++ std lib?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6dbc3e8e-8b74-4c5e-b7c5-4b90e08239b8%40isocpp.org.
------=_Part_292_312049759.1482915040773
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family: arial, sans-serif; font-size: =
12.8px;">Hi,</span><br style=3D"font-family: arial, sans-serif; font-size: =
12.8px;"><br style=3D"font-family: arial, sans-serif; font-size: 12.8px;"><=
span style=3D"font-family: arial, sans-serif; font-size: 12.8px;">One frequ=
ently needs to append stuff to strings, but the standard way</span><br styl=
e=3D"font-family: arial, sans-serif; font-size: 12.8px;"><span style=3D"fon=
t-family: arial, sans-serif; font-size: 12.8px;">(s +=3D "A" + &q=
uot;B" + to_string(42)) isn't optimal due to temporaries.</span><b=
r style=3D"font-family: arial, sans-serif; font-size: 12.8px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.8px;">A variadic append()=
for std::string seems like the obvious solution.</span><br style=3D"font-f=
amily: arial, sans-serif; font-size: 12.8px;"><span style=3D"font-family: a=
rial, sans-serif; font-size: 12.8px;">It could support string_view, integer=
s, maybe floats</span><br style=3D"font-family: arial, sans-serif; font-siz=
e: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.8p=
x;">but without formatting options..</span><br style=3D"font-family: arial,=
sans-serif; font-size: 12.8px;"><span style=3D"font-family: arial, sans-se=
rif; font-size: 12.8px;">It could even be extensible by calling append(s, t=
);</span><br style=3D"font-family: arial, sans-serif; font-size: 12.8px;"><=
br style=3D"font-family: arial, sans-serif; font-size: 12.8px;"><span style=
=3D"font-family: arial, sans-serif; font-size: 12.8px;">append(s, "A&q=
uot;, "B", 42);</span><br style=3D"font-family: arial, sans-serif=
; font-size: 12.8px;"><br style=3D"font-family: arial, sans-serif; font-siz=
e: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.8p=
x;">Would this be useful for the C++ std lib?</span><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6dbc3e8e-8b74-4c5e-b7c5-4b90e08239b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6dbc3e8e-8b74-4c5e-b7c5-4b90e08239b8=
%40isocpp.org</a>.<br />
------=_Part_292_312049759.1482915040773--
------=_Part_291_1255964154.1482915040773--
.
Author: lnaltidev@gmail.com
Date: Wed, 28 Dec 2016 02:03:18 -0800 (PST)
Raw View
------=_Part_66_920712755.1482919398167
Content-Type: multipart/alternative;
boundary="----=_Part_67_44221662.1482919398167"
------=_Part_67_44221662.1482919398167
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello,
It would be useful, but will however probably cause temporary string in=20
variadic iteration (I'm not a variadic template expert).
but my dream is more to have a library like this one=20
standardized https://github.com/fmtlib/fmt
Laurent
Le mercredi 28 d=C3=A9cembre 2016 09:50:40 UTC+1, Olaf van der Spek a =C3=
=A9crit :
>
> Hi,
>
> One frequently needs to append stuff to strings, but the standard way
> (s +=3D "A" + "B" + to_string(42)) isn't optimal due to temporaries.
> A variadic append() for std::string seems like the obvious solution.
> It could support string_view, integers, maybe floats
> but without formatting options..
> It could even be extensible by calling append(s, t);
>
> append(s, "A", "B", 42);
>
> Would this be useful for the C++ std lib?
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/12962001-6b0f-4652-83f6-d8c70485d133%40isocpp.or=
g.
------=_Part_67_44221662.1482919398167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello,</div><div><br></div>It would be useful, but wi=
ll however probably cause temporary string in variadic iteration (I'm n=
ot a variadic template expert).<div><br></div><div>but my dream is more to =
have a library like this one standardized=C2=A0https://github.com/fmtlib/fm=
t<div><br></div><div>Laurent<br><br>Le mercredi 28 d=C3=A9cembre 2016 09:50=
:40 UTC+1, Olaf van der Spek a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><span style=3D"font-family:arial,sans-se=
rif;font-size:12.8px">Hi,</span><br style=3D"font-family:arial,sans-serif;f=
ont-size:12.8px"><br style=3D"font-family:arial,sans-serif;font-size:12.8px=
"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">One frequen=
tly needs to append stuff to strings, but the standard way</span><br style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.8px">(s +=3D "A" + "B"=
+ to_string(42)) isn't optimal due to temporaries.</span><br style=3D"=
font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-family:a=
rial,sans-serif;font-size:12.8px">A variadic append() for std::string seems=
like the obvious solution.</span><br style=3D"font-family:arial,sans-serif=
;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12=
..8px">It could support string_view, integers, maybe floats</span><br style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.8px">but without formatting options..</spa=
n><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=
=3D"font-family:arial,sans-serif;font-size:12.8px">It could even be extensi=
ble by calling append(s, t);</span><br style=3D"font-family:arial,sans-seri=
f;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;font-size:12.=
8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">append(s=
, "A", "B", 42);</span><br style=3D"font-family:arial,s=
ans-serif;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;font-=
size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">=
Would this be useful for the C++ std lib?</span><br></div></blockquote></di=
v></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/12962001-6b0f-4652-83f6-d8c70485d133%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/12962001-6b0f-4652-83f6-d8c70485d133=
%40isocpp.org</a>.<br />
------=_Part_67_44221662.1482919398167--
------=_Part_66_920712755.1482919398167--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 28 Dec 2016 14:12:17 +0300
Raw View
On 12/28/16 11:50, Olaf van der Spek wrote:
> Hi,
>
> One frequently needs to append stuff to strings, but the standard way
> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
> A variadic append() for std::string seems like the obvious solution.
> It could support string_view, integers, maybe floats
> but without formatting options..
> It could even be extensible by calling append(s, t);
>
> append(s, "A", "B", 42);
>
> Would this be useful for the C++ std lib?
I think, conceptually, formatting should be decoupled from string. It
would probably make sense to have `append` work with strings (although
template expressions would be even better, I think), but it should not
deal with formatting stuff.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56af4902-fe46-6202-56d3-865fd5c2e307%40gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 28 Dec 2016 10:20:54 -0200
Raw View
Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 00:50:40 BRST, Olaf van de=
r Spek=20
escreveu:
> Hi,
>=20
> One frequently needs to append stuff to strings, but the standard way
> (s +=3D "A" + "B" + to_string(42)) isn't optimal due to temporaries.
> A variadic append() for std::string seems like the obvious solution.
> It could support string_view, integers, maybe floats
> but without formatting options..
> It could even be extensible by calling append(s, t);
>=20
> append(s, "A", "B", 42);
>=20
> Would this be useful for the C++ std lib?
It can also be solved without code change, at least the string parts. The=
=20
following code in Qt does exactly one allocation:
#define QT_USE_FAST_OPERATOR_PLUS
#include <qstring.h>
QString s;
s +=3D "A" + QLatin1String("B") + '.' + QLatin1Char(';');
This expression will do a two-pass scan of all the arguments: first, it=20
calculates their maximum sizes (some of them may shorted when converted fro=
m=20
UTF-8 to UTF-16). Once that is known, it increase s's storage, memcpys the=
=20
data or does an in-place conversion into the buffer, then it shrinks s's si=
ze=20
to the actual size (no reallocation).
The only reason why you have to have that #define is that the plus expressi=
on=20
results in a QStringBuilder<...> template instance instead of QString, so a=
n=20
expression like:
(QLatin1String("%1 ") + types).arg(n)
Is valid without it but will fail to compile with the macro. The solution i=
s=20
an explicit cast to QString:
QString(QLatin1String("%1 ") + types).arg(n)
The fast operator plus is also enabled for QByteArray.
Without the macro, you can use the otherwise-unused operator%:
s +=3D "A" % QLatin1String("B") % '.' % QLatin1Char(';');
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2222132.2dy7r4G1i9%40tjmaciei-mobl1.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 28 Dec 2016 10:09:30 -0800 (PST)
Raw View
------=_Part_1336_474215517.1482948571045
Content-Type: multipart/alternative;
boundary="----=_Part_1337_831892747.1482948571045"
------=_Part_1337_831892747.1482948571045
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Op woensdag 28 december 2016 13:20:58 UTC+1 schreef Thiago Macieira:
>
> Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 00:50:40 BRST, Olaf van =
der=20
> Spek=20
> escreveu:=20
> > Hi,=20
> >=20
> > One frequently needs to append stuff to strings, but the standard way=
=20
> > (s +=3D "A" + "B" + to_string(42)) isn't optimal due to temporaries.=20
> > A variadic append() for std::string seems like the obvious solution.=20
> > It could support string_view, integers, maybe floats=20
> > but without formatting options..=20
> > It could even be extensible by calling append(s, t);=20
> >=20
> > append(s, "A", "B", 42);=20
> >=20
> > Would this be useful for the C++ std lib?=20
>
> It can also be solved without code change, at least the string parts. The=
=20
> following code in Qt does exactly one allocation:=20
>
The non-string parts are kinda important.
Depending on a macro definition is a no-go and overloading operator+ for=20
all kinds of types is probably not a good idea.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/718a0b20-4127-4f65-bad1-484bfbc36575%40isocpp.or=
g.
------=_Part_1337_831892747.1482948571045
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Op woensdag 28 december 2016 13:20:58 UTC+1 schreef T=
hiago Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Em=
quarta-feira, 28 de dezembro de 2016, =C3=A0s 00:50:40 BRST, Olaf van der =
Spek=C2=A0<br>escreveu:=C2=A0<br>> Hi,=C2=A0<br>>=C2=A0<br>> One f=
requently needs to append stuff to strings, but the standard way=C2=A0<br>&=
gt; (s +=3D "A" + "B" + to_string(42)) isn't optima=
l due to temporaries.=C2=A0<br>> A variadic append() for std::string see=
ms like the obvious solution.=C2=A0<br>> It could support string_view, i=
ntegers, maybe floats=C2=A0<br>> but without formatting options..=C2=A0<=
br>> It could even be extensible by calling append(s, t);=C2=A0<br>>=
=C2=A0<br>> append(s, "A", "B", 42);=C2=A0<br>>=
=C2=A0<br>> Would this be useful for the C++ std lib?=C2=A0<br><br>It ca=
n also be solved without code change, at least the string parts. The=C2=A0<=
br>following code in Qt does exactly one allocation:=C2=A0<br></blockquote>=
<div><br></div><div>The non-string parts are kinda important.</div><div>Dep=
ending on a macro definition is a no-go and overloading operator+ for all k=
inds of types is probably not a good idea.</div></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/718a0b20-4127-4f65-bad1-484bfbc36575%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/718a0b20-4127-4f65-bad1-484bfbc36575=
%40isocpp.org</a>.<br />
------=_Part_1337_831892747.1482948571045--
------=_Part_1336_474215517.1482948571045--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 29 Dec 2016 01:35:08 -0200
Raw View
Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 10:09:30 BRST, Olaf van de=
r Spek=20
escreveu:
> > > append(s, "A", "B", 42);
> > >=20
> > > Would this be useful for the C++ std lib?
> >=20
> > It can also be solved without code change, at least the string parts. T=
he
>=20
> > following code in Qt does exactly one allocation:
> The non-string parts are kinda important.
I disagree. Anything but other strings and elements of strings (characters)=
=20
should be done with the proper string formatting functions. Otherwise, we'l=
l=20
soon have someone asking for hex formatting, zero padding, etc. We already=
=20
have the right tools for that.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2519978.5zMBLT7kQj%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Dec 2016 21:45:19 -0800 (PST)
Raw View
------=_Part_57_358877770.1482990319788
Content-Type: multipart/alternative;
boundary="----=_Part_58_1853677193.1482990319788"
------=_Part_58_1853677193.1482990319788
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 28, 2016 at 10:35:15 PM UTC-5, Thiago Macieira wrote=
:
>
> Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 10:09:30 BRST, Olaf van =
der=20
> Spek=20
> escreveu:=20
> > > > append(s, "A", "B", 42);=20
> > > >=20
> > > > Would this be useful for the C++ std lib?=20
> > >=20
> > > It can also be solved without code change, at least the string parts.=
=20
> The=20
> >=20
> > > following code in Qt does exactly one allocation:=20
> > The non-string parts are kinda important.=20
>
> I disagree. Anything but other strings and elements of strings=20
> (characters)=20
> should be done with the proper string formatting functions. Otherwise,=20
> we'll=20
> soon have someone asking for hex formatting, zero padding, etc. We alread=
y=20
> have the right tools for that.
>
We kinda have the right tools for that ;) We still don't have a decent=20
C++-ified printf, despite having had variadic templates for 2 language=20
revisions now.=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c5f32f39-5e29-4c4c-9cd9-113a3b5fd386%40isocpp.or=
g.
------=_Part_58_1853677193.1482990319788
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 28, 2016 at 10:35:15 PM UTC=
-5, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em q=
uarta-feira, 28 de dezembro de 2016, =C3=A0s 10:09:30 BRST, Olaf van der Sp=
ek=20
<br>escreveu:
<br>> > > append(s, "A", "B", 42);
<br>> > >=20
<br>> > > Would this be useful for the C++ std lib?
<br>> >=20
<br>> > It can also be solved without code change, at least the strin=
g parts. The
<br>>=20
<br>> > following code in Qt does exactly one allocation:
<br>> The non-string parts are kinda important.
<br>
<br>I disagree. Anything but other strings and elements of strings (charact=
ers)=20
<br>should be done with the proper string formatting functions. Otherwise, =
we'll=20
<br>soon have someone asking for hex formatting, zero padding, etc. We alre=
ady=20
<br>have the right tools for that.<br></blockquote><div><br>We kinda have t=
he right tools for that ;) We still don't have a decent C++-ified print=
f, despite having had variadic templates for 2 language revisions now. <br>=
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c5f32f39-5e29-4c4c-9cd9-113a3b5fd386%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c5f32f39-5e29-4c4c-9cd9-113a3b5fd386=
%40isocpp.org</a>.<br />
------=_Part_58_1853677193.1482990319788--
------=_Part_57_358877770.1482990319788--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 28 Dec 2016 22:54:32 -0800 (PST)
Raw View
------=_Part_1548_239814206.1482994472768
Content-Type: multipart/alternative;
boundary="----=_Part_1549_1150481663.1482994472768"
------=_Part_1549_1150481663.1482994472768
Content-Type: text/plain; charset=UTF-8
On Wednesday, December 28, 2016 at 11:50:40 AM UTC+3, Olaf van der Spek
wrote:
>
> Hi,
>
> One frequently needs to append stuff to strings, but the standard way
> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
> A variadic append() for std::string seems like the obvious solution.
> It could support string_view, integers, maybe floats
> but without formatting options..
> It could even be extensible by calling append(s, t);
>
> append(s, "A", "B", 42);
>
> Would this be useful for the C++ std lib?
>
I think operator<<() would be better here:
s << "A" << "B" << to_string(42);
And about support for non-character types. It is useful at least for
diagnostics. No need for powerful formatting here, just the ability to
convert any fundamental type to text of any form. iostreams are to
cumbersom, printf is not generic (one need to specify exact specifier for
the type).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e68bd9-f296-4707-aea6-29ca04993a61%40isocpp.org.
------=_Part_1549_1150481663.1482994472768
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 28, 2016 at 11:50:40 AM UTC+3, Olaf=
van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">Hi,<=
/span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><br style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.8px">One frequently needs to append stuff =
to strings, but the standard way</span><br style=3D"font-family:arial,sans-=
serif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-si=
ze:12.8px">(s +=3D "A" + "B" + to_string(42)) isn't=
optimal due to temporaries.</span><br style=3D"font-family:arial,sans-seri=
f;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:1=
2.8px">A variadic append() for std::string seems like the obvious solution.=
</span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span st=
yle=3D"font-family:arial,sans-serif;font-size:12.8px">It could support stri=
ng_view, integers, maybe floats</span><br style=3D"font-family:arial,sans-s=
erif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-siz=
e:12.8px">but without formatting options..</span><br style=3D"font-family:a=
rial,sans-serif;font-size:12.8px"><span style=3D"font-family:arial,sans-ser=
if;font-size:12.8px">It could even be extensible by calling append(s, t);</=
span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><br style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.8px">append(s, "A", "B"=
;, 42);</span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><=
br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"f=
ont-family:arial,sans-serif;font-size:12.8px">Would this be useful for the =
C++ std lib?</span></div></blockquote><div>I think operator<<() would=
be better here:<br><span style=3D"font-family:arial,sans-serif;font-size:1=
2.8px"><br><div style=3D"background-color: rgb(250, 250, 250); border-color=
: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap=
: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">s </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><&=
lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #080;" class=3D"styled-by-prettify">"A"</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">"B"</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> to_string</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" cl=
ass=3D"styled-by-prettify">42</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span></div></code></div><br>And about support for no=
n-character types. It is useful at least for diagnostics. No need for power=
ful formatting here, just the ability to convert any fundamental type to te=
xt of any form. iostreams are to cumbersom, printf is not generic (one need=
to specify exact specifier for the type).<br><br></span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b2e68bd9-f296-4707-aea6-29ca04993a61%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2e68bd9-f296-4707-aea6-29ca04993a61=
%40isocpp.org</a>.<br />
------=_Part_1549_1150481663.1482994472768--
------=_Part_1548_239814206.1482994472768--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 29 Dec 2016 09:44:31 +0100
Raw View
2016-12-29 4:35 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 10:09:30 BRST, Olaf van =
der Spek
> escreveu:
>> > > append(s, "A", "B", 42);
>> > >
>> > > Would this be useful for the C++ std lib?
>> >
>> > It can also be solved without code change, at least the string parts. =
The
>>
>> > following code in Qt does exactly one allocation:
>> The non-string parts are kinda important.
>
> I disagree. Anything but other strings and elements of strings (character=
s)
> should be done with the proper string formatting functions. Otherwise, we=
'll
What proper functions would that be?
Are they as performant as the proposed functions?
> soon have someone asking for hex formatting, zero padding, etc. We alread=
y
> have the right tools for that.
Do we?
--=20
Olaf
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7U3HPa_a0_VkaQpVtzTcF8PibdOa%2B_xpVtpVHDJbZ%2=
Bq0X5bw%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 29 Dec 2016 10:19:10 -0200
Raw View
Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 09:44:31 BRST, Olaf van de=
r Spek=20
escreveu:
> > I disagree. Anything but other strings and elements of strings
> > (characters)
> > should be done with the proper string formatting functions. Otherwise,
> > we'll
> What proper functions would that be?
I think in the standard library, that's std::stringstream. I don't use it, =
so=20
I wouldn't know.
QString has them built in: the .arg() overloads.
> Are they as performant as the proposed functions?
They don't have to be because they serve different purposes. We also need=
=20
something that can support internationalisation (i18n) and concatenation wi=
th=20
plus operators can't do that.
> > soon have someone asking for hex formatting, zero padding, etc. We alre=
ady
> > have the right tools for that.
>=20
> Do we?
Yes.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3700470.JfTvTltSib%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 29 Dec 2016 10:20:59 -0200
Raw View
Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 22:54:32 BRST, Victor Dyac=
henko=20
escreveu:
> I think operator<<() would be better here:
>=20
> s << "A" << "B" << to_string(42);
>=20
> And about support for non-character types. It is useful at least for
> diagnostics. No need for powerful formatting here, just the ability to
> convert any fundamental type to text of any form. iostreams are to
> cumbersom, printf is not generic (one need to specify exact specifier for
> the type).
Why can't you use std::stringstream or another std::ostream here? I know=20
you're saying it's cumbersome, and I agree that the iostreams part of the=
=20
standard library is an extreme overkill (using polymorphism for things that=
=20
didn't need it). Still, we have the tool.
Why not fix iostreams instead?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7607381.61kQ144YtO%40tjmaciei-mobl1.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 29 Dec 2016 04:35:57 -0800 (PST)
Raw View
------=_Part_135_1444479523.1483014957325
Content-Type: multipart/alternative;
boundary="----=_Part_136_1066831621.1483014957326"
------=_Part_136_1066831621.1483014957326
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, December 29, 2016 at 3:21:02 PM UTC+3, Thiago Macieira wrote:
>
> Em quarta-feira, 28 de dezembro de 2016, =C3=A0s 22:54:32 BRST, Victor=20
> Dyachenko=20
> escreveu:=20
> > I think operator<<() would be better here:=20
> >=20
> > s << "A" << "B" << to_string(42);=20
> >=20
> > And about support for non-character types. It is useful at least for=20
> > diagnostics. No need for powerful formatting here, just the ability to=
=20
> > convert any fundamental type to text of any form. iostreams are to=20
> > cumbersom, printf is not generic (one need to specify exact specifier=
=20
> for=20
> > the type).=20
>
> Why can't you use std::stringstream or another std::ostream here? I know=
=20
> you're saying it's cumbersome, and I agree that the iostreams part of the=
=20
> standard library is an extreme overkill (using polymorphism for things=20
> that=20
> didn't need it). Still, we have the tool.=20
>
> "We have unusable tool. Nobody uses it including myself, but we have it!"=
=20
:-)
=20
> Why not fix iostreams instead?=20
>
Because it is not fixable by design. It tries to be everything, so any=20
implementation will be bloated. Dependency on the locales, which weights=20
more than 1MB per se, states everything (formatting parameters, flags,=20
etc), virtual calls, et al. I don't require anything of that just to build=
=20
the error message in the small function, like this:
result_t res =3D call(...);
if(failed(res)) throw std::logical_error(std::string() << "The call()=20
returned " << res);
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/79877a4b-497a-4b6e-9e03-e59c1d17cffe%40isocpp.or=
g.
------=_Part_136_1066831621.1483014957326
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, December 29, 2016 at 3:21:02 PM UTC+3=
, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em qua=
rta-feira, 28 de dezembro de 2016, =C3=A0s 22:54:32 BRST, Victor Dyachenko=
=20
<br>escreveu:
<br>> I think operator<<() would be better here:
<br>>=20
<br>> s << "A" << "B" << to_string=
(42);
<br>>=20
<br>> And about support for non-character types. It is useful at least f=
or
<br>> diagnostics. No need for powerful formatting here, just the abilit=
y to
<br>> convert any fundamental type to text of any form. iostreams are to
<br>> cumbersom, printf is not generic (one need to specify exact specif=
ier for
<br>> the type).
<br>
<br>Why can't you use std::stringstream or another std::ostream here? I=
know=20
<br>you're saying it's cumbersome, and I agree that the iostreams p=
art of the=20
<br>standard library is an extreme overkill (using polymorphism for things =
that=20
<br>didn't need it). Still, we have the tool.
<br>
<br></blockquote><div>"We have unusable tool. Nobody uses it including=
myself, but we have it!" :-)<br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">Why not fix iostreams instead?
<br></blockquote><div>Because it is not fixable by design. It tries to be e=
verything, so any implementation will be bloated. Dependency on the locales=
, which weights more than 1MB per se, states everything (formatting paramet=
ers, flags, etc), virtual calls, et al. I don't require anything of tha=
t just to build the error message in the small function, like this:<br><br>=
<div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-wor=
d;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #000;" class=3D"styled-by-prettify">result_t=
res </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> call</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">failed</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">res</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">throw<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">logical_error</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">string</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&qu=
ot;The call() returned "</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> res</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></div></code></div><br>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79877a4b-497a-4b6e-9e03-e59c1d17cffe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79877a4b-497a-4b6e-9e03-e59c1d17cffe=
%40isocpp.org</a>.<br />
------=_Part_136_1066831621.1483014957326--
------=_Part_135_1444479523.1483014957325--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 29 Dec 2016 04:42:50 -0800 (PST)
Raw View
------=_Part_115_72165112.1483015370307
Content-Type: multipart/alternative;
boundary="----=_Part_116_913505565.1483015370307"
------=_Part_116_913505565.1483015370307
Content-Type: text/plain; charset=UTF-8
FIX: s/ states everything / states everywhere /
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/727df93a-3992-4c48-b729-cdc8815b5166%40isocpp.org.
------=_Part_116_913505565.1483015370307
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">FIX: s/ states everything / states everywhere /<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/727df93a-3992-4c48-b729-cdc8815b5166%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/727df93a-3992-4c48-b729-cdc8815b5166=
%40isocpp.org</a>.<br />
------=_Part_116_913505565.1483015370307--
------=_Part_115_72165112.1483015370307--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Thu, 29 Dec 2016 13:02:20 +0000
Raw View
--94eb2c191226b967b80544cbb287
Content-Type: text/plain; charset=UTF-8
Ah yes, because obviously the primary thing that `std::string`'s interface
needs is *more functionality*. </s>
On Thu, Dec 29, 2016 at 1:42 PM Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:
> FIX: s/ states everything / states everywhere /
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/727df93a-3992-4c48-b729-cdc8815b5166%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/727df93a-3992-4c48-b729-cdc8815b5166%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTiV0-PRcAA-XLMnUkh%2BjJx4NdO-uvrAbc5814WD2Us9g%40mail.gmail.com.
--94eb2c191226b967b80544cbb287
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ah yes, because obviously the primary thing that `std::str=
ing`'s interface needs is <i>more functionality</i>. </s></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Dec 29, 2016 at 1:42 =
PM Victor Dyachenko <<a href=3D"mailto:victor.dyachenko@gmail.com">victo=
r.dyachenko@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr" class=3D"gmail_msg">FIX: s/ states everything / states e=
verywhere /<br class=3D"gmail_msg"></div>
<p class=3D"gmail_msg"></p>
-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br class=3D"gmail_msg=
">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/727df93a-3992-4c48-b729-cdc8815b5166%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/727df93a-3992-4c48-b729-cdc8815b5166%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTiV0-PRcAA-XLMnUkh%2BjJx4NdO-u=
vrAbc5814WD2Us9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTiV0-PRc=
AA-XLMnUkh%2BjJx4NdO-uvrAbc5814WD2Us9g%40mail.gmail.com</a>.<br />
--94eb2c191226b967b80544cbb287--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 29 Dec 2016 16:09:59 +0300
Raw View
On 12/29/16 15:35, Victor Dyachenko wrote:
>
> Why not fix iostreams instead?
>
> Because it is not fixable by design. It tries to be everything, so any
> implementation will be bloated. Dependency on the locales, which weights
> more than 1MB per se, states everything (formatting parameters, flags,
> etc), virtual calls, et al. I don't require anything of that just to
> build the error message in the small function, like this:
>
> |
> result_t res =call(...);
> if(failed(res))throwstd::logical_error(std::string()<<"The call()
> returned "<<res);
> |
std::string is already bloated too much. Adding yet more bloat is hardly
the way to go.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9f62f8c0-5a9a-64db-a2b7-d4b84d0f7d48%40gmail.com.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 29 Dec 2016 14:11:56 +0100
Raw View
2016-12-29 14:09 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
> std::string is already bloated too much. Adding yet more bloat is hardly the
> way to go.
We're not requesting stuff to be added to std::string. ;)
--
Olaf
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HNihfbHp2n8vWED8HJc76-8j8PQE2is3xiOO5wyvBuoGQ%40mail.gmail.com.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 29 Dec 2016 05:16:23 -0800 (PST)
Raw View
------=_Part_103_1329246340.1483017383903
Content-Type: multipart/alternative;
boundary="----=_Part_104_1626723791.1483017383903"
------=_Part_104_1626723791.1483017383903
Content-Type: text/plain; charset=UTF-8
On Thursday, December 29, 2016 at 4:10:03 PM UTC+3, Andrey Semashev wrote:
>
> std::string is already bloated too much.
Agree.
> Adding yet more bloat is hardly
> the way to go.
>
Specifically these features can be implemented in 50 lines of code using
sprintf(), and in a few hundred w/o any dependencies.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/83d555d1-c799-4f6d-9969-b1c052f760d6%40isocpp.org.
------=_Part_104_1626723791.1483017383903
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 29, 2016 at 4:10:03 PM UTC+3, Andrey=
Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">std::string is=
already bloated too much.</blockquote><div>Agree.<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"> Adding yet more bloat is hardly=20
<br>the way to go.
<br></blockquote><div>=C2=A0Specifically these features can be implemented =
in 50 lines of code using sprintf(), and in a few hundred w/o any dependenc=
ies.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/83d555d1-c799-4f6d-9969-b1c052f760d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83d555d1-c799-4f6d-9969-b1c052f760d6=
%40isocpp.org</a>.<br />
------=_Part_104_1626723791.1483017383903--
------=_Part_103_1329246340.1483017383903--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 29 Dec 2016 11:30:01 -0200
Raw View
Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 04:35:57 BRST, Victor Dyac=
henko=20
escreveu:
> > "We have unusable tool. Nobody uses it including myself, but we have it=
!"
> > :-)
You misunderstand me. I don't use std::string in the first place. Therefore=
, I=20
have no need for std::stringstream.
Though I also don't use iostreams, except in Hello World applications.
> > Why not fix iostreams instead?
>=20
> Because it is not fixable by design. It tries to be everything, so any
> implementation will be bloated. Dependency on the locales, which weights
> more than 1MB per se, states everything (formatting parameters, flags,
> etc), virtual calls, et al.=20
So dump it and start something new. I think we'll all benefit from it, sinc=
e=20
most of us think its design is bloated. It came from the very depths of C++=
's=20
origins, when the rule was to make *everything* polymorphic and overrideabl=
e.=20
We've learned a lot since then.
Anyway, I don't oppose having a formatting method for strings, outside of=
=20
iostreams or a replacement of it. I think we need it, even.
I just don't think we should combine that with concatenation.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1730640.yXFxZGszCK%40tjmaciei-mobl1.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 29 Dec 2016 05:47:29 -0800 (PST)
Raw View
------=_Part_1060_1194070830.1483019249175
Content-Type: multipart/alternative;
boundary="----=_Part_1061_210605216.1483019249175"
------=_Part_1061_210605216.1483019249175
Content-Type: text/plain; charset=UTF-8
On Thursday, December 29, 2016 at 4:30:10 PM UTC+3, Thiago Macieira wrote:
>
> I just don't think we should combine that with concatenation.
>
Makes sense. "<<" for non-character type, indeed, is the subset of the
concatenation feature. As for me, the ability to use "<<" instead of "+="
for char, const char * and std::string would be a good starting point.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8d8502f9-8429-495a-96ba-f49a478871d1%40isocpp.org.
------=_Part_1061_210605216.1483019249175
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 29, 2016 at 4:30:10 PM UTC+3, Thiago=
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I just don'=
;t think we should combine that with concatenation.
<br></blockquote><div>Makes sense. "<<" for non-character t=
ype, indeed, is the subset of the concatenation feature. As for me, the abi=
lity to use "<<" instead of "+=3D" for char, cons=
t char=C2=A0 * and std::string would be a good starting point.<br></div></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8d8502f9-8429-495a-96ba-f49a478871d1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8d8502f9-8429-495a-96ba-f49a478871d1=
%40isocpp.org</a>.<br />
------=_Part_1061_210605216.1483019249175--
------=_Part_1060_1194070830.1483019249175--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 29 Dec 2016 16:56:52 +0300
Raw View
On 12/29/16 16:11, Olaf van der Spek wrote:
> 2016-12-29 14:09 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
>> std::string is already bloated too much. Adding yet more bloat is hardly the
>> way to go.
>
> We're not requesting stuff to be added to std::string. ;)
Adding operator<< overloads for std::string is adding to std::string. As
is creating a specialized append() algorithm that is targeted
specifically at string manipulation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/272bf944-2a46-7fdc-057d-68ddf36fca70%40gmail.com.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 29 Dec 2016 15:00:47 +0100
Raw View
2016-12-29 14:56 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
> On 12/29/16 16:11, Olaf van der Spek wrote:
>>
>> 2016-12-29 14:09 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
>>>
>>> std::string is already bloated too much. Adding yet more bloat is hardly
>>> the
>>> way to go.
>>
>>
>> We're not requesting stuff to be added to std::string. ;)
>
>
> Adding operator<< overloads for std::string is adding to std::string. As is
> creating a specialized append() algorithm that is targeted specifically at
> string manipulation.
What are you suggesting?
I'm fine with s being a template parameter allowing you to maybe use
it for file or vector<char> too...
A string algo is exactly what (some) people need..
--
Olaf
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HMdic9fcotOrFvfUfeu9uWbGDvPOwDT8mqJzt26Q966LQ%40mail.gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 29 Dec 2016 17:06:09 +0300
Raw View
On 12/29/16 16:16, Victor Dyachenko wrote:
> On Thursday, December 29, 2016 at 4:10:03 PM UTC+3, Andrey Semashev wrote:
>
> Adding yet more bloat is hardly
> the way to go.
>
> Specifically these features can be implemented in 50 lines of code
> using sprintf(), and in a few hundred w/o any dependencies.
The exact number of lines is not my only concern, although I doubt that
your esimate is accurate, at least in the "no added dependencies" case.
Correctly formatting FP numbers, in particular, sounds like a
complicated task. Then there is support for user-defined types, some of
which are probably ostreamable - would you not want existing operator<<
to be used? This brings a dependency on iostreams.
Conceptually, you're adding more functionality to std::string, which IMO
should be nothing more than a container of characters. Any formatting
tools should build on top of that container (and maybe even allow
different containers to be used) instead of hijacking it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4eefe155-b9f8-4d3f-089f-45f7c8f8667b%40gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 29 Dec 2016 17:12:55 +0300
Raw View
On 12/29/16 17:00, Olaf van der Spek wrote:
> 2016-12-29 14:56 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
>> On 12/29/16 16:11, Olaf van der Spek wrote:
>>>
>>> 2016-12-29 14:09 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
>>>>
>>>> std::string is already bloated too much. Adding yet more bloat is hardly
>>>> the
>>>> way to go.
>>>
>>>
>>> We're not requesting stuff to be added to std::string. ;)
>>
>>
>> Adding operator<< overloads for std::string is adding to std::string. As is
>> creating a specialized append() algorithm that is targeted specifically at
>> string manipulation.
>
> What are you suggesting?
> I'm fine with s being a template parameter allowing you to maybe use
> it for file or vector<char> too...
>
> A string algo is exactly what (some) people need..
I don't have a proposal, but if that's a generic formatting algorithm
then it should not be coupled with std::string and of course it should
not be named append() (because, well, appending is the least of the
things it does). I think, a C++ version of sprintf() is a frequently
requested feature, and it seems it could potentially fit your case as well.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/93a5b8da-5d1e-a664-03a8-b11d3bab6529%40gmail.com.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 29 Dec 2016 15:24:33 +0100
Raw View
2016-12-29 15:12 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
> I don't have a proposal, but if that's a generic formatting algorithm then
From my first post: "It could support string_view, integers, maybe floats
**but without formatting options**.."
> it should not be coupled with std::string and of course it should not be
> named append() (because, well, appending is the least of the things it
> does). I think, a C++ version of sprintf() is a frequently requested
> feature, and it seems it could potentially fit your case as well.
Maybe, but the formatting options and string make it vastly more
complex. It'd also have a different interface. Maybe it'd even use my
proposed append function internally.. ;)
--
Olaf
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HNEiktWy9iHqCfprN5G3AteHZqAhsMBmDLaU5u7o3KXdA%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 29 Dec 2016 12:36:03 -0200
Raw View
Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 05:47:29 BRST, Victor Dyac=
henko=20
escreveu:
> On Thursday, December 29, 2016 at 4:30:10 PM UTC+3, Thiago Macieira wrote=
:
> > I just don't think we should combine that with concatenation.
>=20
> Makes sense. "<<" for non-character type, indeed, is the subset of the
> concatenation feature. As for me, the ability to use "<<" instead of "+=
=3D"
> for char, const char * and std::string would be a good starting point.
The left-most operand is always a class type, probably a template=20
instantiation of std::basic_string.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1509317.BqkunrEfpk%40tjmaciei-mobl1.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Thu, 29 Dec 2016 08:14:55 -0800 (PST)
Raw View
------=_Part_1509_1673861548.1483028095336
Content-Type: multipart/alternative;
boundary="----=_Part_1510_1302678472.1483028095336"
------=_Part_1510_1302678472.1483028095336
Content-Type: text/plain; charset=UTF-8
Note that deferring number formatting to existing functions reduces the
performance gain of this function: Each of the number formatter functions
will have to allocate a std::string or similar and return it before the
Append() function or similar gets hold of it. Thus we can never get down to
the one allocation solution envisioned. Furthermore, even to find out the
number of characters to allocate for a formatted number without actually
doing the formatting is very complicated, especially if it needs to heed
formatting options. Using a simplified formatted length functionality can
work but means that either there could be a significant over-allocation if
guesses are too high or significant amounts of double allocation if guesses
are too low.
Another solution would be to use a thread-local buffer to basically sprintf
into and then copy the now known length result into the string (causing one
allocation). But this can all be viewed as QOI level discussions. What is
important is that if number formatting is excluded from a feature like this
much of its appeal when it comes to allocation count reduction is lost.
So while this proposal without number capability does reduce allocations
there are many more allocations that can be gotten rid of if numbers are
allowed. An alternative would be to introduce another set of number
formatting functions which return objects that actually do the formatting
into a buffer, but can also tell how large that buffer needs to be.
Unfortunately this would add to C++ already large set of number formatting
functions and there would be no warning if older, less performant functions
are used inside an Append call by mistake.
I think, but have no proof, that it could be easier to get a customization
point similar to operator<<(ostream&, T) for additional types if an
operator chaining approach is implemented than for a Append function. As
someone suggested it should be possible to let this mechanism fall back to
a use of the ostream based operator if a specific overload is not
available. Allowing the stream modifiers such as hex etc. would be possible
but of course cumbersome and also perpetuate this old fashioned way of
specifying formatting. One thought that struck me was that maybe a library
implementer can turn the tables and implement shifting into an ostream in
terms of this new feature (reducing the number of reallocations of the
stream buffer) but this is probably not possible due to backward
compatiblibty issues.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d1656ac9-a383-49cb-a1b0-14cbcf1415f5%40isocpp.org.
------=_Part_1510_1302678472.1483028095336
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Note that deferring number formatting to existing function=
s reduces the performance gain of this function: Each of the number formatt=
er functions will have to allocate a std::string or similar and return it b=
efore the Append() function or similar gets hold of it. Thus we can never g=
et down to the one allocation solution envisioned. Furthermore, even to fin=
d out the number of characters to allocate for a formatted number without a=
ctually doing the formatting is very complicated, especially if it needs to=
heed formatting options. Using a simplified formatted length functionality=
can work but means that either there could be a significant over-allocatio=
n if guesses are too high or significant amounts of double allocation if gu=
esses are too low.<div><div><br></div><div>Another solution would be to use=
a thread-local buffer to basically sprintf into and then copy the now know=
n length result into the string (causing one allocation). But this can all =
be viewed as =C2=A0QOI level discussions. What is important is that if numb=
er formatting is excluded from a feature like this much of its appeal when =
it comes to allocation count reduction is lost.</div></div><div><br></div><=
div>So while this proposal without number capability does reduce allocation=
s there are many more allocations that can be gotten rid of if numbers are =
allowed. An alternative would be to introduce another set of number formatt=
ing functions which return objects that actually do the formatting into a b=
uffer, but can also tell how large that buffer needs to be. Unfortunately t=
his would add to C++ already large set of number formatting functions and t=
here would be no warning if older, less performant functions are used insid=
e an Append call by mistake.</div><div><br></div><div>I think, but have no =
proof, that it could be easier to get a customization point similar to oper=
ator<<(ostream&, T) for additional types if an operator chaining =
approach is implemented than for a Append function. As someone suggested it=
should be possible to let this mechanism fall back to a use of the ostream=
based operator if a specific overload is not available. Allowing the strea=
m modifiers such as hex etc. would be possible but of course cumbersome and=
also perpetuate this old fashioned way of specifying formatting. One thoug=
ht that struck me was that maybe a library implementer can turn the tables =
and implement shifting into an ostream in terms of this new feature (reduci=
ng the number of reallocations of the stream buffer) but this is probably n=
ot possible due to backward compatiblibty issues.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d1656ac9-a383-49cb-a1b0-14cbcf1415f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d1656ac9-a383-49cb-a1b0-14cbcf1415f5=
%40isocpp.org</a>.<br />
------=_Part_1510_1302678472.1483028095336--
------=_Part_1509_1673861548.1483028095336--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 29 Dec 2016 08:47:02 -0800 (PST)
Raw View
------=_Part_1624_333022150.1483030022370
Content-Type: multipart/alternative;
boundary="----=_Part_1625_389794779.1483030022370"
------=_Part_1625_389794779.1483030022370
Content-Type: text/plain; charset=UTF-8
On Thursday, December 29, 2016 at 8:10:03 AM UTC-5, Andrey Semashev wrote:
>
> On 12/29/16 15:35, Victor Dyachenko wrote:
> >
> > Why not fix iostreams instead?
> >
> > Because it is not fixable by design. It tries to be everything, so any
> > implementation will be bloated. Dependency on the locales, which weights
> > more than 1MB per se, states everything (formatting parameters, flags,
> > etc), virtual calls, et al. I don't require anything of that just to
> > build the error message in the small function, like this:
> >
> > |
> > result_t res =call(...);
> > if(failed(res))throwstd::logical_error(std::string()<<"The call()
> > returned "<<res);
> > |
>
> std::string is already bloated too much. Adding yet more bloat is hardly
> the way to go.
>
I find this "too bloated" argument to be unconvincing.
Does `std::basic_string` have functions that are, strictly speaking, not
necessary? Yes. But that doesn't mean you shouldn't add function which
actually *are necessary* to the interface. The fact that a type already has
unneeded member functions shouldn't stop you from putting needed ones in
there.
Now, you can argue that it actually *isn't* necessary, that there are ways
to achieve the same performance of a concatenation function without making
it a member. But "appeal to bloat" isn't a valid argument against it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6abd0160-dd78-4206-8f3e-83486c71f365%40isocpp.org.
------=_Part_1625_389794779.1483030022370
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 29, 2016 at 8:10:03 AM UTC-5, Andrey=
Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12/29/16 15=
:35, Victor Dyachenko wrote:
<br>>
<br>> =C2=A0 =C2=A0 Why not fix iostreams instead?
<br>>
<br>> Because it is not fixable by design. It tries to be everything, so=
any
<br>> implementation will be bloated. Dependency on the locales, which w=
eights
<br>> more than 1MB per se, states everything (formatting parameters, fl=
ags,
<br>> etc), virtual calls, et al. I don't require anything of that j=
ust to
<br>> build the error message in the small function, like this:
<br>>
<br>> |
<br>> result_t res =3Dcall(...);
<br>> if(failed(res))throwstd::<wbr>logical_error(std::string()<<&=
quot;<wbr>The call()
<br>> returned "<<res);
<br>> |
<br>
<br>std::string is already bloated too much. Adding yet more bloat is hardl=
y=20
<br>the way to go.<br></blockquote><div><br>I find this "too bloated&q=
uot; argument to be unconvincing.<br><br>Does `std::basic_string` have func=
tions that are, strictly speaking, not necessary? Yes. But that doesn't=
mean you shouldn't add function which actually <i>are necessary</i> to=
the interface. The fact that a type already has unneeded member functions =
shouldn't stop you from putting needed ones in there.<br><br>Now, you c=
an argue that it actually <i>isn't</i> necessary, that there are ways t=
o achieve the same performance of a concatenation function without making i=
t a member. But "appeal to bloat" isn't a valid argument agai=
nst it.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6abd0160-dd78-4206-8f3e-83486c71f365%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6abd0160-dd78-4206-8f3e-83486c71f365=
%40isocpp.org</a>.<br />
------=_Part_1625_389794779.1483030022370--
------=_Part_1624_333022150.1483030022370--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 29 Dec 2016 17:47:57 +0100
Raw View
2016-12-29 17:14 GMT+01:00 Bengt Gustafsson <bengt.gustafsson@beamways.com>:
> Note that deferring number formatting to existing functions reduces the
> performance gain of this function: Each of the number formatter functions
> will have to allocate a std::string or similar and return it before the
> Append() function or similar gets hold of it. Thus we can never get down to
http://en.cppreference.com/w/cpp/utility/to_chars ;)
> I think, but have no proof, that it could be easier to get a customization
> point similar to operator<<(ostream&, T) for additional types if an operator
> chaining approach is implemented than for a Append function. As someone
I think this isn't true, a customization point should be no trouble
with an append function..
Chaining looks good but wouldn't it make the single-allocation
optimization impossible?
--
Olaf
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HMy%3DaGu-XxPaCc71_vW-COBwmVTdww1K7ErR_o0-R63zw%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 29 Dec 2016 09:03:10 -0800 (PST)
Raw View
------=_Part_1116_357614938.1483030990974
Content-Type: multipart/alternative;
boundary="----=_Part_1117_378376871.1483030990974"
------=_Part_1117_378376871.1483030990974
Content-Type: text/plain; charset=UTF-8
On Thursday, December 29, 2016 at 11:47:59 AM UTC-5, Olaf van der Spek
wrote:
>
> 2016-12-29 17:14 GMT+01:00 Bengt Gustafsson <bengt.gu...@beamways.com
> <javascript:>>:
> > Note that deferring number formatting to existing functions reduces the
> > performance gain of this function: Each of the number formatter
> functions
> > will have to allocate a std::string or similar and return it before the
> > Append() function or similar gets hold of it. Thus we can never get down
> to
>
> http://en.cppreference.com/w/cpp/utility/to_chars ;)
>
`to_chars` lacks the ability to tell you exactly how many characters a
conversion will take. That's going to make it really difficult to
pre-allocate the right amount of memory. At least, not without allocating a
lot of extra space.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a9025bd7-5c13-45be-b7d2-6b88f799cf64%40isocpp.org.
------=_Part_1117_378376871.1483030990974
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 29, 2016 at 11:47:59 AM UTC-5, Olaf =
van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-12-29 =
17:14 GMT+01:00 Bengt Gustafsson <<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"y-MKOcHwCQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">bengt.gu...@beamways.com</a><wbr>>:
<br>> Note that deferring number formatting to existing functions reduce=
s the
<br>> performance gain of this function: Each of the number formatter fu=
nctions
<br>> will have to allocate a std::string or similar and return it befor=
e the
<br>> Append() function or similar gets hold of it. Thus we can never ge=
t down to
<br>
<br><a href=3D"http://en.cppreference.com/w/cpp/utility/to_chars" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Fto_cha=
rs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFp69NpgnLo_Rn_AQZTjqrDQhHZWg'=
;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3d=
http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futility%2Fto_chars\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNFp69NpgnLo_Rn_AQZTjqrDQhHZWg';return true;=
">http://en.cppreference.com/w/<wbr>cpp/utility/to_chars</a> ;)<br></blockq=
uote><div><br>`to_chars` lacks the ability to tell you exactly how many cha=
racters a conversion will take. That's going to make it really difficul=
t to pre-allocate the right amount of memory. At least, not without allocat=
ing a lot of extra space.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a9025bd7-5c13-45be-b7d2-6b88f799cf64%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a9025bd7-5c13-45be-b7d2-6b88f799cf64=
%40isocpp.org</a>.<br />
------=_Part_1117_378376871.1483030990974--
------=_Part_1116_357614938.1483030990974--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 29 Dec 2016 20:18:28 +0300
Raw View
On 12/29/16 19:47, Nicol Bolas wrote:
> On Thursday, December 29, 2016 at 8:10:03 AM UTC-5, Andrey Semashev wrote:
>
> std::string is already bloated too much. Adding yet more bloat is
> hardly
> the way to go.
>
> I find this "too bloated" argument to be unconvincing.
>
> Does `std::basic_string` have functions that are, strictly speaking, not
> necessary? Yes. But that doesn't mean you shouldn't add function which
> actually /are necessary/ to the interface. The fact that a type already
> has unneeded member functions shouldn't stop you from putting needed
> ones in there.
I don't think formatting qualifies as the "necessary" or "needed"
functions for std::string.
> Now, you can argue that it actually /isn't/ necessary, that there are
> ways to achieve the same performance of a concatenation function without
> making it a member. But "appeal to bloat" isn't a valid argument against it.
It is, because that is exactly how std::string interface became bloated.
Consider the bunch of find*/rfind/compare member functions that are
currently present in std::string interface but could perfectly be
standalone. Some of them, in fact, already exist as standalone generic
algorithms, which a decent compiler will optimize to the same degree as
the dedicated member functions.
The proposed extension is worse than the mentioned member functions in
that it potentially brings new dependencies to implement formatting.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8a0771b3-4776-40d8-bc32-0a50cc4b7dab%40gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 29 Dec 2016 20:23:43 +0300
Raw View
On 12/29/16 17:24, Olaf van der Spek wrote:
> 2016-12-29 15:12 GMT+01:00 Andrey Semashev <andrey.semashev@gmail.com>:
>> I don't have a proposal, but if that's a generic formatting algorithm then
>
> From my first post: "It could support string_view, integers, maybe floats
> **but without formatting options**.."
Well, it may not support formatting options, but as long as it converts
arbitrary data to strings (or anything that can act like a string), it's
still a generic formatting algorithm.
>> it should not be coupled with std::string and of course it should not be
>> named append() (because, well, appending is the least of the things it
>> does). I think, a C++ version of sprintf() is a frequently requested
>> feature, and it seems it could potentially fit your case as well.
>
> Maybe, but the formatting options and string make it vastly more
> complex. It'd also have a different interface. Maybe it'd even use my
> proposed append function internally.. ;)
If we're talking about an sprintf() equivalent, I don't think a more
flexible formatting implementation can be based on top of a less
flexible one (that is, your proposed function).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a5393b6f-be64-1b81-ecb9-d59f9a666ad7%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 29 Dec 2016 13:58:59 -0800 (PST)
Raw View
------=_Part_4055_712370235.1483048739449
Content-Type: multipart/alternative;
boundary="----=_Part_4056_906058282.1483048739449"
------=_Part_4056_906058282.1483048739449
Content-Type: text/plain; charset=UTF-8
On Thursday, December 29, 2016 at 12:18:32 PM UTC-5, Andrey Semashev wrote:
>
> On 12/29/16 19:47, Nicol Bolas wrote:
> > On Thursday, December 29, 2016 at 8:10:03 AM UTC-5, Andrey Semashev
> wrote:
> >
> > std::string is already bloated too much. Adding yet more bloat is
> > hardly
> > the way to go.
> >
> > I find this "too bloated" argument to be unconvincing.
> >
> > Does `std::basic_string` have functions that are, strictly speaking, not
> > necessary? Yes. But that doesn't mean you shouldn't add function which
> > actually /are necessary/ to the interface. The fact that a type already
> > has unneeded member functions shouldn't stop you from putting needed
> > ones in there.
>
> I don't think formatting qualifies as the "necessary" or "needed"
> functions for std::string.
>
And I do not think that the basis of the append functionality requires
including a "formatting" system. The basic proposal is fast sequential
string appending. Stuff added on top of that should not interfere with that
basic ideal.
> Now, you can argue that it actually /isn't/ necessary, that there are
> > ways to achieve the same performance of a concatenation function without
> > making it a member. But "appeal to bloat" isn't a valid argument against
> it.
>
> It is, because that is exactly how std::string interface became bloated.
>
That's not my understanding of the evolution of this type.
As I understand it, what became known as `std::basic_string` was a regular
old concrete string class. It had exactly the kind of interface that string
classes would be expected to have: searching, replacing, etc. That's
typical of string classes, and there's no reason to consider that "bloat".
It *certainly* would not have been considered "bloated" at the time it was
designed.
However, when they moved to stick it into the standard, it was decided to
give it an STL interface in addition to its existing interface.
Consider the bunch of find*/rfind/compare member functions that are
> currently present in std::string interface but could perfectly be
> standalone. Some of them, in fact, already exist as standalone generic
> algorithms, which a decent compiler will optimize to the same degree as
> the dedicated member functions.
>
There is a fundamental difference between the argument you just outlined
and the "X is bloat and bloat is bad" you said before. The difference being
that the above is an actual argument, and the latter is an opinion.
If you want to say that it is not necessary to add appending functionality
to `std::string` itself, then make that argument. But saying that the class
is "bloated" and therefore adding *anything* is wrong is not a functional
argument.
It should also be noted that the primary reason why those member functions
continue to exist in `basic_string` (that is, why the committee did not
*replace* their interface with the STL-based one) is because they work with
integer offsets, rather than iterators/pointers. A *lot* of people do work
with strings based on integer offsets, and they're not going to rewrite all
of their code just because you think that iterators involve less "bloat".
In some cases, they *can't* rewrite their code, since it's in C. So rather
than making a string type that many people would reject, the committee made
sure that the member API would use offsets, while relying on algorithms for
those who want to use iterators.
If you feel that this is "bloat", that's your prerogative. But there is a
genuine reason behind these APIs.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2ca47cff-3e0f-4948-bd87-6325c048805c%40isocpp.org.
------=_Part_4056_906058282.1483048739449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 29, 2016 at 12:18:32 PM UTC-5, Andre=
y Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12/29/16 1=
9:47, Nicol Bolas wrote:
<br>> On Thursday, December 29, 2016 at 8:10:03 AM UTC-5, Andrey Semashe=
v wrote:
<br>>
<br>> =C2=A0 =C2=A0 std::string is already bloated too much. Adding yet =
more bloat is
<br>> =C2=A0 =C2=A0 hardly
<br>> =C2=A0 =C2=A0 the way to go.
<br>>
<br>> I find this "too bloated" argument to be unconvincing.
<br>>
<br>> Does `std::basic_string` have functions that are, strictly speakin=
g, not
<br>> necessary? Yes. But that doesn't mean you shouldn't add fu=
nction which
<br>> actually /are necessary/ to the interface. The fact that a type al=
ready
<br>> has unneeded member functions shouldn't stop you from putting =
needed
<br>> ones in there.
<br>
<br>I don't think formatting qualifies as the "necessary" or =
"needed"=20
<br>functions for std::string.<br></blockquote><div><br>And I do not think =
that the basis of the append functionality requires including a "forma=
tting" system. The basic proposal is fast sequential string appending.=
Stuff added on top of that should not interfere with that basic ideal.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> Now, you can argue that it actually /isn't/ necessary, that there =
are
<br>> ways to achieve the same performance of a concatenation function w=
ithout
<br>> making it a member. But "appeal to bloat" isn't a va=
lid argument against it.
<br>
<br>It is, because that is exactly how std::string interface became bloated=
..<br></blockquote><div><br>That's not my understanding of the evolution=
of this type.<br><br>As I understand it, what became known as `std::basic_=
string` was a regular old concrete string class. It had exactly the kind of=
interface that string classes would be expected to have: searching, replac=
ing, etc. That's typical of string classes, and there's no reason t=
o consider that "bloat". It <i>certainly</i> would not have been =
considered "bloated" at the time it was designed.<br><br>However,=
when they moved to stick it into the standard, it was decided to give it a=
n STL interface in addition to its existing interface.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">Consider the bunch of find*/rfind/com=
pare member functions that are=20
<br>currently present in std::string interface but could perfectly be=20
<br>standalone. Some of them, in fact, already exist as standalone generic=
=20
<br>algorithms, which a decent compiler will optimize to the same degree as=
=20
<br>the dedicated member functions.<br></blockquote><div><br>There is a fun=
damental difference between the argument you just outlined and the "X =
is bloat and bloat is bad" you said before. The difference being that =
the above is an actual argument, and the latter is an opinion.<br><br>If yo=
u want to say that it is not necessary to add appending functionality to `s=
td::string` itself, then make that argument. But saying that the class is &=
quot;bloated" and therefore adding <i>anything</i> is wrong is not a f=
unctional argument.<br><br>It should also be noted that the primary reason =
why those member=20
functions continue to exist in `basic_string` (that is, why the committee d=
id not <i>replace</i> their interface with the STL-based one) is because th=
ey work with integer=20
offsets, rather than iterators/pointers. A <i>lot</i> of people do work=20
with strings based on integer offsets, and they're not going to rewrite=
=20
all of their code just because you think that iterators involve less=20
"bloat". In some cases, they <i>can't</i> rewrite their code,=
since it's in C. So rather than making a string type that many people =
would=20
reject, the committee made sure that the member API would use offsets,=20
while relying on algorithms for those who want to use iterators.<br><br>If =
you feel that this is "bloat", that's your prerogative. But t=
here is a genuine reason behind these APIs.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2ca47cff-3e0f-4948-bd87-6325c048805c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2ca47cff-3e0f-4948-bd87-6325c048805c=
%40isocpp.org</a>.<br />
------=_Part_4056_906058282.1483048739449--
------=_Part_4055_712370235.1483048739449--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 29 Dec 2016 20:24:13 -0200
Raw View
Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 09:03:10 BRST, Nicol Bolas=
=20
escreveu:
> `to_chars` lacks the ability to tell you exactly how many characters a
> conversion will take. That's going to make it really difficult to
> pre-allocate the right amount of memory. At least, not without allocating=
a
> lot of extra space.
Which you can't know until you perform the conversion anyway. So any code t=
hat=20
tries to single-allocate a formatting chain needs to estimate with the wors=
t=20
case scenario (which, for 'f', could be in the hundreds of characters) and=
=20
then trim the string.
As a QoI bonus, implementations can improve the estimation by performing lo=
g10=20
on the value, or log2 and divide by 3 (log2 is extremely fast).
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9448360.R0Cie9K37v%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 29 Dec 2016 20:30:03 -0200
Raw View
Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 20:18:28 BRST, Andrey Sema=
shev=20
escreveu:
> It is, because that is exactly how std::string interface became bloated.
> Consider the bunch of find*/rfind/compare member functions that are
> currently present in std::string interface but could perfectly be
> standalone. Some of them, in fact, already exist as standalone generic
> algorithms, which a decent compiler will optimize to the same degree as
> the dedicated member functions.
And yet hardly any compiler will optimise as well as the dedicated copies o=
f=20
those functions that exist for QString inside QtCore.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/16299440.VqBOrIjuRa%40tjmaciei-mobl1.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 30 Dec 2016 04:33:15 +0300
Raw View
On Fri, Dec 30, 2016 at 1:30 AM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 20:18:28 BRST, Andrey Se=
mashev
> escreveu:
>> It is, because that is exactly how std::string interface became bloated.
>> Consider the bunch of find*/rfind/compare member functions that are
>> currently present in std::string interface but could perfectly be
>> standalone. Some of them, in fact, already exist as standalone generic
>> algorithms, which a decent compiler will optimize to the same degree as
>> the dedicated member functions.
>
> And yet hardly any compiler will optimise as well as the dedicated copies=
of
> those functions that exist for QString inside QtCore.
I'm not familiar with Qt implementation, but I suspect it doesn't do
anything significantly more optimized than libc string functions. I
know at least gcc is able to convert std::copy/std::fill into
memcpy/memset calls when possible, and I see no reason why it couldn't
convert std::find/std::equal into memmem/memcmp. Does Qt do something
better than that?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAEhD%2B6CHhBj-N2Yg7K7XxVXE%2BNT62ATbk7eYJZqRP6R=
hyMfd6Q%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 29 Dec 2016 21:15:50 -0800 (PST)
Raw View
------=_Part_1773_433991119.1483074950455
Content-Type: multipart/alternative;
boundary="----=_Part_1774_226331072.1483074950455"
------=_Part_1774_226331072.1483074950455
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, December 29, 2016 at 5:24:17 PM UTC-5, Thiago Macieira wrote:
>
> Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 09:03:10 BRST, Nicol Bol=
as=20
> escreveu:=20
> > `to_chars` lacks the ability to tell you exactly how many characters a=
=20
> > conversion will take. That's going to make it really difficult to=20
> > pre-allocate the right amount of memory. At least, not without=20
> allocating a=20
> > lot of extra space.=20
>
> Which you can't know until you perform the conversion anyway. So any code=
=20
> that=20
> tries to single-allocate a formatting chain needs to estimate with the=20
> worst=20
> case scenario (which, for 'f', could be in the hundreds of characters) an=
d=20
> then trim the string.=20
>
> As a QoI bonus, implementations can improve the estimation by performing=
=20
> log10=20
> on the value, or log2 and divide by 3 (log2 is extremely fast).
>
Don't misunderstand my point; it's a perfectly fine design. I was just=20
pointing out that this makes it essentially impossible to have both a=20
single-allocation append design and in-situ string formatting during append=
=20
operations.
So it's probably best to leave that alone.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c71e6a33-bdfe-485e-b8fa-20cc1fc42136%40isocpp.or=
g.
------=_Part_1774_226331072.1483074950455
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 29, 2016 at 5:24:17 PM UTC-5, Thiago=
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em quinta-feir=
a, 29 de dezembro de 2016, =C3=A0s 09:03:10 BRST, Nicol Bolas=20
<br>escreveu:
<br>> `to_chars` lacks the ability to tell you exactly how many characte=
rs a
<br>> conversion will take. That's going to make it really difficult=
to
<br>> pre-allocate the right amount of memory. At least, not without all=
ocating a
<br>> lot of extra space.
<br>
<br>Which you can't know until you perform the conversion anyway. So an=
y code that=20
<br>tries to single-allocate a formatting chain needs to estimate with the =
worst=20
<br>case scenario (which, for 'f', could be in the hundreds of char=
acters) and=20
<br>then trim the string.
<br>
<br>As a QoI bonus, implementations can improve the estimation by performin=
g log10=20
<br>on the value, or log2 and divide by 3 (log2 is extremely fast).<br></bl=
ockquote><div><br>Don't misunderstand my point; it's a perfectly fi=
ne design. I was just pointing out that this makes it essentially impossibl=
e to have both a single-allocation append design and in-situ string formatt=
ing during append operations.<br><br>So it's probably best to leave tha=
t alone.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c71e6a33-bdfe-485e-b8fa-20cc1fc42136%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c71e6a33-bdfe-485e-b8fa-20cc1fc42136=
%40isocpp.org</a>.<br />
------=_Part_1774_226331072.1483074950455--
------=_Part_1773_433991119.1483074950455--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 29 Dec 2016 21:23:58 -0800 (PST)
Raw View
------=_Part_1260_429975818.1483075438313
Content-Type: multipart/alternative;
boundary="----=_Part_1261_2060656440.1483075438313"
------=_Part_1261_2060656440.1483075438313
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, December 29, 2016 at 8:33:20 PM UTC-5, Andrey Semashev wrote:
>
> On Fri, Dec 30, 2016 at 1:30 AM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:=20
> > Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 20:18:28 BRST, Andrey=
=20
> Semashev=20
> > escreveu:=20
> >> It is, because that is exactly how std::string interface became=20
> bloated.=20
> >> Consider the bunch of find*/rfind/compare member functions that are=20
> >> currently present in std::string interface but could perfectly be=20
> >> standalone. Some of them, in fact, already exist as standalone generic=
=20
> >> algorithms, which a decent compiler will optimize to the same degree a=
s=20
> >> the dedicated member functions.=20
> >=20
> > And yet hardly any compiler will optimise as well as the dedicated=20
> copies of=20
> > those functions that exist for QString inside QtCore.=20
>
> I'm not familiar with Qt implementation, but I suspect it doesn't do=20
> anything significantly more optimized than libc string functions. I=20
> know at least gcc is able to convert std::copy/std::fill into=20
> memcpy/memset calls when possible, and I see no reason why it couldn't=20
> convert std::find/std::equal into memmem/memcmp. Does Qt do something=20
> better than that?=20
>
Here's a better question: so what if it doesn't?
I'm in favor of QOI when it comes to algorithms. But at the end of the day,=
=20
it costs me as a user *nothing* to have both `std::find` and=20
`basic_string::find`. Does it hurt my program in any way that I could have=
=20
used `std::find` instead of the member function? No. Does it make my=20
program in any way confusing? No. Does it make my program run any slower?=
=20
No. It doesn't even make my executable bigger, since either way, it'll=20
compile down to an inlined function.
Then so long as there are genuine benefits to the member function version=
=20
(like being able to take integer indices), what's the big deal?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1258ca2e-1149-4381-9e72-e86a8d05a179%40isocpp.or=
g.
------=_Part_1261_2060656440.1483075438313
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 29, 2016 at 8:33:20 PM UTC-5, Andrey=
Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Dec 30=
, 2016 at 1:30 AM, Thiago Macieira <<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"XY3BKWwNCgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">thi...@macieira.org</a>> wrote:
<br>> Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 20:18:28 BRST, An=
drey Semashev
<br>> escreveu:
<br>>> It is, because that is exactly how std::string interface becam=
e bloated.
<br>>> Consider the bunch of find*/rfind/compare member functions tha=
t are
<br>>> currently present in std::string interface but could perfectly=
be
<br>>> standalone. Some of them, in fact, already exist as standalone=
generic
<br>>> algorithms, which a decent compiler will optimize to the same =
degree as
<br>>> the dedicated member functions.
<br>>
<br>> And yet hardly any compiler will optimise as well as the dedicated=
copies of
<br>> those functions that exist for QString inside QtCore.
<br>
<br>I'm not familiar with Qt implementation, but I suspect it doesn'=
;t do
<br>anything significantly more optimized than libc string functions. I
<br>know at least gcc is able to convert std::copy/std::fill into
<br>memcpy/memset calls when possible, and I see no reason why it couldn=
9;t
<br>convert std::find/std::equal into memmem/memcmp. Does Qt do something
<br>better than that?
<br></blockquote><div><br>Here's a better question: so what if it doesn=
't?<br><br>I'm in favor of QOI when it comes to algorithms. But at =
the end of the day, it costs me as a user <i>nothing</i> to have both `std:=
:find` and `basic_string::find`. Does it hurt my program in any way that I =
could have used `std::find` instead of the member function? No. Does it mak=
e my program in any way confusing? No. Does it make my program run any slow=
er? No. It doesn't even make my executable bigger, since either way, it=
'll compile down to an inlined function.<br><br>Then so long as there a=
re genuine benefits to the member function version (like being able to take=
integer indices), what's the big deal?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1258ca2e-1149-4381-9e72-e86a8d05a179%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1258ca2e-1149-4381-9e72-e86a8d05a179=
%40isocpp.org</a>.<br />
------=_Part_1261_2060656440.1483075438313--
------=_Part_1260_429975818.1483075438313--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 30 Dec 2016 13:08:11 +0300
Raw View
On 12/30/16 08:23, Nicol Bolas wrote:
> On Thursday, December 29, 2016 at 8:33:20 PM UTC-5, Andrey Semashev wrote:
>
> I'm not familiar with Qt implementation, but I suspect it doesn't do
> anything significantly more optimized than libc string functions. I
> know at least gcc is able to convert std::copy/std::fill into
> memcpy/memset calls when possible, and I see no reason why it couldn't
> convert std::find/std::equal into memmem/memcmp. Does Qt do something
> better than that?
>
> Here's a better question: so what if it doesn't?
>
> I'm in favor of QOI when it comes to algorithms. But at the end of the
> day, it costs me as a user /nothing/ to have both `std::find` and
> `basic_string::find`. Does it hurt my program in any way that I could
> have used `std::find` instead of the member function? No. Does it make
> my program in any way confusing? No. Does it make my program run any
> slower? No. It doesn't even make my executable bigger, since either way,
> it'll compile down to an inlined function.
>
> Then so long as there are genuine benefits to the member function
> version (like being able to take integer indices), what's the big deal?
It affects interface conciseness. As a user you have to learn what those
functions do, why they are there, and when to use them and not the
standalone algorithms. Frankly, I did not find a definitive answer to
these questions myself after years of programming practice.
Index-based interface of these functions is not an advantage that
warrants their existence because you can trivially convert indices into
iterators yourself (and I'm sure these functions do that internally
anyway). Yet that interface requires std::string::npos, a special magic
number, which one has to check for everywhere, including those member
functions. You may argue that the number is named and that it's probably
((size_t)-1) so that you'll never have a string that large, and checking
for it is not expensive, but still it rubs me the wrong way every time I
see it. So what is the reason to use the index-based interface then?
There is also a cost if you want to implement a class that mimics
std::string. I've done that a few times, and those member functions do
add complexity to the task.
There is obviously a cost for standard library implementers and standard
writers and committee.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b451816-d2fc-ef94-0e5e-9d23215f35ce%40gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 30 Dec 2016 13:13:47 +0300
Raw View
On 12/30/16 13:08, Andrey Semashev wrote:
> On 12/30/16 08:23, Nicol Bolas wrote:
>> On Thursday, December 29, 2016 at 8:33:20 PM UTC-5, Andrey Semashev
>> wrote:
>>
>> I'm not familiar with Qt implementation, but I suspect it doesn't do
>> anything significantly more optimized than libc string functions. I
>> know at least gcc is able to convert std::copy/std::fill into
>> memcpy/memset calls when possible, and I see no reason why it
>> couldn't
>> convert std::find/std::equal into memmem/memcmp. Does Qt do something
>> better than that?
>>
>> Here's a better question: so what if it doesn't?
>>
>> I'm in favor of QOI when it comes to algorithms. But at the end of the
>> day, it costs me as a user /nothing/ to have both `std::find` and
>> `basic_string::find`. Does it hurt my program in any way that I could
>> have used `std::find` instead of the member function? No. Does it make
>> my program in any way confusing? No. Does it make my program run any
>> slower? No. It doesn't even make my executable bigger, since either way,
>> it'll compile down to an inlined function.
>>
>> Then so long as there are genuine benefits to the member function
>> version (like being able to take integer indices), what's the big deal?
>
> It affects interface conciseness. As a user you have to learn what those
> functions do, why they are there, and when to use them and not the
> standalone algorithms. Frankly, I did not find a definitive answer to
> these questions myself after years of programming practice.
>
> Index-based interface of these functions is not an advantage that
> warrants their existence because you can trivially convert indices into
> iterators yourself (and I'm sure these functions do that internally
> anyway). Yet that interface requires std::string::npos, a special magic
> number, which one has to check for everywhere, including those member
> functions. You may argue that the number is named and that it's probably
> ((size_t)-1) so that you'll never have a string that large, and checking
> for it is not expensive, but still it rubs me the wrong way every time I
> see it. So what is the reason to use the index-based interface then?
>
> There is also a cost if you want to implement a class that mimics
> std::string. I've done that a few times, and those member functions do
> add complexity to the task.
I'll add that now the standard library did that once as well, in
std::string_view.
> There is obviously a cost for standard library implementers and standard
> writers and committee.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6ecd63a7-7725-efa6-48b2-4a0de57eb12e%40gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 10:06:23 -0200
Raw View
Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 04:33:15 BRST, Andrey Semas=
hev=20
escreveu:
> On Fri, Dec 30, 2016 at 1:30 AM, Thiago Macieira <thiago@macieira.org>=20
wrote:
> > And yet hardly any compiler will optimise as well as the dedicated copi=
es
> > of those functions that exist for QString inside QtCore.
>=20
> I'm not familiar with Qt implementation, but I suspect it doesn't do
> anything significantly more optimized than libc string functions. I
> know at least gcc is able to convert std::copy/std::fill into
> memcpy/memset calls when possible, and I see no reason why it couldn't
> convert std::find/std::equal into memmem/memcmp. Does Qt do something
> better than that?
Now try that for std::u16string and std::wstring.
And yes, it does something better than that because the libc functions are=
=20
optimised differently. memcmp is optimised for large data blocks, but most=
=20
strings are actually quite short, to the point that the necessary detection=
at=20
runtime to figure out the best strategy for long and short strings is enoug=
h=20
overhead.
By having a dedicated function somewhere, an implementation can provide an=
=20
out-of-line copy, hand-rolled for the use-cases.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3884640.PO38xQy1ar%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 10:09:55 -0200
Raw View
Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 21:23:58 BRST, Nicol Bolas=
=20
escreveu:
> I'm in favor of QOI when it comes to algorithms. But at the end of the da=
y,
> it costs me as a user *nothing* to have both `std::find` and
> `basic_string::find`.=20
I agree with that, but not with your conclusions.
> Does it hurt my program in any way that I could have
> used `std::find` instead of the member function? No. Does it make my
> program in any way confusing? No.=20
It could hurt, but it's probably not confusing.
> Does it make my program run any slower? No.=20
It could, if they are optimised differently. If you use the generic functio=
n=20
that is optimised for amortising its set up cost over 1 kB of data on a 64-
byte data block instead of the function optimised for less than 128 bytes,=
=20
then your code will run slower.
> It doesn't even make my executable bigger, since either way, it'll
> compile down to an inlined function.
Uh... that makes it bigger, not smaller. Compiling to more inlined code alw=
ays=20
makes it bigger. If you want to make it smaller, you have to call the same=
=20
out-of-line function.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1716747.Z4oPCp04dD%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 10:16:58 -0200
Raw View
Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 13:08:11 BRST, Andrey Semas=
hev=20
escreveu:
> It affects interface conciseness. As a user you have to learn what those
> functions do, why they are there, and when to use them and not the
> standalone algorithms. Frankly, I did not find a definitive answer to
> these questions myself after years of programming practice.
A function called "find" somewhere does the same as another function called=
=20
"find" elsewhere. Naming matters. So just name like functions likewise, and=
=20
unlike functions differently.
This way, the learning carries from one place to the next.
Also, I don't subscribe to the concise-interface paradigm as much as you (a=
nd=20
I guess Bjarne) do. I don't think a date class needs to have a=20
"find_next_friday" function, but I do think useful functions should be adde=
d.
> Index-based interface of these functions is not an advantage that
> warrants their existence because you can trivially convert indices into
> iterators yourself (and I'm sure these functions do that internally
> anyway). Yet that interface requires std::string::npos, a special magic
> number, which one has to check for everywhere, including those member
> functions. You may argue that the number is named and that it's probably
> ((size_t)-1) so that you'll never have a string that large, and checking
> for it is not expensive, but still it rubs me the wrong way every time I
> see it. So what is the reason to use the index-based interface then?
Because people are used to it and expect it. There's a self-reinfocing cycl=
e=20
here: people learnt it, so they use that technique in their code; which mak=
es=20
new developers learn it too, then use it again and again.
Breaking the cycle is possible, but you're going to cause grief to people w=
ho=20
are used to and expect that technique.
> There is also a cost if you want to implement a class that mimics
> std::string. I've done that a few times, and those member functions do
> add complexity to the task.
True, but that's not an issue we have to concern ourselves with. That happe=
ns=20
very infrequently, it's always done by experts, and if you want to implemen=
t a=20
very core class, you know you have an uphill battle.
> There is obviously a cost for standard library implementers and standard
> writers and committee.
True, but like the reimplementation, it happens once only, thereafter only=
=20
maintenance. But it may save hundreds of hours of work down the line by oth=
er=20
people.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3451251.E3cW5T57FE%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 10:19:17 -0200
Raw View
Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 21:15:50 BRST, Nicol Bolas=
=20
escreveu:
> Don't misunderstand my point; it's a perfectly fine design. I was just
> pointing out that this makes it essentially impossible to have both a
> single-allocation append design and in-situ string formatting during appe=
nd
> operations.
>=20
> So it's probably best to leave that alone.
That's why I've been saying that single-allocation appending and formatting=
=20
should be separate things.
But to enable the latter, the former should allow for a generator object th=
at=20
can specify the maximum size on constant time, then inform what the actual=
=20
size later.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2064907.bserQZRNqv%40tjmaciei-mobl1.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 30 Dec 2016 16:07:45 +0300
Raw View
On 12/30/16 15:06, Thiago Macieira wrote:
> Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 04:33:15 BRST, Andrey Sem=
ashev
> escreveu:
>> On Fri, Dec 30, 2016 at 1:30 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
>>> And yet hardly any compiler will optimise as well as the dedicated copi=
es
>>> of those functions that exist for QString inside QtCore.
>>
>> I'm not familiar with Qt implementation, but I suspect it doesn't do
>> anything significantly more optimized than libc string functions. I
>> know at least gcc is able to convert std::copy/std::fill into
>> memcpy/memset calls when possible, and I see no reason why it couldn't
>> convert std::find/std::equal into memmem/memcmp. Does Qt do something
>> better than that?
>
> Now try that for std::u16string and std::wstring.
The only problem is with memset, and it's partly mitigated by wmemset.=20
The other functions don't depend on character sizes.
> And yes, it does something better than that because the libc functions ar=
e
> optimised differently. memcmp is optimised for large data blocks, but mos=
t
> strings are actually quite short, to the point that the necessary detecti=
on at
> runtime to figure out the best strategy for long and short strings is eno=
ugh
> overhead.
>
> By having a dedicated function somewhere, an implementation can provide a=
n
> out-of-line copy, hand-rolled for the use-cases.
Ok, I see. But is there a reason to have these optimized algorithms as=20
class members as opposed to free functions? Why limit their use to a=20
particular class? I mean, std::string_view and other user-defined=20
analogues of std::string (maybe even Qt included) could just make use of=20
the optimized string algorithms in the standard library, if they were=20
standalone and generic enough.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ffd6dc3c-6d3b-f5b0-5a16-73aa9463ae92%40gmail.com=
..
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 11:21:08 -0200
Raw View
Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:07:45 BRST, Andrey Semas=
hev=20
escreveu:
> > Now try that for std::u16string and std::wstring.
>=20
> The only problem is with memset, and it's partly mitigated by wmemset.
> The other functions don't depend on character sizes.
Sure they do. memchr finds a single byte, not a word of 2 or 4 bytes. memcm=
p is=20
the same: it does a byte-by-byte comparison and returns a difference of the=
=20
first byte that compared differently. Except that the difference is very li=
kely=20
incorrect for a 2-byte word on little-endian machines.
You can implement 2- and 4-byte string operations on top of the 1-byte libc=
=20
functions, but they won't be as efficient as the implementations doing dire=
ct 2-
and 4-byte ops.
> > By having a dedicated function somewhere, an implementation can provide=
an
> > out-of-line copy, hand-rolled for the use-cases.
>=20
> Ok, I see. But is there a reason to have these optimized algorithms as
> class members as opposed to free functions? Why limit their use to a
> particular class? I mean, std::string_view and other user-defined
> analogues of std::string (maybe even Qt included) could just make use of
> the optimized string algorithms in the standard library, if they were
> standalone and generic enough.
The question here is different. I'd like to have those methods accessible t=
o=20
me without using std::string (though std::u16string_view would do nicely).
But I think they should be available as members for other reasons besides=
=20
efficiency.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1600353.4PXnUuzDvH%40tjmaciei-mobl1.
.
Author: Bo Persson <bop@gmb.dk>
Date: Fri, 30 Dec 2016 14:52:21 +0100
Raw View
On 2016-12-30 13:09, Thiago Macieira wrote:
> Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 21:23:58 BRST, Nicol Bol=
as
> escreveu:
>> It doesn't even make my executable bigger, since either way, it'll
>> compile down to an inlined function.
>
> Uh... that makes it bigger, not smaller. Compiling to more inlined code a=
lways
> makes it bigger. If you want to make it smaller, you have to call the sam=
e
> out-of-line function.
>
Not *always*. Inlined code can open up new opportunities for the=20
optimizer, and save lots of code compared to passing parameters and=20
calling out-of-line functions.
Here is one example of when extensive inlining makes the code *a lot*=20
smaller:
http://stackoverflow.com/questions/11638271/examples-of-when-a-bitwise-swap=
-is-a-bad-idea/11639305#11639305
Bo Persson
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/o45oqf%24s89%241%40blaine.gmane.org.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 30 Dec 2016 16:58:18 +0300
Raw View
On 12/30/16 16:21, Thiago Macieira wrote:
> Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:07:45 BRST, Andrey Sem=
ashev
> escreveu:
>>> Now try that for std::u16string and std::wstring.
>>
>> The only problem is with memset, and it's partly mitigated by wmemset.
>> The other functions don't depend on character sizes.
>
> Sure they do. memchr finds a single byte, not a word of 2 or 4 bytes.
I listed memmem, which searches an arbitrarily sized needle. On systems=20
where it is absent, it is very easy to emulate through memchr.
> memcmp is
> the same: it does a byte-by-byte comparison and returns a difference of t=
he
> first byte that compared differently.
No it doesn't. Its result is <0, 0 or >0, and not necessarilly the=20
difference.
> Except that the difference is very likely
> incorrect for a 2-byte word on little-endian machines.
Ah, right. We have wmemcmp then.
>> Ok, I see. But is there a reason to have these optimized algorithms as
>> class members as opposed to free functions? Why limit their use to a
>> particular class? I mean, std::string_view and other user-defined
>> analogues of std::string (maybe even Qt included) could just make use of
>> the optimized string algorithms in the standard library, if they were
>> standalone and generic enough.
>
> The question here is different. I'd like to have those methods accessible=
to
> me without using std::string (though std::u16string_view would do nicely)=
..
>
> But I think they should be available as members for other reasons besides
> efficiency.
What are those reasons?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/210278e3-9a27-b7fb-833f-5b368406bb6e%40gmail.com=
..
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 11:58:31 -0200
Raw View
Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 14:52:21 BRST, Bo Persson e=
screveu:
> On 2016-12-30 13:09, Thiago Macieira wrote:
> > Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 21:23:58 BRST, Nicol B=
olas
> >=20
> > escreveu:
> >> It doesn't even make my executable bigger, since either way, it'll
> >> compile down to an inlined function.
> >=20
> > Uh... that makes it bigger, not smaller. Compiling to more inlined code
> > always makes it bigger. If you want to make it smaller, you have to cal=
l
> > the same out-of-line function.
>=20
> Not *always*. Inlined code can open up new opportunities for the
> optimizer, and save lots of code compared to passing parameters and
> calling out-of-line functions.
Right, I apologise for the generalisation.
But in this case it holds true: those functions aren't trivial, so inlining=
=20
them at every call place increases the code size, not descreases.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1631968.7G42dsh6pa%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 12:46:04 -0200
Raw View
Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST, Andrey Semas=
hev=20
escreveu:
> On 12/30/16 16:21, Thiago Macieira wrote:
> > Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:07:45 BRST, Andrey S=
emashev
> >=20
> > escreveu:
> >>> Now try that for std::u16string and std::wstring.
> >>=20
> >> The only problem is with memset, and it's partly mitigated by wmemset.
> >> The other functions don't depend on character sizes.
> >=20
> > Sure they do. memchr finds a single byte, not a word of 2 or 4 bytes.
>=20
> I listed memmem, which searches an arbitrarily sized needle. On systems
> where it is absent, it is very easy to emulate through memchr.
But not as efficient if you're looking at words, not just needles.
Take the following array of 16-bit elements:
{ 0x0102, 0x0304, 0x0506, 0 }
On little-endian machines, that's the byte sequence
02 01 04 03 06 05 00 00
If you search for 0x401 with memmem, you're going to find it at byte index =
1,=20
but that's not a valid match because it straddles the boundary of two 16-bi=
t=20
elements.=20
If you searched for 0x404 with memchr, you'd search first for 0x04, which y=
ou'd=20
find at byte index 2, so it's valid, only to conclude that the next byte is=
n't=20
a match.
> > memcmp is
> > the same: it does a byte-by-byte comparison and returns a difference of
> > the
> > first byte that compared differently.
>=20
> No it doesn't. Its result is <0, 0 or >0, and not necessarilly the
> difference.
Either way, it can be wrong. Take these two strings:
u"ABC\u0180" =3D> 41 00 42 00 43 00 80 01
u"ABC\u027F" =3D> 41 00 42 00 43 00 7F 02
A proper char16_t comparison should find that the first string is less than=
the=20
second. But a pure memcmp will find that byte index 6 differs and that 0x7F=
is=20
less than 0x80, so the second string is less than the first.
So memcmp won't cut it. You need a function that returns the pointer to or=
=20
index of the first byte that compared unequally, so that you can inspect th=
e=20
word that contains that differing byte. There's no such function in libc.
> > Except that the difference is very likely
> > incorrect for a 2-byte word on little-endian machines.
>=20
> Ah, right. We have wmemcmp then.
wchar_t is 4 bytes on Unix systems, so it won't help for char16_t. Where is=
is=20
2 bytes, it won't help for char32_t.
> > But I think they should be available as members for other reasons besid=
es
> > efficiency.
>=20
> What are those reasons?
I explained in another email: convenience and difference in philosophy. I d=
o=20
believe a class should provide as members most of the common operations to =
be=20
done to its data. That's why QString has startsWith() and endsWith(), which=
=20
are trivially easy to implement.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1537490.zR3xCGS3bO%40tjmaciei-mobl1.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 30 Dec 2016 17:56:00 +0100
Raw View
2016-12-30 15:46 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST, Andrey Sem=
ashev
> escreveu:
> I explained in another email: convenience and difference in philosophy. I=
do
> believe a class should provide as members most of the common operations t=
o be
> done to its data. That's why QString has startsWith() and endsWith(), whi=
ch
> are trivially easy to implement.
However, if those are implemented as free functions taking something
like string_view, other string types would be able to take advantage
of them too...
--=20
Olaf
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7U3HNvqJiB9-ViHrXyTkk-qEN0nGs12Ty1DX%2BBJq0VS=
Dva%3DA%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 30 Dec 2016 09:10:22 -0800 (PST)
Raw View
------=_Part_7935_574418887.1483117822288
Content-Type: multipart/alternative;
boundary="----=_Part_7936_453299298.1483117822289"
------=_Part_7936_453299298.1483117822289
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, December 30, 2016 at 8:58:36 AM UTC-5, Thiago Macieira wrote:
>
> Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 14:52:21 BRST, Bo Persson=
=20
> escreveu:=20
> > On 2016-12-30 13:09, Thiago Macieira wrote:=20
> > > Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 21:23:58 BRST, Nicol=
Bolas=20
> > >=20
> > > escreveu:=20
> > >> It doesn't even make my executable bigger, since either way, it'll=
=20
> > >> compile down to an inlined function.=20
> > >=20
> > > Uh... that makes it bigger, not smaller. Compiling to more inlined=20
> code=20
> > > always makes it bigger. If you want to make it smaller, you have to=
=20
> call=20
> > > the same out-of-line function.=20
> >=20
> > Not *always*. Inlined code can open up new opportunities for the=20
> > optimizer, and save lots of code compared to passing parameters and=20
> > calling out-of-line functions.=20
>
> Right, I apologise for the generalisation.=20
>
> But in this case it holds true: those functions aren't trivial, so=20
> inlining=20
> them at every call place increases the code size, not descreases.=20
>
My point was that both implementations, the member version and free=20
function, would be inlined to the same code. So neither will be bigger=20
relative to the other.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a8eda984-2e91-40d9-a1e7-35e0901d8362%40isocpp.or=
g.
------=_Part_7936_453299298.1483117822289
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 30, 2016 at 8:58:36 AM UTC-5, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em sexta-feira, =
30 de dezembro de 2016, =C3=A0s 14:52:21 BRST, Bo Persson escreveu:
<br>> On 2016-12-30 13:09, Thiago Macieira wrote:
<br>> > Em quinta-feira, 29 de dezembro de 2016, =C3=A0s 21:23:58 BRS=
T, Nicol Bolas
<br>> >=20
<br>> > escreveu:
<br>> >> It doesn't even make my executable bigger, since eith=
er way, it'll
<br>> >> compile down to an inlined function.
<br>> >=20
<br>> > Uh... that makes it bigger, not smaller. Compiling to more in=
lined code
<br>> > always makes it bigger. If you want to make it smaller, you h=
ave to call
<br>> > the same out-of-line function.
<br>>=20
<br>> Not *always*. Inlined code can open up new opportunities for the
<br>> optimizer, and save lots of code compared to passing parameters an=
d
<br>> calling out-of-line functions.
<br>
<br>Right, I apologise for the generalisation.
<br>
<br>But in this case it holds true: those functions aren't trivial, so =
inlining=20
<br>them at every call place increases the code size, not descreases.
<br></blockquote><div><br>My point was that both implementations, the membe=
r version and free function, would be inlined to the same code. So neither =
will be bigger relative to the other.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a8eda984-2e91-40d9-a1e7-35e0901d8362%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8eda984-2e91-40d9-a1e7-35e0901d8362=
%40isocpp.org</a>.<br />
------=_Part_7936_453299298.1483117822289--
------=_Part_7935_574418887.1483117822288--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 30 Dec 2016 09:21:52 -0800 (PST)
Raw View
------=_Part_2336_2052931898.1483118512895
Content-Type: multipart/alternative;
boundary="----=_Part_2337_1539884550.1483118512895"
------=_Part_2337_1539884550.1483118512895
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, December 30, 2016 at 11:56:02 AM UTC-5, Olaf van der Spek wrote:
>
> 2016-12-30 15:46 GMT+01:00 Thiago Macieira <thi...@macieira.org=20
> <javascript:>>:=20
> > Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST, Andrey=
=20
> Semashev=20
> > escreveu:=20
> > I explained in another email: convenience and difference in philosophy.=
=20
> I do=20
> > believe a class should provide as members most of the common operations=
=20
> to be=20
> > done to its data. That's why QString has startsWith() and endsWith(),=
=20
> which=20
> > are trivially easy to implement.=20
>
> However, if those are implemented as free functions taking something=20
> like string_view, other string types would be able to take advantage=20
> of them too...
>
Sure. But the problem with over-genericization is that, anyone who is not=
=20
steeped in the lore of all your generic algorithms can't figure out how to=
=20
do something simple.
`startsWith` is a perfectly fine and descriptive name, for a string member=
=20
function. The context and its parameters explain what it's doing. But the=
=20
non-member generic version couldn't be simply named `starts_with`. It would=
=20
have to be something like `matches_initial_sequence`. Far less descriptive.=
=20
Plus, there's the fact that it can conceptually work with any forward=20
range(s), which makes it less likely that someone looking for how to do=20
this test on strings will find it.
What's worse is that people could easily argue that we don't need=20
`matches_initial_sequence` at all. Once we have ranges, people can argue=20
that `matches_initial_sequence is equivalent to `std::equal(some_str |=20
initial_sequence(size(other_str)), other_str);` So do we really need such a=
=20
function? I could see people arguing that it's just added "bloat".
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/276e5471-0614-47ae-8b78-bef265751119%40isocpp.or=
g.
------=_Part_2337_1539884550.1483118512895
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 30, 2016 at 11:56:02 AM UTC-5, Olaf va=
n der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-12-30 15=
:46 GMT+01:00 Thiago Macieira <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"lb1rRcY_CgAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">thi...@macieira.org</a>>:
<br>> Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST, And=
rey Semashev
<br>> escreveu:
<br>> I explained in another email: convenience and difference in philos=
ophy. I do
<br>> believe a class should provide as members most of the common opera=
tions to be
<br>> done to its data. That's why QString has startsWith() and ends=
With(), which
<br>> are trivially easy to implement.
<br>
<br>However, if those are implemented as free functions taking something
<br>like string_view, other string types would be able to take advantage
<br>of them too...<br></blockquote><div><br>Sure. But the problem with over=
-genericization is that, anyone who is not steeped in the lore of all your =
generic algorithms can't figure out how to do something simple.<br><br>=
`startsWith` is a perfectly fine and descriptive name, for a string member =
function. The context and its parameters explain what it's doing. But t=
he non-member generic version couldn't be simply named `starts_with`. I=
t would have to be something like `matches_initial_sequence`. Far less desc=
riptive. Plus, there's the fact that it can conceptually work with any =
forward range(s), which makes it less likely that someone looking for how t=
o do this test on strings will find it.<br><br>What's worse is that peo=
ple could easily argue that we don't need `matches_initial_sequence` at=
all. Once we have ranges, people can argue that `matches_initial_sequence =
is equivalent to `std::equal(some_str | initial_sequence(size(other_str)), =
other_str);` So do we really need such a function? I could see people argui=
ng that it's just added "bloat".<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/276e5471-0614-47ae-8b78-bef265751119%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/276e5471-0614-47ae-8b78-bef265751119=
%40isocpp.org</a>.<br />
------=_Part_2337_1539884550.1483118512895--
------=_Part_2336_2052931898.1483118512895--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 30 Dec 2016 18:24:00 +0100
Raw View
2016-12-30 18:21 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> On Friday, December 30, 2016 at 11:56:02 AM UTC-5, Olaf van der Spek wrot=
e:
>>
>> 2016-12-30 15:46 GMT+01:00 Thiago Macieira <thi...@macieira.org>:
>> > Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST, Andrey
>> > Semashev
>> > escreveu:
>> > I explained in another email: convenience and difference in philosophy=
..
>> > I do
>> > believe a class should provide as members most of the common operation=
s
>> > to be
>> > done to its data. That's why QString has startsWith() and endsWith(),
>> > which
>> > are trivially easy to implement.
>>
>> However, if those are implemented as free functions taking something
>> like string_view, other string types would be able to take advantage
>> of them too...
>
>
> Sure. But the problem with over-genericization is that, anyone who is not
> steeped in the lore of all your generic algorithms can't figure out how t=
o
> do something simple.
>
> `startsWith` is a perfectly fine and descriptive name, for a string membe=
r
> function. The context and its parameters explain what it's doing. But the
> non-member generic version couldn't be simply named `starts_with`. It wou=
ld
Why not? Works fine for Boost:
http://www.boost.org/doc/libs/1_63_0/doc/html/boost/algorithm/starts_with.h=
tml
> have to be something like `matches_initial_sequence`. Far less descriptiv=
e.
> Plus, there's the fact that it can conceptually work with any forward
> range(s), which makes it less likely that someone looking for how to do t=
his
> test on strings will find it.
>
> What's worse is that people could easily argue that we don't need
> `matches_initial_sequence` at all. Once we have ranges, people can argue
> that `matches_initial_sequence is equivalent to `std::equal(some_str |
> initial_sequence(size(other_str)), other_str);` So do we really need such=
a
> function? I could see people arguing that it's just added "bloat".
Hehe
--=20
Olaf
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7U3HMQc0t0eWdzJ_YkNks5VFURHm5j_uUAzyV5FCudW8a=
JrA%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 30 Dec 2016 10:16:26 -0800 (PST)
Raw View
------=_Part_7744_984629354.1483121786808
Content-Type: multipart/alternative;
boundary="----=_Part_7745_923926704.1483121786809"
------=_Part_7745_923926704.1483121786809
Content-Type: text/plain; charset=UTF-8
On Friday, December 30, 2016 at 5:08:17 AM UTC-5, Andrey Semashev wrote:
>
> On 12/30/16 08:23, Nicol Bolas wrote:
> > On Thursday, December 29, 2016 at 8:33:20 PM UTC-5, Andrey Semashev
> wrote:
> >
> > I'm not familiar with Qt implementation, but I suspect it doesn't do
> > anything significantly more optimized than libc string functions. I
> > know at least gcc is able to convert std::copy/std::fill into
> > memcpy/memset calls when possible, and I see no reason why it
> couldn't
> > convert std::find/std::equal into memmem/memcmp. Does Qt do
> something
> > better than that?
> >
> > Here's a better question: so what if it doesn't?
> >
> > I'm in favor of QOI when it comes to algorithms. But at the end of the
> > day, it costs me as a user /nothing/ to have both `std::find` and
> > `basic_string::find`. Does it hurt my program in any way that I could
> > have used `std::find` instead of the member function? No. Does it make
> > my program in any way confusing? No. Does it make my program run any
> > slower? No. It doesn't even make my executable bigger, since either way,
> > it'll compile down to an inlined function.
> >
> > Then so long as there are genuine benefits to the member function
> > version (like being able to take integer indices), what's the big deal?
>
> It affects interface conciseness. As a user you have to learn what those
> functions do, why they are there, and when to use them and not the
> standalone algorithms. Frankly, I did not find a definitive answer to
> these questions myself after years of programming practice.
>
> Index-based interface of these functions is not an advantage that
> warrants their existence because you can trivially convert indices into
> iterators yourself (and I'm sure these functions do that internally
> anyway). Yet that interface requires std::string::npos, a special magic
> number, which one has to check for everywhere, including those member
> functions. You may argue that the number is named and that it's probably
> ((size_t)-1) so that you'll never have a string that large, and checking
> for it is not expensive, but still it rubs me the wrong way every time I
> see it. So what is the reason to use the index-based interface then?
>
Interface conciseness is less important than overall readability. Consider
a relatively simple programming task. You're given two strings. You want to
find the last instance of string B within string A, then generate a string
that consists of all characters *before* the instance you found.
This is what the implementation based on generic algorithms and iterators
looks like:
std::string generic(std::string look, std::string pattern)
{
auto loc = std::search(look.rbegin(), look.rend(),
pattern.rbegin(), pattern.rend());
if(loc != look.rend())
{
loc += pattern.size();
return std::string(look.begin(), loc.base());
}
else
return std::string{};
}
Understanding this code requires being well versed in how reverse iterators
work. Two particularly non-obvious things I had to do were: 1) reversing
the *pattern* as well as the string being searched and 2) offsetting `loc`
by the pattern's size, since that's not the actual location.
This is what the index&member function version looks like:
std::string member(std::string look, std::string pattern)
{
auto loc = look.rfind(pattern);
if(loc != std::string::npos)
{
return look.substr(0, loc);
}
return std::string{};
}
That's much shorter and more easily understood. There's no need to reverse
the pattern's range, nor the mysterious offset. The only thing that might
be at all confusing is the test against `npos`. But that's ultimately no
different from testing against `look.rend()`.
As for compiler optimizations, here are the compiled results for GCC 7,
under -O3 <https://godbolt.org/g/xDFhgs>. It seems to me that `member` is
much shorter in assembly than `generic`, requiring a lot fewer jumps and
the like. So your "the compiler can sort it out" argument seems to not be
true in this case.
There is also a cost if you want to implement a class that mimics
> std::string. I've done that a few times, and those member functions do
> add complexity to the task.
>
> There is obviously a cost for standard library implementers and standard
> writers and committee.
>
So you're saying that we should avoid good APIs because they're hard to get
through committee? That sounds like a problem with the committee process,
not with the API.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f69bf759-012d-4524-a3f4-e59a6d9f17ee%40isocpp.org.
------=_Part_7745_923926704.1483121786809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 30, 2016 at 5:08:17 AM UTC-5, Andrey S=
emashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12/30/16 08:2=
3, Nicol Bolas wrote:
<br>> On Thursday, December 29, 2016 at 8:33:20 PM UTC-5, Andrey Semashe=
v wrote:
<br>>
<br>> =C2=A0 =C2=A0 I'm not familiar with Qt implementation, but I s=
uspect it doesn't do
<br>> =C2=A0 =C2=A0 anything significantly more optimized than libc stri=
ng functions. I
<br>> =C2=A0 =C2=A0 know at least gcc is able to convert std::copy/std::=
fill into
<br>> =C2=A0 =C2=A0 memcpy/memset calls when possible, and I see no reas=
on why it couldn't
<br>> =C2=A0 =C2=A0 convert std::find/std::equal into memmem/memcmp. Doe=
s Qt do something
<br>> =C2=A0 =C2=A0 better than that?
<br>>
<br>> Here's a better question: so what if it doesn't?
<br>>
<br>> I'm in favor of QOI when it comes to algorithms. But at the en=
d of the
<br>> day, it costs me as a user /nothing/ to have both `std::find` and
<br>> `basic_string::find`. Does it hurt my program in any way that I co=
uld
<br>> have used `std::find` instead of the member function? No. Does it =
make
<br>> my program in any way confusing? No. Does it make my program run a=
ny
<br>> slower? No. It doesn't even make my executable bigger, since e=
ither way,
<br>> it'll compile down to an inlined function.
<br>>
<br>> Then so long as there are genuine benefits to the member function
<br>> version (like being able to take integer indices), what's the =
big deal?
<br>
<br>It affects interface conciseness. As a user you have to learn what thos=
e=20
<br>functions do, why they are there, and when to use them and not the=20
<br>standalone algorithms. Frankly, I did not find a definitive answer to=
=20
<br>these questions myself after years of programming practice.
<br>
<br>Index-based interface of these functions is not an advantage that=20
<br>warrants their existence because you can trivially convert indices into=
=20
<br>iterators yourself (and I'm sure these functions do that internally=
=20
<br>anyway). Yet that interface requires std::string::npos, a special magic=
=20
<br>number, which one has to check for everywhere, including those member=
=20
<br>functions. You may argue that the number is named and that it's pro=
bably=20
<br>((size_t)-1) so that you'll never have a string that large, and che=
cking=20
<br>for it is not expensive, but still it rubs me the wrong way every time =
I=20
<br>see it. So what is the reason to use the index-based interface then?<br=
></blockquote><div><br>Interface conciseness is less important than overall=
readability. Consider a relatively simple programming task. You're giv=
en two strings. You want to find the last instance of string B within strin=
g A, then generate a string that consists of all characters <i>before</i> t=
he instance you found.<br><br>This is what the implementation based on gene=
ric algorithms and iterators looks like:<br><br><div style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> generic</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">strin=
g</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> look</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> pattern</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> loc </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">search</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
look</span><span style=3D"color: #660;" class=3D"styled-by-prettify"></span=
></code><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">rbegin</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><code class=3D"prett=
yprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">look</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></code><=
span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">rend</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pattern<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">rbegin</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> pattern</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">rend</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">());</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">loc </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><code class=3D"prettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">look</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"></span></code><span style=3D=
"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">rend</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 loc </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> pattern</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">size</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><code class=3D"prettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">look</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"></span></code><span style=3D"color: #660;"=
class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">begin</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> loc</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">base</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">());</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">else</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
br>Understanding this code requires being well versed in how reverse iterat=
ors work. Two particularly non-obvious things I had to do were: 1) reversin=
g the <i>pattern</i> as well as the string being searched and 2) offsetting=
`loc` by the pattern's size, since that's not the actual location.=
<br><br>This is what the index&member function version looks like:<br><=
br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-=
word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> member</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> look</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> pattern</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> loc </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> look</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">rfind</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>pattern</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">if</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">l=
oc </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">npos</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> look</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">substr</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> loc</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>=
That's much shorter and more easily understood. There's no need to =
reverse the pattern's range, nor the mysterious offset. The only thing =
that might be at all confusing is the test against `npos`. But that's u=
ltimately no different from testing against `look.rend()`.<br><br>As for co=
mpiler optimizations, <a href=3D"https://godbolt.org/g/xDFhgs">here are the=
compiled results for GCC 7, under -O3</a>. It seems to me that `member` is=
much shorter in assembly than `generic`, requiring a lot fewer jumps and t=
he like. So your "the compiler can sort it out" argument seems to=
not be true in this case.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">
There is also a cost if you want to implement a class that mimics=20
<br>std::string. I've done that a few times, and those member functions=
do=20
<br>add complexity to the task.
<br>
<br>There is obviously a cost for standard library implementers and standar=
d=20
<br>writers and committee.<br></blockquote><div><br>So you're saying th=
at we should avoid good APIs because they're hard to get through commit=
tee? That sounds like a problem with the committee process, not with the AP=
I. <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f69bf759-012d-4524-a3f4-e59a6d9f17ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f69bf759-012d-4524-a3f4-e59a6d9f17ee=
%40isocpp.org</a>.<br />
------=_Part_7745_923926704.1483121786809--
------=_Part_7744_984629354.1483121786808--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Dec 2016 16:49:58 -0200
Raw View
Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 17:56:00 BRST, Olaf van der=
Spek=20
escreveu:
> 2016-12-30 15:46 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> > Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST, Andrey S=
emashev
> > escreveu:
> > I explained in another email: convenience and difference in philosophy.=
I
> > do believe a class should provide as members most of the common
> > operations to be done to its data. That's why QString has startsWith()
> > and endsWith(), which are trivially easy to implement.
>=20
> However, if those are implemented as free functions taking something
> like string_view, other string types would be able to take advantage
> of them too...
I don't see it that way. Like I said, they're trivially easy to implement, =
so=20
they're trivially easy to reimplement. They can be implemented multiple tim=
es,=20
one for each string-like class.
Or std::string could delegate everything to std::string_view on itself. Thi=
s=20
achieves high code reuse.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1561722.hH4c4B51Y2%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 30 Dec 2016 17:48:35 -0800 (PST)
Raw View
------=_Part_8130_1322783983.1483148915954
Content-Type: multipart/alternative;
boundary="----=_Part_8131_448690233.1483148915954"
------=_Part_8131_448690233.1483148915954
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, December 30, 2016 at 1:50:02 PM UTC-5, Thiago Macieira wrote:
>
> Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 17:56:00 BRST, Olaf van d=
er=20
> Spek=20
> escreveu:=20
> > 2016-12-30 15:46 GMT+01:00 Thiago Macieira <thi...@macieira.org=20
> <javascript:>>:=20
> > > Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST, Andrey=
=20
> Semashev=20
> > > escreveu:=20
> > > I explained in another email: convenience and difference in=20
> philosophy. I=20
> > > do believe a class should provide as members most of the common=20
> > > operations to be done to its data. That's why QString has startsWith(=
)=20
> > > and endsWith(), which are trivially easy to implement.=20
> >=20
> > However, if those are implemented as free functions taking something=20
> > like string_view, other string types would be able to take advantage=20
> > of them too...
>
> I don't see it that way. Like I said, they're trivially easy to implement=
,=20
> so=20
> they're trivially easy to reimplement. They can be implemented multiple=
=20
> times,=20
> one for each string-like class.=20
>
Any one such function is relatively easy to implement. But when you have=20
*twenty* such functions, it starts being a significant task. *Especially*=
=20
once you want to start testing them all comprehensively.
This is precisely why even simple algorithms like `search` and `accumulate`=
=20
and so forth are not bound to a specific container. Yes, we could always=20
rewrite them. But what's the point of that, when we don't *have to*?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/73bb89f8-98ae-4a4c-8a62-fba16c70353b%40isocpp.or=
g.
------=_Part_8131_448690233.1483148915954
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 30, 2016 at 1:50:02 PM UTC-5, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em sexta-feira, =
30 de dezembro de 2016, =C3=A0s 17:56:00 BRST, Olaf van der Spek=20
<br>escreveu:
<br>> 2016-12-30 15:46 GMT+01:00 Thiago Macieira <<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"zkAFqv5FCgAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">thi...@macieira.org</a>=
>:
<br>> > Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 16:58:18 BRST=
, Andrey Semashev
<br>> > escreveu:
<br>> > I explained in another email: convenience and difference in p=
hilosophy. I
<br>> > do believe a class should provide as members most of the comm=
on
<br>> > operations to be done to its data. That's why QString has=
startsWith()
<br>> > and endsWith(), which are trivially easy to implement.
<br>>=20
<br>> However, if those are implemented as free functions taking somethi=
ng
<br>> like string_view, other string types would be able to take advanta=
ge
<br>> of them too...<br>
<br>I don't see it that way. Like I said, they're trivially easy to=
implement, so=20
<br>they're trivially easy to reimplement. They can be implemented mult=
iple times,=20
<br>one for each string-like class.
<br></blockquote><div><br>Any one such function is relatively easy to imple=
ment. But when you have <i>twenty</i> such functions, it starts being a sig=
nificant task. <i>Especially</i> once you want to start testing them all co=
mprehensively.<br><br>This is precisely why even simple algorithms like `se=
arch` and `accumulate` and so forth are not bound to a specific container. =
Yes, we could always rewrite them. But what's the point of that, when w=
e don't <i>have to</i>?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/73bb89f8-98ae-4a4c-8a62-fba16c70353b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73bb89f8-98ae-4a4c-8a62-fba16c70353b=
%40isocpp.org</a>.<br />
------=_Part_8131_448690233.1483148915954--
------=_Part_8130_1322783983.1483148915954--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 31 Dec 2016 00:05:37 -0200
Raw View
Em sexta-feira, 30 de dezembro de 2016, =C3=A0s 17:48:35 BRST, Nicol Bolas=
=20
escreveu:
> > I don't see it that way. Like I said, they're trivially easy to impleme=
nt,
> > so
> > they're trivially easy to reimplement. They can be implemented multiple
> > times,
> > one for each string-like class.
>=20
> Any one such function is relatively easy to implement. But when you have
> *twenty* such functions, it starts being a significant task. *Especially*
> once you want to start testing them all comprehensively.
If they all call the same implementation, then you can test it once and it=
=20
would suffice. It is the exact same amount of testing necessary as if it we=
re=20
only a free function.
> This is precisely why even simple algorithms like `search` and `accumulat=
e`
> and so forth are not bound to a specific container. Yes, we could always
> rewrite them. But what's the point of that, when we don't *have to*?
I'm not asking for all functions to be added to each and every class. Only=
=20
those that are used very often and would benefit from conciseness of code a=
nd=20
discoverability.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1849192.zPS9UT8Wn7%40tjmaciei-mobl1.
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Fri, 30 Dec 2016 19:18:40 -0800 (PST)
Raw View
------=_Part_1059_475598495.1483154320690
Content-Type: multipart/alternative;
boundary="----=_Part_1060_757874904.1483154320691"
------=_Part_1060_757874904.1483154320691
Content-Type: text/plain; charset=UTF-8
On Friday, December 30, 2016 at 1:16:27 PM UTC-5, Nicol Bolas wrote:
>
> Interface conciseness is less important than overall readability. Consider
> a relatively simple programming task. You're given two strings. You want to
> find the last instance of string B within string A, then generate a string
> that consists of all characters *before* the instance you found.
>
> This is what the implementation based on generic algorithms and iterators
> looks like:
>
> std::string generic(std::string look, std::string pattern)
> {
> auto loc = std::search(look.rbegin(), look.rend(),
> pattern.rbegin(), pattern.rend());
>
> if(loc != look.rend())
> {
> loc += pattern.size();
> return std::string(look.begin(), loc.base());
> }
> else
> return std::string{};
> }
>
> Understanding this code requires being well versed in how reverse
> iterators work. Two particularly non-obvious things I had to do were: 1)
> reversing the *pattern* as well as the string being searched and 2)
> offsetting `loc` by the pattern's size, since that's not the actual
> location.
>
> This is what the index&member function version looks like:
>
> std::string member(std::string look, std::string pattern)
> {
> auto loc = look.rfind(pattern);
>
> if(loc != std::string::npos)
> {
> return look.substr(0, loc);
> }
>
> return std::string{};
> }
>
> That's much shorter and more easily understood. There's no need to reverse
> the pattern's range, nor the mysterious offset. The only thing that might
> be at all confusing is the test against `npos`. But that's ultimately no
> different from testing against `look.rend()`.
>
Seems to me that's only because you chose a sub-optimal algorithm. You
want the one that matches string::rfind, but you used the one that matches
string::find instead, so you had to add extra code to make it work right.
Try this:
std::string generic(std::string look, std::string pattern)
{
auto loc = std::find_end(look.begin(), look.end(),
pattern.begin(), pattern.end());
if(loc != look.end())
{
return std::string(look.begin(), loc);
}
return std::string{};
}
or with Ranges:
std::string generic(std::string look, std::string pattern)
{
auto loc = std::find_end(look, pattern);
if(loc != look.end())
{
return std::string(look.begin(), loc);
}
return std::string{};
}
The generated assembly here looks to be smaller than search, but not as
small as rfind.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bd2bc535-5dd7-479b-8062-fa7a082d907a%40isocpp.org.
------=_Part_1060_757874904.1483154320691
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 30, 2016 at 1:16:27 PM UTC-5, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>Interface conciseness is less important than overall readability. Conside=
r a relatively simple programming task. You're given two strings. You w=
ant to find the last instance of string B within string A, then generate a =
string that consists of all characters <i>before</i> the instance you found=
..<br><br>This is what the implementation based on generic algorithms and it=
erators looks like:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><d=
iv><span style=3D"color:#000">std</span><span style=3D"color:#660">::</span=
><span style=3D"color:#008">string</span><span style=3D"color:#000"> generi=
c</span><span style=3D"color:#660">(</span><span style=3D"color:#000">std</=
span><span style=3D"color:#660">::</span><span style=3D"color:#008">string<=
/span><span style=3D"color:#000"> look</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#008">string</span><span style=3D"color:#000"> pat=
tern</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">auto</span><span style=3D"c=
olor:#000"> loc </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"c=
olor:#000">search</span><span style=3D"color:#660">(</span><code><span styl=
e=3D"color:#000">look</span><span style=3D"color:#660"></span></code><span =
style=3D"color:#660">.</span><span style=3D"color:#000">rbegin</span><span =
style=3D"color:#660">(),</span><span style=3D"color:#000"> </span><code><sp=
an style=3D"color:#000">look</span><span style=3D"color:#660"></span></code=
><span style=3D"color:#660">.</span><span style=3D"color:#000">rend</span><=
span style=3D"color:#660">(),</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 pattern</span><span style=3D"color:#660">.</span><span=
style=3D"color:#000">rbegin</span><span style=3D"color:#660">(),</span><sp=
an style=3D"color:#000"> pattern</span><span style=3D"color:#660">.</span><=
span style=3D"color:#000">rend</span><span style=3D"color:#660">());</span>=
<span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#008">if</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">loc </span><span style=3D"color:#660">!=
=3D</span><span style=3D"color:#000"> </span><code><span style=3D"color:#00=
0">look</span><span style=3D"color:#660"></span></code><span style=3D"color=
:#660">.</span><span style=3D"color:#000">rend</span><span style=3D"color:#=
660">())</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 loc </span><span style=3D"color:#660">+=3D</span><span style=3D"=
color:#000"> pattern</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">size</span><span style=3D"color:#660">();</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
:#008">return</span><span style=3D"color:#000"> std</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#008">string</span><span style=3D"c=
olor:#660">(</span><code><span style=3D"color:#000">look</span><span style=
=3D"color:#660"></span></code><span style=3D"color:#660">.</span><span styl=
e=3D"color:#008">begin</span><span style=3D"color:#660">(),</span><span sty=
le=3D"color:#000"> loc</span><span style=3D"color:#660">.</span><span style=
=3D"color:#008">base</span><span style=3D"color:#660">());</span><span styl=
e=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#008">else</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
</span><span style=3D"color:#008">return</span><span style=3D"color:#000">=
std</span><span style=3D"color:#660">::</span><span style=3D"color:#008">s=
tring</span><span style=3D"color:#660">{};</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#660">}</span></div></code></div><br>Under=
standing this code requires being well versed in how reverse iterators work=
.. Two particularly non-obvious things I had to do were: 1) reversing the <i=
>pattern</i> as well as the string being searched and 2) offsetting `loc` b=
y the pattern's size, since that's not the actual location.<br><br>=
This is what the index&member function version looks like:<br><br><div =
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px"><code><div><span style=3D"color:#000">st=
d</span><span style=3D"color:#660">::</span><span style=3D"color:#008">stri=
ng</span><span style=3D"color:#000"> member</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">std</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#008">string</span><span style=3D"color:#000">=
look</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
std</span><span style=3D"color:#660">::</span><span style=3D"color:#008">st=
ring</span><span style=3D"color:#000"> pattern</span><span style=3D"color:#=
660">)</span><span style=3D"color:#000"><br></span><span style=3D"color:#66=
0">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">auto</span><span style=3D"color:#000"> loc </span><span sty=
le=3D"color:#660">=3D</span><span style=3D"color:#000"> look</span><span st=
yle=3D"color:#660">.</span><span style=3D"color:#000">rfind</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">pattern</span><span st=
yle=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 <b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#008">if</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#000">loc </span><span style=3D"col=
or:#660">!=3D</span><span style=3D"color:#000"> std</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#008">string</span><span style=3D"c=
olor:#660">::</span><span style=3D"color:#000">npos</span><span style=3D"co=
lor:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span=
style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span style=3D=
"color:#000"> look</span><span style=3D"color:#660">.</span><span style=3D"=
color:#000">substr</span><span style=3D"color:#660">(</span><span style=3D"=
color:#066">0</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> loc</span><span style=3D"color:#660">);</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span><span sty=
le=3D"color:#000"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D=
"color:#008">return</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#008">string</span><span styl=
e=3D"color:#660">{};</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">}</span></div></code></div><br>That's much shorter and=
more easily understood. There's no need to reverse the pattern's r=
ange, nor the mysterious offset. The only thing that might be at all confus=
ing is the test against `npos`. But that's ultimately no different from=
testing against `look.rend()`.<br></div></div></blockquote><div><br></div>=
<div>Seems to me that's only because you chose a sub-optimal algorithm.=
=C2=A0You want the one that matches string::rfind, but you used the one th=
at matches string::find instead, so you had to add extra code to make it wo=
rk right. =C2=A0Try this:</div><div><br></div><div><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><div style=3D"borde=
r-width: 1px; border-style: solid; border-color: rgb(187, 187, 187); color:=
rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif;"><code><span s=
tyle=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">std</span></span><span style=3D"color: rgb(102, 102, 0);"><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span></span><span=
style=3D"color: rgb(0, 0, 136);"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">string</span></span><span style=3D"color: rgb(0, 0, 0);"><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> generic</span></s=
pan><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span></span><span style=3D"color: rgb(0, 0, =
0);"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span></=
span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span></span><span style=3D"color: rgb(0, 0=
, 136);"><span style=3D"color: #008;" class=3D"styled-by-prettify">string</=
span></span><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> look</span></span><span style=3D"color: rg=
b(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span></span><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> std</span></span><span style=3D"color: =
rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span></span><span style=3D"color: rgb(0, 0, 136);"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">string</span></span><span style=3D"=
color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> pattern</span></span><span style=3D"color: rgb(102, 102, 0);"><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span></span><span sty=
le=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span></span><span style=3D"color: rgb(102, 102, 0);"><span=
style=3D"color: #660;" class=3D"styled-by-prettify">{</span></span><span s=
tyle=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>=C2=A0 =C2=A0 </span></span><span style=3D"color: rgb(0, 0=
, 136);"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an></span><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> loc </span></span><span style=3D"color: rgb(=
102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span></span><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> std</span></span><span style=3D"color=
: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">find=
_end</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span></span><code><span style=
=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">look</span></span><span style=3D"color: rgb(102, 102, 0);"></span>=
</code><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span></span><span style=3D"color: rgb(0, =
0, 0);"><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</sp=
an></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(),</span></span><span style=3D"color: rg=
b(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan></span><code><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color:=
#000;" class=3D"styled-by-prettify">look</span></span><span style=3D"color=
: rgb(102, 102, 0);"></span></code><span style=3D"color: rgb(102, 102, 0);"=
><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span></span><=
span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">end</span></span><span style=3D"color: rgb(102, 102, 0);=
"><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span></spa=
n><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pattern</span></spa=
n><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">.</span></span><span style=3D"color: rgb(0, 0, 0)=
;"><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span></=
span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(),</span></span><span style=3D"color: rgb(0, =
0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify"> pattern<=
/span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color:=
#660;" class=3D"styled-by-prettify">.</span></span><span style=3D"color: r=
gb(0, 0, 0);"><span style=3D"color: #008;" class=3D"styled-by-prettify">end=
</span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color=
: #660;" class=3D"styled-by-prettify">());</span></span><span style=3D"colo=
r: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span></span><span styl=
e=3D"color: rgb(0, 0, 136);"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">if</span></span><span style=3D"color: rgb(102, 102, 0);"><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span></span><span st=
yle=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">loc </span></span><span style=3D"color: rgb(102, 102, 0);"><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</span></span><sp=
an style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span></span><code><span style=3D"color: rgb(0, 0, 0);">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">look</span></span=
><span style=3D"color: rgb(102, 102, 0);"></span></code><span style=3D"colo=
r: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span></span><span style=3D"color: rgb(0, 0, 0);"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">end</span></span><span style=3D"col=
or: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">())</span></span><span style=3D"color: rgb(0, 0, 0);"><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span></span>=
<span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span></span><span style=3D"color: rgb(0, 0, 0);"=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></spa=
n><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span></span><span sty=
le=3D"color: rgb(0, 0, 136);"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">return</span></span><span style=3D"color: rgb(0, 0, 0);"><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> std</span></span><spa=
n style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span></span><span style=3D"color: rgb(0, 0, 136);">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">string</span></sp=
an><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span></span><code><span style=3D"color: rgb(0=
, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify">look</s=
pan></span><span style=3D"color: rgb(102, 102, 0);"></span></code><span sty=
le=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span></span><span style=3D"color: rgb(0, 0, 136);"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">begin</span></span><spa=
n style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(),</span></span><span style=3D"color: rgb(0, 0, 0);"><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> loc</span></span>=
<span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span></span><span style=3D"color: rgb(0, 0, 0);=
"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span></span><span style=3D"col=
or: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></span><span style=3D"color: rgb(0, 0, 0);"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span></span><sp=
an style=3D"color: rgb(0, 0, 136);"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">return</span></span><span style=3D"color: rgb(0, 0, 0);"=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span></spa=
n><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span></span><span style=3D"color: rgb(0, 0, 1=
36);"><span style=3D"color: #008;" class=3D"styled-by-prettify">string</spa=
n></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{};</span></span><span style=3D"color: rgb=
(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></span><span style=3D"color: rgb(102, 102, 0);"><span style=3D"color:=
#660;" class=3D"styled-by-prettify">}</span></span></code></div></div></co=
de></div><br>or with Ranges:</div><div><br></div><div class=3D"prettyprint"=
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> generic</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">string=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> look</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> pattern</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> loc </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">find_end</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">look</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> pattern</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">loc </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> look</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">string</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">loo=
k</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> loc</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><div>=C2=A0</div><div>The generated assembl=
y here looks to be smaller than search, but not as small as rfind.</div><di=
v><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bd2bc535-5dd7-479b-8062-fa7a082d907a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bd2bc535-5dd7-479b-8062-fa7a082d907a=
%40isocpp.org</a>.<br />
------=_Part_1060_757874904.1483154320691--
------=_Part_1059_475598495.1483154320690--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 31 Dec 2016 08:15:05 -0800 (PST)
Raw View
------=_Part_1081_827194708.1483200905844
Content-Type: multipart/alternative;
boundary="----=_Part_1082_1136361351.1483200905845"
------=_Part_1082_1136361351.1483200905845
Content-Type: text/plain; charset=UTF-8
On Friday, December 30, 2016 at 10:18:40 PM UTC-5, Greg Marr wrote:
>
> On Friday, December 30, 2016 at 1:16:27 PM UTC-5, Nicol Bolas wrote:
>>
>> Interface conciseness is less important than overall readability.
>> Consider a relatively simple programming task. You're given two strings.
>> You want to find the last instance of string B within string A, then
>> generate a string that consists of all characters *before* the instance
>> you found.
>>
>> This is what the implementation based on generic algorithms and iterators
>> looks like:
>>
>> std::string generic(std::string look, std::string pattern)
>> {
>> auto loc = std::search(look.rbegin(), look.rend(),
>> pattern.rbegin(), pattern.rend());
>>
>> if(loc != look.rend())
>> {
>> loc += pattern.size();
>> return std::string(look.begin(), loc.base());
>> }
>> else
>> return std::string{};
>> }
>>
>> Understanding this code requires being well versed in how reverse
>> iterators work. Two particularly non-obvious things I had to do were: 1)
>> reversing the *pattern* as well as the string being searched and 2)
>> offsetting `loc` by the pattern's size, since that's not the actual
>> location.
>>
>> This is what the index&member function version looks like:
>>
>> std::string member(std::string look, std::string pattern)
>> {
>> auto loc = look.rfind(pattern);
>>
>> if(loc != std::string::npos)
>> {
>> return look.substr(0, loc);
>> }
>>
>> return std::string{};
>> }
>>
>> That's much shorter and more easily understood. There's no need to
>> reverse the pattern's range, nor the mysterious offset. The only thing that
>> might be at all confusing is the test against `npos`. But that's ultimately
>> no different from testing against `look.rend()`.
>>
>
> Seems to me that's only because you chose a sub-optimal algorithm. You
> want the one that matches string::rfind, but you used the one that matches
> string::find instead, so you had to add extra code to make it work right.
> Try this:
>
This actually emphasizes one of the problems with having a gigantic
algorithms library: the difficulty of finding appropriate operations.
I have been using C++ for decades now. And yet until you posted that, I had
never even *heard of* `std::find_end`. It's been there for nearly two
decades, and yet, I never knew it existed.
If people don't know an algorithm exists, it can't be used.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/85b9b92d-ae88-4b48-8f5c-e2e2cdb853ae%40isocpp.org.
------=_Part_1082_1136361351.1483200905845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 30, 2016 at 10:18:40 PM UTC-5, Greg Ma=
rr wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On F=
riday, December 30, 2016 at 1:16:27 PM UTC-5, Nicol Bolas wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Interface conciseness is=
less important than overall readability. Consider a relatively simple prog=
ramming task. You're given two strings. You want to find the last insta=
nce of string B within string A, then generate a string that consists of al=
l characters <i>before</i> the instance you found.<br><br>This is what the =
implementation based on generic algorithms and iterators looks like:<br><br=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px"><code><div><span style=3D"color:#0=
00">std</span><span style=3D"color:#660">::</span><span style=3D"color:#008=
">string</span><span style=3D"color:#000"> generic</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#000">std</span><span style=3D"color:=
#660">::</span><span style=3D"color:#008">string</span><span style=3D"color=
:#000"> look</span><span style=3D"color:#660">,</span><span style=3D"color:=
#000"> std</span><span style=3D"color:#660">::</span><span style=3D"color:#=
008">string</span><span style=3D"color:#000"> pattern</span><span style=3D"=
color:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span=
style=3D"color:#008">auto</span><span style=3D"color:#000"> loc </span><sp=
an style=3D"color:#660">=3D</span><span style=3D"color:#000"> std</span><sp=
an style=3D"color:#660">::</span><span style=3D"color:#000">search</span><s=
pan style=3D"color:#660">(</span><code><span style=3D"color:#000">look</spa=
n><span style=3D"color:#660"></span></code><span style=3D"color:#660">.</sp=
an><span style=3D"color:#000">rbegin</span><span style=3D"color:#660">(),</=
span><span style=3D"color:#000"> </span><code><span style=3D"color:#000">lo=
ok</span><span style=3D"color:#660"></span></code><span style=3D"color:#660=
">.</span><span style=3D"color:#000">rend</span><span style=3D"color:#660">=
(),</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 patter=
n</span><span style=3D"color:#660">.</span><span style=3D"color:#000">rbegi=
n</span><span style=3D"color:#660">(),</span><span style=3D"color:#000"> pa=
ttern</span><span style=3D"color:#660">.</span><span style=3D"color:#000">r=
end</span><span style=3D"color:#660">());</span><span style=3D"color:#000">=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#008">if</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">loc </span><span style=3D"color:#660">!=3D</span><span style=3D"color:=
#000"> </span><code><span style=3D"color:#000">look</span><span style=3D"co=
lor:#660"></span></code><span style=3D"color:#660">.</span><span style=3D"c=
olor:#000">rend</span><span style=3D"color:#660">())</span><span style=3D"c=
olor:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 loc </span><span sty=
le=3D"color:#660">+=3D</span><span style=3D"color:#000"> pattern</span><spa=
n style=3D"color:#660">.</span><span style=3D"color:#000">size</span><span =
style=3D"color:#660">();</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span style=
=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#008">string</span><span style=3D"color:#660">(</span><code><span=
style=3D"color:#000">look</span><span style=3D"color:#660"></span></code><=
span style=3D"color:#660">.</span><span style=3D"color:#008">begin</span><s=
pan style=3D"color:#660">(),</span><span style=3D"color:#000"> loc</span><s=
pan style=3D"color:#660">.</span><span style=3D"color:#008">base</span><spa=
n style=3D"color:#660">());</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#660">}</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#008">else</span><span style=3D=
"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#0=
08">return</span><span style=3D"color:#000"> std</span><span style=3D"color=
:#660">::</span><span style=3D"color:#008">string</span><span style=3D"colo=
r:#660">{};</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">}</span></div></code></div><br>Understanding this code requires bei=
ng well versed in how reverse iterators work. Two particularly non-obvious =
things I had to do were: 1) reversing the <i>pattern</i> as well as the str=
ing being searched and 2) offsetting `loc` by the pattern's size, since=
that's not the actual location.<br><br>This is what the index&memb=
er function version looks like:<br><br><div style=3D"background-color:rgb(2=
50,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1=
px"><code><div><span style=3D"color:#000">std</span><span style=3D"color:#6=
60">::</span><span style=3D"color:#008">string</span><span style=3D"color:#=
000"> member</span><span style=3D"color:#660">(</span><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
08">string</span><span style=3D"color:#000"> look</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> std</span><span style=3D"color:=
#660">::</span><span style=3D"color:#008">string</span><span style=3D"color=
:#000"> pattern</span><span style=3D"color:#660">)</span><span style=3D"col=
or:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">auto</span><span=
style=3D"color:#000"> loc </span><span style=3D"color:#660">=3D</span><spa=
n style=3D"color:#000"> look</span><span style=3D"color:#660">.</span><span=
style=3D"color:#000">rfind</span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">pattern</span><span style=3D"color:#660">);</span><spa=
n style=3D"color:#000"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:#008">if</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">loc </span><span style=3D"color:#660">!=3D</span><span styl=
e=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#008">string</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">npos</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span st=
yle=3D"color:#008">return</span><span style=3D"color:#000"> look</span><spa=
n style=3D"color:#660">.</span><span style=3D"color:#000">substr</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#066">0</span><span sty=
le=3D"color:#660">,</span><span style=3D"color:#000"> loc</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color:#660">}</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><sp=
an style=3D"color:#000"> std</span><span style=3D"color:#660">::</span><spa=
n style=3D"color:#008">string</span><span style=3D"color:#660">{};</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#660">}</span></di=
v></code></div><br>That's much shorter and more easily understood. Ther=
e's no need to reverse the pattern's range, nor the mysterious offs=
et. The only thing that might be at all confusing is the test against `npos=
`. But that's ultimately no different from testing against `look.rend()=
`.<br></div></div></blockquote><div><br></div><div>Seems to me that's o=
nly because you chose a sub-optimal algorithm. =C2=A0You want the one that =
matches string::rfind, but you used the one that matches string::find inste=
ad, so you had to add extra code to make it work right. =C2=A0Try this:</di=
v></div></blockquote><div><br>This actually emphasizes one of the problems =
with having a gigantic algorithms library: the difficulty of finding approp=
riate operations.<br><br>I have been using C++ for decades now. And yet unt=
il you posted that, I had never even <i>heard of</i> `std::find_end`. It=
9;s been there for nearly two decades, and yet, I never knew it existed.<br=
><br>If people don't know an algorithm exists, it can't be used.</d=
iv></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/85b9b92d-ae88-4b48-8f5c-e2e2cdb853ae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/85b9b92d-ae88-4b48-8f5c-e2e2cdb853ae=
%40isocpp.org</a>.<br />
------=_Part_1082_1136361351.1483200905845--
------=_Part_1081_827194708.1483200905844--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 31 Dec 2016 18:48:24 +0200
Raw View
On 31 December 2016 at 18:15, Nicol Bolas <jmckesson@gmail.com> wrote:
>> Seems to me that's only because you chose a sub-optimal algorithm. You
>> want the one that matches string::rfind, but you used the one that matches
>> string::find instead, so you had to add extra code to make it work right.
>> Try this:
>
>
> This actually emphasizes one of the problems with having a gigantic
> algorithms library: the difficulty of finding appropriate operations.
>
> I have been using C++ for decades now. And yet until you posted that, I had
> never even heard of `std::find_end`. It's been there for nearly two decades,
> and yet, I never knew it existed.
>
> If people don't know an algorithm exists, it can't be used.
Right, but I'm not convinced people are any wiser when they don't know
a member function exists.
In a completely anecdotal fashion, I tend to separate "what tools do I
have to solve this problem?" from "let's bang on the
keyboard and see what we'll find". Sometimes it's said that member
functions are easier to find
for IDEs and tools like intellisense, but when I have done the "what
tools?" phase, I tend to
turn the completion tools off if they give me a single false positive,
because they end up slowing
me down when I know what I intend to write. To each their own, I guess.
But hey, what proposal are we discussing, again? :) After all this
rather philosophical discussion,
I'm not quite sure what we're looking at. ;)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbN3Fg6NLYpzk29%3DU5Cn6kP%2B14Q3VL9H_bz5%3DXteriwkg%40mail.gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sun, 1 Jan 2017 03:08:20 +0300
Raw View
On 12/30/16 21:16, Nicol Bolas wrote:
>
> Interface conciseness is less important than overall readability.
> Consider a relatively simple programming task. You're given two strings.
> You want to find the last instance of string B within string A, then
> generate a string that consists of all characters /before/ the instance
> you found.
>
> This is what the implementation based on generic algorithms and
> iterators looks like:
>
> |
> std::stringgeneric(std::stringlook,std::stringpattern)
> {
> autoloc =std::search(|look|.rbegin(),|look|.rend(),
> pattern.rbegin(),pattern.rend());
>
> if(loc !=|look|.rend())
> {
> loc +=pattern.size();
> returnstd::string(|look|.begin(),loc.base());
> }
> else
> returnstd::string{};
> }
> |
>
> This is what the index&member function version looks like:
>
> |
> std::stringmember(std::stringlook,std::stringpattern)
> {
> autoloc =look.rfind(pattern);
>
> if(loc !=std::string::npos)
> {
> returnlook.substr(0,loc);
> }
>
> returnstd::string{};
> }
> |
Well, if the `std::string::rfind` algorithm was standalone, I believe
the code would've been just as readable:
template< typename Iterator1, typename Iterator2 >
Iterator1 search_last(Iterator1 begin, Iterator1 end,
Iterator2 needle_begin, Iterator2 needle_end);
std::string generic2(std::string look, std::string pattern)
{
auto it = search_last(look.begin(), look.end(),
pattern.begin(), pattern.end());
if (it != look.end())
return std::string(look.begin(), it);
return std::string{};
}
That `search_last` algorithm could've been a generic algorithm with
specialized versions for optimal performance (if the compiler doesn't
already do the good job). So once again, index-based interface (I mean,
the choice of indices over iterators by itself), or algorithms being
`std::string` members doesn't make the code any clearer.
I can understand someone might be used to indices as a concept, but
really, most of the standard library is built around iterators; you'd
expect anyone more or less familiar with C++ should be used to iterators
in no less degree.
> As for compiler optimizations, here are the compiled results for GCC 7,
> under -O3 <https://godbolt.org/g/xDFhgs>. It seems to me that `member`
> is much shorter in assembly than `generic`, requiring a lot fewer jumps
> and the like. So your "the compiler can sort it out" argument seems to
> not be true in this case.
Ok, fair enough, the compiler is not good at optimizing reverse
iteration. Let the library provide an optimized implementation of that
algorithm then. Let it be reusable in classes other than `std::string`.
In that case there is no need to pile it in `std::string` interface.
More concise `std::string` interface, more reusable algorithms, everyone
wins.
I know it's too late for the existing algorithms in `std::string`. I
just don't want it to get worse.
> There is also a cost if you want to implement a class that mimics
> std::string. I've done that a few times, and those member functions do
> add complexity to the task.
>
> There is obviously a cost for standard library implementers and
> standard
> writers and committee.
>
> So you're saying that we should avoid good APIs because they're hard to
> get through committee? That sounds like a problem with the committee
> process, not with the API.
I'm saying poorly designed API that imposes coupling and additional
dependencies adds a cost both on users who want to use or implement that
API and the committee which has to maintain evolution of the library.
I'm not saying no new APIs should be added to the standard library.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b975ab42-e233-7315-f331-43eeb36bbb1b%40gmail.com.
.
Author: olaf@join.cc
Date: Fri, 13 Jan 2017 08:10:33 -0800 (PST)
Raw View
------=_Part_566_2024452373.1484323833689
Content-Type: multipart/alternative;
boundary="----=_Part_567_989675238.1484323833689"
------=_Part_567_989675238.1484323833689
Content-Type: text/plain; charset=UTF-8
Op zaterdag 31 december 2016 17:48:27 UTC+1 schreef Ville Voutilainen:
>
> But hey, what proposal are we discussing, again? :) After all this
> rather philosophical discussion,
> I'm not quite sure what we're looking at. ;)
>
I'm glad you asked. :D
append(s, "A", "B", 42); with at least support for string but perhaps more
general support.
It could call append(s, v) for each argument, providing a simple
customization support.
I'm not sure how to combine customization and optimal performance though.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/550410ae-e702-4218-b366-eacb9773ff72%40isocpp.org.
------=_Part_567_989675238.1484323833689
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Op zaterdag 31 december 2016 17:48:27 UTC+1 schreef Ville =
Voutilainen:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But hey, what prop=
osal are we discussing, again? :) After all this
<br>rather philosophical discussion,
<br>I'm not quite sure what we're looking at. ;)
<br></blockquote><div><br></div><div>I'm glad you asked. :D</div><div><=
br></div><div><span style=3D"font-family: arial, sans-serif; font-size: 12.=
8px;">append(s, "A", "B", 42); with at least support fo=
r string but perhaps more general support.</span></div><div><span style=3D"=
font-family: arial, sans-serif; font-size: 12.8px;"><br></span></div><div><=
span style=3D"font-family: arial, sans-serif; font-size: 12.8px;">It could =
call append(s, v) for each argument, providing a simple customization suppo=
rt.=C2=A0</span></div><div><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.8px;">I'm not sure how to combine customization and optima=
l performance though.</span></div><div><span style=3D"font-family: arial, s=
ans-serif; font-size: 12.8px;"><br></span></div><div><span style=3D"font-fa=
mily: arial, sans-serif; font-size: 12.8px;"><br></span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/550410ae-e702-4218-b366-eacb9773ff72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/550410ae-e702-4218-b366-eacb9773ff72=
%40isocpp.org</a>.<br />
------=_Part_567_989675238.1484323833689--
------=_Part_566_2024452373.1484323833689--
.
Author: Victor Zverovich <victor.zverovich@gmail.com>
Date: Sat, 14 Jan 2017 13:02:02 -0800 (PST)
Raw View
------=_Part_826_720812032.1484427722902
Content-Type: multipart/alternative;
boundary="----=_Part_827_897485780.1484427722903"
------=_Part_827_897485780.1484427722903
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello,
The author of the fmt library here. FWIW I've been working on a proposal to=
=20
introduce similar formatting functionality based on variadic templates to=
=20
the standard: http://fmtlib.net/Text%20Formatting.html . It is still a very=
=20
early and incomplete draft but I'd be glad to hear feedback.
With this functionality, one could do something like
std::string s =3D std::format("{}{}{}", "A", "B", 42);
This is somewhat more general than what the OP proposes because it allows=
=20
format specifiers and output targets other than strings. At the same time,=
=20
if properly implemented, it solves the problem of extra allocations and can=
=20
have performance similar to that of sprintf.
Any comments are very welcome.
Cheers,
Victor
On Wednesday, December 28, 2016 at 2:03:18 AM UTC-8, lnal...@gmail.com=20
wrote:
>
> Hello,
>
> It would be useful, but will however probably cause temporary string in=
=20
> variadic iteration (I'm not a variadic template expert).
>
> but my dream is more to have a library like this one standardized=20
> https://github.com/fmtlib/fmt
>
> Laurent
>
> Le mercredi 28 d=C3=A9cembre 2016 09:50:40 UTC+1, Olaf van der Spek a =C3=
=A9crit :
>>
>> Hi,
>>
>> One frequently needs to append stuff to strings, but the standard way
>> (s +=3D "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>> A variadic append() for std::string seems like the obvious solution.
>> It could support string_view, integers, maybe floats
>> but without formatting options..
>> It could even be extensible by calling append(s, t);
>>
>> append(s, "A", "B", 42);
>>
>> Would this be useful for the C++ std lib?
>>
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6b156c7a-ff97-448e-81ca-ae8322fe1417%40isocpp.or=
g.
------=_Part_827_897485780.1484427722903
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<div><br></div><div>The author of the fmt library he=
re. FWIW I've been working on a proposal to introduce similar formattin=
g functionality based on variadic templates to the standard:=C2=A0http://fm=
tlib.net/Text%20Formatting.html . It is still a very early and incomplete d=
raft but I'd be glad to hear feedback.</div><div><br></div><div>With th=
is functionality, one could do something like</div><div><br></div><div><spa=
n style=3D"font-family: arial, sans-serif; font-size: 12.8px;">=C2=A0 std::=
string s =3D std::format("{}{}{}", "A", "B", =
42);</span><br></div><div><span style=3D"font-family: arial, sans-serif; fo=
nt-size: 12.8px;"><br></span></div><div><font face=3D"arial, sans-serif"><s=
pan style=3D"font-size: 12.8px;">This is somewhat more general than what th=
e OP proposes because it allows format specifiers and output targets other =
than strings. At the same time, if properly implemented, it solves the prob=
lem of extra allocations and can have performance similar to that of sprint=
f.</span></font></div><div><font face=3D"arial, sans-serif"><span style=3D"=
font-size: 12.8px;"><br></span></font></div><div><font face=3D"arial, sans-=
serif"><span style=3D"font-size: 12.8px;">Any comments are very welcome.</s=
pan></font></div><div><font face=3D"arial, sans-serif"><span style=3D"font-=
size: 12.8px;"><br></span></font></div><div><font face=3D"arial, sans-serif=
"><span style=3D"font-size: 12.8px;">Cheers,</span></font></div><div><font =
face=3D"arial, sans-serif"><span style=3D"font-size: 12.8px;">Victor</span>=
</font></div><div><br>On Wednesday, December 28, 2016 at 2:03:18 AM UTC-8, =
lnal...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>Hello,</div><div><br></div>It would be useful, but will how=
ever probably cause temporary string in variadic iteration (I'm not a v=
ariadic template expert).<div><br></div><div>but my dream is more to have a=
library like this one standardized=C2=A0<a href=3D"https://github.com/fmtl=
ib/fmt" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ffmtlib%2Ffmt\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHczylSI1dpD7vrOq7kB4ix9U5bbQ';retu=
rn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps=
%3A%2F%2Fgithub.com%2Ffmtlib%2Ffmt\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
HczylSI1dpD7vrOq7kB4ix9U5bbQ';return true;">https://github.<wbr>com/fmt=
lib/fmt</a><div><br></div><div>Laurent<br><br>Le mercredi 28 d=C3=A9cembre =
2016 09:50:40 UTC+1, Olaf van der Spek a =C3=A9crit=C2=A0:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"font-family:arial,sa=
ns-serif;font-size:12.8px">Hi,</span><br style=3D"font-family:arial,sans-se=
rif;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;font-size:1=
2.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">One fr=
equently needs to append stuff to strings, but the standard way</span><br s=
tyle=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-=
family:arial,sans-serif;font-size:12.8px">(s +=3D "A" + "B&q=
uot; + to_string(42)) isn't optimal due to temporaries.</span><br style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.8px">A variadic append() for std::string s=
eems like the obvious solution.</span><br style=3D"font-family:arial,sans-s=
erif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-siz=
e:12.8px">It could support string_view, integers, maybe floats</span><br st=
yle=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-f=
amily:arial,sans-serif;font-size:12.8px">but without formatting options..</=
span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span styl=
e=3D"font-family:arial,sans-serif;font-size:12.8px">It could even be extens=
ible by calling append(s, t);</span><br style=3D"font-family:arial,sans-ser=
if;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;font-size:12=
..8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">append(=
s, "A", "B", 42);</span><br style=3D"font-family:arial,=
sans-serif;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;font=
-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px"=
>Would this be useful for the C++ std lib?</span><br></div></blockquote></d=
iv></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6b156c7a-ff97-448e-81ca-ae8322fe1417%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6b156c7a-ff97-448e-81ca-ae8322fe1417=
%40isocpp.org</a>.<br />
------=_Part_827_897485780.1484427722903--
------=_Part_826_720812032.1484427722902--
.
Author: gmisocpp@gmail.com
Date: Sat, 14 Jan 2017 13:35:44 -0800 (PST)
Raw View
------=_Part_615_1237396391.1484429744762
Content-Type: multipart/alternative;
boundary="----=_Part_616_1567709728.1484429744762"
------=_Part_616_1567709728.1484429744762
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm looking forward to formatting being proposed for the standard.
You touched on reducing allocations, I think their should be a variant of=
=20
the interface that reuses an existing string to format into.
std::string reuse_ms;
e.g. std::fmt_existing(reuse_me, ...);
This would raise the possibility of no additional allocations in some=20
situations.
But particularly in a loop.
The user may also resize/reserve the string before the loop then to reduce=
=20
the chance of any unexpected allocations or exceptions.
They could aim to set a worst case size.
I haven't looked closely at fmt so apologies if this facility already=20
exists.
On Sunday, January 15, 2017 at 10:02:03 AM UTC+13, Victor Zverovich wrote:
> Hello,
>
> The author of the fmt library here. FWIW I've been working on a proposal=
=20
> to introduce similar formatting functionality based on variadic templates=
=20
> to the standard: http://fmtlib.net/Text%20Formatting.html . It is still a=
=20
> very early and incomplete draft but I'd be glad to hear feedback.
>
> With this functionality, one could do something like
>
> std::string s =3D std::format("{}{}{}", "A", "B", 42);
>
> This is somewhat more general than what the OP proposes because it allows=
=20
> format specifiers and output targets other than strings. At the same time=
,=20
> if properly implemented, it solves the problem of extra allocations and c=
an=20
> have performance similar to that of sprintf.
>
> Any comments are very welcome.
>
> Cheers,
> Victor
>
> On Wednesday, December 28, 2016 at 2:03:18 AM UTC-8, lnal...@gmail.com=20
> wrote:
>>
>> Hello,
>>
>> It would be useful, but will however probably cause temporary string in=
=20
>> variadic iteration (I'm not a variadic template expert).
>>
>> but my dream is more to have a library like this one standardized=20
>> https://github.com/fmtlib/fmt
>>
>> Laurent
>>
>> Le mercredi 28 d=C3=A9cembre 2016 09:50:40 UTC+1, Olaf van der Spek a =
=C3=A9crit :
>>>
>>> Hi,
>>>
>>> One frequently needs to append stuff to strings, but the standard way
>>> (s +=3D "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>>> A variadic append() for std::string seems like the obvious solution.
>>> It could support string_view, integers, maybe floats
>>> but without formatting options..
>>> It could even be extensible by calling append(s, t);
>>>
>>> append(s, "A", "B", 42);
>>>
>>> Would this be useful for the C++ std lib?
>>>
>>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e7197b97-9a3f-48b9-9e72-7c962461d969%40isocpp.or=
g.
------=_Part_616_1567709728.1484429744762
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>I'm looking forward to=C2=A0format=
ting being proposed for the standard.</div><div><br></div><div>You touched =
on reducing allocations,=C2=A0I think their should be a variant of the inte=
rface that reuses=C2=A0an existing string to format into.</div><div>std::st=
ring reuse_ms;</div><div>e.g. std::fmt_existing(reuse_me, ...);</div><div><=
br></div><div>This=C2=A0would raise the=C2=A0possibility of=C2=A0no additio=
nal allocations in some situations.</div><div>But particularly in a loop.</=
div><div>The user may also resize/reserve the string before the loop then t=
o=C2=A0reduce the chance of any unexpected allocations or exceptions.</div>=
<div>They could aim to set a worst case size.</div><div><br><div>I haven=
9;t looked closely at fmt so apologies if this facility already exists.</di=
v><br>On Sunday, January 15, 2017 at 10:02:03 AM UTC+13, Victor Zverovich w=
rote:</div><blockquote class=3D"gmail_quote" 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;"><div dir=3D"ltr">Hello,<div><br></d=
iv><div>The author of the fmt library here. FWIW I've been working on a=
proposal to introduce similar formatting functionality based on variadic t=
emplates to the standard:=C2=A0<a onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2Ffmtlib.net%2FText%2520Formatting.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHZTnDLRkoRH6OSti61EVjg03ldwg';ret=
urn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%=
3A%2F%2Ffmtlib.net%2FText%2520Formatting.html\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNHZTnDLRkoRH6OSti61EVjg03ldwg';return true;" href=3D"http://f=
mtlib.net/Text%20Formatting.html" target=3D"_blank" rel=3D"nofollow">http:/=
/fmtlib.net/<wbr>Text%20Formatting.html</a> . It is still a very early and =
incomplete draft but I'd be glad to hear feedback.</div><div><br></div>=
<div>With this functionality, one could do something like</div><div><br></d=
iv><div><span style=3D"font-family: arial,sans-serif; font-size: 12.8px;">=
=C2=A0 std::string s =3D std::format("{}{}{}", "A", &qu=
ot;B", 42);</span><br></div><div><span style=3D"font-family: arial,san=
s-serif; font-size: 12.8px;"><br></span></div><div><font face=3D"arial, san=
s-serif"><span style=3D"font-size: 12.8px;">This is somewhat more general t=
han what the OP proposes because it allows format specifiers and output tar=
gets other than strings. At the same time, if properly implemented, it solv=
es the problem of extra allocations and can have performance similar to tha=
t of sprintf.</span></font></div><div><font face=3D"arial, sans-serif"><spa=
n style=3D"font-size: 12.8px;"><br></span></font></div><div><font face=3D"a=
rial, sans-serif"><span style=3D"font-size: 12.8px;">Any comments are very =
welcome.</span></font></div><div><font face=3D"arial, sans-serif"><span sty=
le=3D"font-size: 12.8px;"><br></span></font></div><div><font face=3D"arial,=
sans-serif"><span style=3D"font-size: 12.8px;">Cheers,</span></font></div>=
<div><font face=3D"arial, sans-serif"><span style=3D"font-size: 12.8px;">Vi=
ctor</span></font></div><div><br>On Wednesday, December 28, 2016 at 2:03:18=
AM UTC-8, <a>lnal...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote"=
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;"><div=
dir=3D"ltr"><div>Hello,</div><div><br></div>It would be useful, but will h=
owever probably cause temporary string in variadic iteration (I'm not a=
variadic template expert).<div><br></div><div>but my dream is more to have=
a library like this one standardized=C2=A0<a onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ffmtlib%2Ffmt\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHczylSI1dpD7vrOq7kB4ix9U5bbQ';r=
eturn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dht=
tps%3A%2F%2Fgithub.com%2Ffmtlib%2Ffmt\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNHczylSI1dpD7vrOq7kB4ix9U5bbQ';return true;" href=3D"https://github.c=
om/fmtlib/fmt" target=3D"_blank" rel=3D"nofollow">https://github.<wbr>com/f=
mtlib/fmt</a><div><br></div><div>Laurent<br><br>Le mercredi 28 d=C3=A9cembr=
e 2016 09:50:40 UTC+1, Olaf van der Spek a =C3=A9crit=C2=A0:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;"><div dir=3D"ltr"><span style=3D"font-family: arial,sans-serif=
; font-size: 12.8px;">Hi,</span><br style=3D"font-family: arial,sans-serif;=
font-size: 12.8px;"><br style=3D"font-family: arial,sans-serif; font-size:=
12.8px;"><span style=3D"font-family: arial,sans-serif; font-size: 12.8px;"=
>One frequently needs to append stuff to strings, but the standard way</spa=
n><br style=3D"font-family: arial,sans-serif; font-size: 12.8px;"><span sty=
le=3D"font-family: arial,sans-serif; font-size: 12.8px;">(s +=3D "A&qu=
ot; + "B" + to_string(42)) isn't optimal due to temporaries.<=
/span><br style=3D"font-family: arial,sans-serif; font-size: 12.8px;"><span=
style=3D"font-family: arial,sans-serif; font-size: 12.8px;">A variadic app=
end() for std::string seems like the obvious solution.</span><br style=3D"f=
ont-family: arial,sans-serif; font-size: 12.8px;"><span style=3D"font-famil=
y: arial,sans-serif; font-size: 12.8px;">It could support string_view, inte=
gers, maybe floats</span><br style=3D"font-family: arial,sans-serif; font-s=
ize: 12.8px;"><span style=3D"font-family: arial,sans-serif; font-size: 12.8=
px;">but without formatting options..</span><br style=3D"font-family: arial=
,sans-serif; font-size: 12.8px;"><span style=3D"font-family: arial,sans-ser=
if; font-size: 12.8px;">It could even be extensible by calling append(s, t)=
;</span><br style=3D"font-family: arial,sans-serif; font-size: 12.8px;"><br=
style=3D"font-family: arial,sans-serif; font-size: 12.8px;"><span style=3D=
"font-family: arial,sans-serif; font-size: 12.8px;">append(s, "A"=
, "B", 42);</span><br style=3D"font-family: arial,sans-serif; fon=
t-size: 12.8px;"><br style=3D"font-family: arial,sans-serif; font-size: 12.=
8px;"><span style=3D"font-family: arial,sans-serif; font-size: 12.8px;">Wou=
ld this be useful for the C++ std lib?</span><br></div></blockquote></div><=
/div></div></blockquote></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7197b97-9a3f-48b9-9e72-7c962461d969%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7197b97-9a3f-48b9-9e72-7c962461d969=
%40isocpp.org</a>.<br />
------=_Part_616_1567709728.1484429744762--
------=_Part_615_1237396391.1484429744762--
.
Author: Victor Zverovich <victor.zverovich@gmail.com>
Date: Sat, 14 Jan 2017 14:03:56 -0800 (PST)
Raw View
------=_Part_1115_1413363263.1484431436545
Content-Type: multipart/alternative;
boundary="----=_Part_1116_733183465.1484431436546"
------=_Part_1116_733183465.1484431436546
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I agree that it would be useful to have a formatting function that appends=
=20
to existing string. Incidentally, the facility to append to strings and=20
containers with contiguous storage was recently contributed to=20
fmt: https://github.com/fmtlib/fmt/pull/450
On Saturday, January 14, 2017 at 1:35:45 PM UTC-8, gmis...@gmail.com wrote:
>
>
> I'm looking forward to formatting being proposed for the standard.
>
> You touched on reducing allocations, I think their should be a variant of=
=20
> the interface that reuses an existing string to format into.
> std::string reuse_ms;
> e.g. std::fmt_existing(reuse_me, ...);
>
> This would raise the possibility of no additional allocations in some=20
> situations.
> But particularly in a loop.
> The user may also resize/reserve the string before the loop then to reduc=
e=20
> the chance of any unexpected allocations or exceptions.
> They could aim to set a worst case size.
>
> I haven't looked closely at fmt so apologies if this facility already=20
> exists.
>
> On Sunday, January 15, 2017 at 10:02:03 AM UTC+13, Victor Zverovich wrote=
:
>
>> Hello,
>>
>> The author of the fmt library here. FWIW I've been working on a proposal=
=20
>> to introduce similar formatting functionality based on variadic template=
s=20
>> to the standard: http://fmtlib.net/Text%20Formatting.html . It is still=
=20
>> a very early and incomplete draft but I'd be glad to hear feedback.
>>
>> With this functionality, one could do something like
>>
>> std::string s =3D std::format("{}{}{}", "A", "B", 42);
>>
>> This is somewhat more general than what the OP proposes because it allow=
s=20
>> format specifiers and output targets other than strings. At the same tim=
e,=20
>> if properly implemented, it solves the problem of extra allocations and =
can=20
>> have performance similar to that of sprintf.
>>
>> Any comments are very welcome.
>>
>> Cheers,
>> Victor
>>
>> On Wednesday, December 28, 2016 at 2:03:18 AM UTC-8, lnal...@gmail.com=
=20
>> wrote:
>>>
>>> Hello,
>>>
>>> It would be useful, but will however probably cause temporary string in=
=20
>>> variadic iteration (I'm not a variadic template expert).
>>>
>>> but my dream is more to have a library like this one standardized=20
>>> https://github.com/fmtlib/fmt
>>>
>>> Laurent
>>>
>>> Le mercredi 28 d=C3=A9cembre 2016 09:50:40 UTC+1, Olaf van der Spek a =
=C3=A9crit :
>>>>
>>>> Hi,
>>>>
>>>> One frequently needs to append stuff to strings, but the standard way
>>>> (s +=3D "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>>>> A variadic append() for std::string seems like the obvious solution.
>>>> It could support string_view, integers, maybe floats
>>>> but without formatting options..
>>>> It could even be extensible by calling append(s, t);
>>>>
>>>> append(s, "A", "B", 42);
>>>>
>>>> Would this be useful for the C++ std lib?
>>>>
>>>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/835808b1-39cb-4769-b808-42b81d0c7c00%40isocpp.or=
g.
------=_Part_1116_733183465.1484431436546
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree that it would be useful to have a formatting funct=
ion that appends to existing string. Incidentally, the facility to append t=
o strings and containers with contiguous storage was recently contributed t=
o fmt:=C2=A0https://github.com/fmtlib/fmt/pull/450<br><br>On Saturday, Janu=
ary 14, 2017 at 1:35:45 PM UTC-8, gmis...@gmail.com wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>I'm lo=
oking forward to=C2=A0formatting being proposed for the standard.</div><div=
><br></div><div>You touched on reducing allocations,=C2=A0I think their sho=
uld be a variant of the interface that reuses=C2=A0an existing string to fo=
rmat into.</div><div>std::string reuse_ms;</div><div>e.g. std::fmt_existing=
(reuse_me, ...);</div><div><br></div><div>This=C2=A0would raise the=C2=A0po=
ssibility of=C2=A0no additional allocations in some situations.</div><div>B=
ut particularly in a loop.</div><div>The user may also resize/reserve the s=
tring before the loop then to=C2=A0reduce the chance of any unexpected allo=
cations or exceptions.</div><div>They could aim to set a worst case size.</=
div><div><br><div>I haven't looked closely at fmt so apologies if this =
facility already exists.</div><br>On Sunday, January 15, 2017 at 10:02:03 A=
M UTC+13, Victor Zverovich wrote:</div><blockquote class=3D"gmail_quote" st=
yle=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"><div dir=3D"ltr">He=
llo,<div><br></div><div>The author of the fmt library here. FWIW I've b=
een working on a proposal to introduce similar formatting functionality bas=
ed on variadic templates to the standard:=C2=A0<a href=3D"http://fmtlib.net=
/Text%20Formatting.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Ffmtlib.net%2FT=
ext%2520Formatting.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHZTnDLRkoRH=
6OSti61EVjg03ldwg';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Ffmtlib.net%2FText%2520Formatting.html\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHZTnDLRkoRH6OSti61EVjg03ldwg';retu=
rn true;">http://fmtlib.net/<wbr>Text%20Formatting.html</a> . It is still a=
very early and incomplete draft but I'd be glad to hear feedback.</div=
><div><br></div><div>With this functionality, one could do something like</=
div><div><br></div><div><span style=3D"font-family:arial,sans-serif;font-si=
ze:12.8px">=C2=A0 std::string s =3D std::format("{}{}{}", "A=
", "B", 42);</span><br></div><div><span style=3D"font-family=
:arial,sans-serif;font-size:12.8px"><br></span></div><div><font face=3D"ari=
al, sans-serif"><span style=3D"font-size:12.8px">This is somewhat more gene=
ral than what the OP proposes because it allows format specifiers and outpu=
t targets other than strings. At the same time, if properly implemented, it=
solves the problem of extra allocations and can have performance similar t=
o that of sprintf.</span></font></div><div><font face=3D"arial, sans-serif"=
><span style=3D"font-size:12.8px"><br></span></font></div><div><font face=
=3D"arial, sans-serif"><span style=3D"font-size:12.8px">Any comments are ve=
ry welcome.</span></font></div><div><font face=3D"arial, sans-serif"><span =
style=3D"font-size:12.8px"><br></span></font></div><div><font face=3D"arial=
, sans-serif"><span style=3D"font-size:12.8px">Cheers,</span></font></div><=
div><font face=3D"arial, sans-serif"><span style=3D"font-size:12.8px">Victo=
r</span></font></div><div><br>On Wednesday, December 28, 2016 at 2:03:18 AM=
UTC-8, <a>lnal...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" st=
yle=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"><div dir=3D"ltr"><d=
iv>Hello,</div><div><br></div>It would be useful, but will however probably=
cause temporary string in variadic iteration (I'm not a variadic templ=
ate expert).<div><br></div><div>but my dream is more to have a library like=
this one standardized=C2=A0<a href=3D"https://github.com/fmtlib/fmt" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ffmtlib%2Ffmt\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNHczylSI1dpD7vrOq7kB4ix9U5bbQ';return true;" o=
nclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgi=
thub.com%2Ffmtlib%2Ffmt\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHczylSI1dpD=
7vrOq7kB4ix9U5bbQ';return true;">https://github.<wbr>com/fmtlib/fmt</a>=
<div><br></div><div>Laurent<br><br>Le mercredi 28 d=C3=A9cembre 2016 09:50:=
40 UTC+1, Olaf van der Spek a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_q=
uote" 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"><div dir=3D=
"ltr"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">Hi,</sp=
an><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><br style=3D=
"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-family:=
arial,sans-serif;font-size:12.8px">One frequently needs to append stuff to =
strings, but the standard way</span><br style=3D"font-family:arial,sans-ser=
if;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:=
12.8px">(s +=3D "A" + "B" + to_string(42)) isn't op=
timal due to temporaries.</span><br style=3D"font-family:arial,sans-serif;f=
ont-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8=
px">A variadic append() for std::string seems like the obvious solution.</s=
pan><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=
=3D"font-family:arial,sans-serif;font-size:12.8px">It could support string_=
view, integers, maybe floats</span><br style=3D"font-family:arial,sans-seri=
f;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:1=
2.8px">but without formatting options..</span><br style=3D"font-family:aria=
l,sans-serif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;=
font-size:12.8px">It could even be extensible by calling append(s, t);</spa=
n><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><br style=3D"=
font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-family:a=
rial,sans-serif;font-size:12.8px">append(s, "A", "B", 4=
2);</span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><br s=
tyle=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-=
family:arial,sans-serif;font-size:12.8px">Would this be useful for the C++ =
std lib?</span><br></div></blockquote></div></div></div></blockquote></div>=
</div></blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/835808b1-39cb-4769-b808-42b81d0c7c00%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/835808b1-39cb-4769-b808-42b81d0c7c00=
%40isocpp.org</a>.<br />
------=_Part_1116_733183465.1484431436546--
------=_Part_1115_1413363263.1484431436545--
.
Author: gmisocpp@gmail.com
Date: Sat, 14 Jan 2017 14:33:01 -0800 (PST)
Raw View
------=_Part_2346_53810440.1484433181442
Content-Type: multipart/alternative;
boundary="----=_Part_2347_682790395.1484433181443"
------=_Part_2347_682790395.1484433181443
Content-Type: text/plain; charset=UTF-8
On Sunday, January 15, 2017 at 11:03:56 AM UTC+13, Victor Zverovich wrote:
>
> I agree that it would be useful to have a formatting function that appends
> to existing string. Incidentally, the facility to append to strings and
> containers with contiguous storage was recently contributed to fmt:
> https://github.com/fmtlib/fmt/pull/450
>
I was just in the process of replying to say that decoupling formatting
from string would be great. And that seems to do that.
I didn't see exactly how it's used but it seems (but I'm sure someone will
correct me here) it would be nice if this worked:
std::vector v;
So fmt(v. "whatever");
I wonder if the standard containers could expose themselves as buffers that
would enable that or this if it's better:
fmt(as_buffer(v), "whatever"); or fmt(v.as_buffer(), "whatever") if that's
better.
I don't see why std::array couldn't be made to work too etc. Does
your wrapper support array?
It seems it would be possible, or at least if the standard could help here.
Nicol's/boosts interface to default constructed allocation would seem
useful to employ in this interface for fmt.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0a11a519-7383-43d5-a342-5fda9e1abb7a%40isocpp.org.
------=_Part_2347_682790395.1484433181443
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, January 15, 2017 at 11:03:56 AM UTC+13,=
Victor Zverovich wrote:<blockquote class=3D"gmail_quote" 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;"><div dir=3D"ltr">I agr=
ee that it would be useful to have a formatting function that appends to ex=
isting string. Incidentally, the facility to append to strings and containe=
rs with contiguous storage was recently contributed to fmt:=C2=A0<a onmouse=
down=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Ffmtlib%2Ffmt%2Fpull%2F450\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
Hk3b6HmdabTKYM7ZjOAWH-VmcF4Q';return true;" onclick=3D"this.href=3D'=
;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ffmtlib%2Ffmt%2F=
pull%2F450\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHk3b6HmdabTKYM7ZjOAWH-Vm=
cF4Q';return true;" href=3D"https://github.com/fmtlib/fmt/pull/450" tar=
get=3D"_blank" rel=3D"nofollow">https://github.com/<wbr>fmtlib/fmt/pull/450=
</a></div></blockquote><div>=C2=A0</div><div>I was just in the process of r=
eplying=C2=A0to=C2=A0say that decoupling formatting from string would be gr=
eat. And that seems to do that.</div><div>I didn't see exactly how it&#=
39;s used but=C2=A0it seems (but I'm sure someone will correct me here)=
it would be nice if this worked:</div><div><br></div><div><div>std::vector=
v;</div><div>So fmt(v. "whatever");</div><div><br></div></div><d=
iv>I wonder if the standard containers could expose themselves as buffers t=
hat would enable that or this if it's better:</div><div><br></div><div>=
<div>fmt(as_buffer(v), "whatever"); or fmt(v.as_buffer(), "w=
hatever") if that's better.</div></div><div><br></div><div>I don&#=
39;t see why std::array couldn't be made to work=C2=A0too=C2=A0etc. Doe=
s your=C2=A0wrapper=C2=A0support array?</div><div><br></div><div>It seems i=
t would be possible, or at least if the standard=C2=A0could help=C2=A0here.=
</div><div>Nicol's/boosts interface to default constructed allocation w=
ould seem useful to employ in this interface for=C2=A0fmt.</div><div><br></=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0a11a519-7383-43d5-a342-5fda9e1abb7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a11a519-7383-43d5-a342-5fda9e1abb7a=
%40isocpp.org</a>.<br />
------=_Part_2347_682790395.1484433181443--
------=_Part_2346_53810440.1484433181442--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 14 Jan 2017 18:31:42 -0800
Raw View
On s=C3=A1bado, 14 de janeiro de 2017 14:33:01 PST gmisocpp@gmail.com wrote=
:
> I was just in the process of replying to say that decoupling formatting
> from string would be great. And that seems to do that.
> I didn't see exactly how it's used but it seems (but I'm sure someone wil=
l
> correct me here) it would be nice if this worked:
>=20
> std::vector v;
> So fmt(v. "whatever");
Sorry, but.. why?
Why can't you just use std::string? Why does it need to be something=20
different?
The formatting code is likely to be big, so it's most likely not going to b=
e=20
inline. Therefore, it can't be templated.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7027114.Za510D0td2%40tjmaciei-mobl1.
.
Author: gmisocpp@gmail.com
Date: Sat, 14 Jan 2017 19:58:30 -0800 (PST)
Raw View
------=_Part_3360_231172710.1484452710530
Content-Type: multipart/alternative;
boundary="----=_Part_3361_1838425197.1484452710530"
------=_Part_3361_1838425197.1484452710530
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, January 15, 2017 at 3:31:47 PM UTC+13, Thiago Macieira wrote:
>
> On s=C3=A1bado, 14 de janeiro de 2017 14:33:01 PST gmis...@gmail.com=20
> <javascript:> wrote:=20
> > I was just in the process of replying to say that decoupling formatting=
=20
> > from string would be great. And that seems to do that.=20
> > I didn't see exactly how it's used but it seems (but I'm sure someone=
=20
> will=20
> > correct me here) it would be nice if this worked:=20
> >=20
> > std::vector v;=20
> > So fmt(v. "whatever");=20
>
> Sorry, but.. why?=20
>
> Why can't you just use std::string? Why does it need to be something=20
> different?=20
>
> The formatting code is likely to be big, so it's most likely not going to=
=20
> be=20
> inline. Therefore, it can't be templated.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
I wasn't saying you can't use a string, I was trying to say that it seems=
=20
to be fmt should be able to format into more than just a string.
Like an std::array, or std::vector or or whatever, via an adaptor or=20
otherwise. anything conforming to a buffer concept of some kind.
i.e. any thing that can present a block of memory containing characters.
quite how that works I'm not sure yet, I specifically wouldn't be keen to=
=20
only a format that worked only with a string and then need to copy that=20
somewhere else unless there was a good reason. There may be a good reason,=
=20
but it seems we should be aware of this.
I also don't want to format have to create that thing either, so I don't=20
see why we should be forced to dynamically create memory in order to format=
=20
which a string only thing would force.
If string has a member called fmt that defers to some outer fomat, fine if=
=20
that's a helper, but if a string was the sole means to format, I think=20
that's not a great thing without convincing motivation.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ff062649-7949-480e-a836-64cf59e0a75c%40isocpp.or=
g.
------=_Part_3361_1838425197.1484452710530
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, January 15, 2017 at 3:31:47 PM UTC+13, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On s=C3=A1bado, 14 de ja=
neiro de 2017 14:33:01 PST <a onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-ma=
ilto=3D"Qd2JDxVRBwAJ">gmis...@gmail.com</a> wrote:
<br>> I was just in the process of replying to say that decoupling forma=
tting
<br>> from string would be great. And that seems to do that.
<br>> I didn't see exactly how it's used but it seems (but I'=
;m sure someone will
<br>> correct me here) it would be nice if this worked:
<br>>=20
<br>> std::vector v;
<br>> So fmt(v. "whatever");
<br>
<br>Sorry, but.. why?
<br>
<br>Why can't you just use std::string? Why does it need to be somethin=
g=20
<br>different?
<br>
<br>The formatting code is likely to be big, so it's most likely not go=
ing to be=20
<br>inline. Therefore, it can't be templated.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>I wasn't saying you can't use =
a string, I was trying to=C2=A0say that it seems to be=C2=A0fmt should be a=
ble to format into more than just a string.</div><div>Like=C2=A0an std::arr=
ay, or std::vector or or whatever, via an adaptor or otherwise. anything co=
nforming to a buffer concept of some kind.</div><div><br></div><div>i.e. an=
y thing that can present a block of memory containing characters.</div><div=
><br></div><div>quite how that works I'm not sure yet, I specifically w=
ouldn't be keen to only=C2=A0a format that worked only with a string an=
d then need to copy that somewhere else unless there was a good reason. The=
re may be a good reason, but it seems we should be aware of this.</div><div=
>I also don't want to format have to create that thing either, so I don=
't see why we should be forced to dynamically create memory in order to=
format which a string only thing would force.</div><div>If string has a me=
mber called fmt that defers to some outer fomat, fine if that's a helpe=
r, but if a string was the sole means to format, I think that's not a g=
reat thing without convincing motivation.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ff062649-7949-480e-a836-64cf59e0a75c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff062649-7949-480e-a836-64cf59e0a75c=
%40isocpp.org</a>.<br />
------=_Part_3361_1838425197.1484452710530--
------=_Part_3360_231172710.1484452710530--
.
Author: gmisocpp@gmail.com
Date: Sat, 14 Jan 2017 20:04:23 -0800 (PST)
Raw View
------=_Part_3434_1555077887.1484453063475
Content-Type: multipart/alternative;
boundary="----=_Part_3435_1371526773.1484453063475"
------=_Part_3435_1371526773.1484453063475
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, January 15, 2017 at 3:31:47 PM UTC+13, Thiago Macieira wrote:
>
> On s=C3=A1bado, 14 de janeiro de 2017 14:33:01 PST gmis...@gmail.com=20
> <javascript:> wrote:=20
> > I was just in the process of replying to say that decoupling formatting=
=20
> > from string would be great. And that seems to do that.=20
> > I didn't see exactly how it's used but it seems (but I'm sure someone=
=20
> will=20
> > correct me here) it would be nice if this worked:=20
> >=20
> > std::vector v;=20
> > So fmt(v. "whatever");=20
>
> Sorry, but.. why?=20
>
> Why can't you just use std::string? Why does it need to be something=20
> different?=20
>
> The formatting code is likely to be big, so it's most likely not going to=
=20
> be=20
> inline. Therefore, it can't be templated.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
I could also imagine wanting to have a unique_ptr or char array from C that=
=20
I want to format into. I can write some adaptor to expose that if it=20
doesn't have anything already that adapts it. So no string at at all there.
I think the OP has these situations covered. It's just about how much=20
better they would be if the library comes into the standard and the=20
standard can adapt to make things even smoother for the library then if=20
need be.
I can imagine the standard help with such adaptors if that's what it needs.
Anyway I don't know how it would work but the emphasis is on not just=20
having string as the only sink for formatting is what I'm saying. And=20
having the standard make those other things very usable out of the box.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c5f30037-32c8-492a-8317-df79fb4dc3e1%40isocpp.or=
g.
------=_Part_3435_1371526773.1484453063475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, January 15, 2017 at 3:31:47 PM UTC+13, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On s=C3=A1bado, 14 de ja=
neiro de 2017 14:33:01 PST <a onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-ma=
ilto=3D"Qd2JDxVRBwAJ">gmis...@gmail.com</a> wrote:
<br>> I was just in the process of replying to say that decoupling forma=
tting
<br>> from string would be great. And that seems to do that.
<br>> I didn't see exactly how it's used but it seems (but I'=
;m sure someone will
<br>> correct me here) it would be nice if this worked:
<br>>=20
<br>> std::vector v;
<br>> So fmt(v. "whatever");
<br>
<br>Sorry, but.. why?
<br>
<br>Why can't you just use std::string? Why does it need to be somethin=
g=20
<br>different?
<br>
<br>The formatting code is likely to be big, so it's most likely not go=
ing to be=20
<br>inline. Therefore, it can't be templated.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>I could also imagine wanting to have a=
unique_ptr or char array from=C2=A0C that I want to format into. I can wri=
te some adaptor to expose that if it doesn't have anything already that=
adapts it. So no string at at all there.</div><div>I think the OP has thes=
e situations covered. It's just about how much better they would be if =
the library comes into the standard and the standard can adapt to make thin=
gs even smoother for the library then if need be.</div><div>I can imagine t=
he standard help with such adaptors if that's what it needs.</div><div>=
<br></div><div>Anyway I don't know how it would work but the emphasis i=
s on not just having string as the only sink for formatting is what I'm=
saying. And having the standard make those other things very usable out of=
the box.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c5f30037-32c8-492a-8317-df79fb4dc3e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c5f30037-32c8-492a-8317-df79fb4dc3e1=
%40isocpp.org</a>.<br />
------=_Part_3435_1371526773.1484453063475--
------=_Part_3434_1555077887.1484453063475--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 15 Jan 2017 00:23:04 -0800
Raw View
On s=C3=A1bado, 14 de janeiro de 2017 19:58:30 PST gmisocpp@gmail.com wrote=
:
> > Sorry, but.. why?
> >=20
> > Why can't you just use std::string? Why does it need to be something
> > different?
> >=20
> > The formatting code is likely to be big, so it's most likely not going =
to
> > be
> > inline. Therefore, it can't be templated.
>=20
> I wasn't saying you can't use a string, I was trying to say that it seems
> to be fmt should be able to format into more than just a string.
> Like an std::array, or std::vector or or whatever, via an adaptor or
> otherwise. anything conforming to a buffer concept of some kind.
Why can't we call that adaptor "std::string"?
> i.e. any thing that can present a block of memory containing characters.
And that can be reallocated to extend its size, or truncated once the true=
=20
size is known. And is contiguous, of course.
> quite how that works I'm not sure yet, I specifically wouldn't be keen to
> only a format that worked only with a string and then need to copy that
> somewhere else unless there was a good reason. There may be a good reason=
,
> but it seems we should be aware of this.
Let's start with the good reason. It has to be good enough to overcome the=
=20
need to make the library function more complex for the 99.99% of the uses.
I know he C library does it, and that it can reuse the same formatters to=
=20
output to a preallocated string (snprintf) or a file (fprintf). But that=20
probably only works because the C library internally writes to a buffer and=
=20
flushes it periodically. So in order to do the same for us, for multiple=20
different output classes, the formatting function would likely have to have=
=20
its own buffering. That's what I meant when I said it would be more complex=
=20
than it needs to be for the 99.99% of the uses.
> I also don't want to format have to create that thing either, so I don't
> see why we should be forced to dynamically create memory in order to form=
at
> which a string only thing would force.
If it can't allocate or reallocate, then it must be prepared for failing in=
=20
case of buffer overrun. When formatting, you usually don't want that becaus=
e=20
formatting can't be easily restarted from where it failed.=20
> If string has a member called fmt that defers to some outer fomat, fine i=
f
> that's a helper, but if a string was the sole means to format, I think
> that's not a great thing without convincing motivation.
See above.
I'd like to hear the motivation for formatting to anything else, compared t=
o=20
the added complexity to make it work. In other words: is it worth it?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1727123.2OmLujIbrJ%40tjmaciei-mobl1.
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sun, 15 Jan 2017 09:54:16 +0100
Raw View
On Sun, Jan 15, 2017 at 12:23:04AM -0800, Thiago Macieira wrote:
> On s=C3=A1bado, 14 de janeiro de 2017 19:58:30 PST gmisocpp@gmail.com wro=
te:
> > > Sorry, but.. why?
> > >=20
> > > Why can't you just use std::string? Why does it need to be something
> > > different?
> > >=20
> > > The formatting code is likely to be big, so it's most likely not goin=
g to
> > > be
> > > inline. Therefore, it can't be templated.
> >=20
> > I wasn't saying you can't use a string, I was trying to say that it see=
ms
> > to be fmt should be able to format into more than just a string.
> > Like an std::array, or std::vector or or whatever, via an adaptor or
> > otherwise. anything conforming to a buffer concept of some kind.
>=20
> Why can't we call that adaptor "std::string"?
>=20
> > i.e. any thing that can present a block of memory containing characters=
..
>=20
> And that can be reallocated to extend its size, or truncated once the tru=
e=20
> size is known. And is contiguous, of course.
>=20
> > quite how that works I'm not sure yet, I specifically wouldn't be keen =
to
> > only a format that worked only with a string and then need to copy that
> > somewhere else unless there was a good reason. There may be a good reas=
on,
> > but it seems we should be aware of this.
>=20
> Let's start with the good reason. It has to be good enough to overcome th=
e=20
> need to make the library function more complex for the 99.99% of the uses=
..
I think that one primary motivation for a fmt type interface is to ease
internationalization efforts. From there follows that one common output
target would be a streambuf. Now, I know that streams and performance in th=
e
same sentence is dodgy at best but why make it even worse with an unneeded
temporary std::string?
/MF
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20170115085416.GA23451%40noemi.
.
Author: gmisocpp@gmail.com
Date: Sun, 15 Jan 2017 03:00:51 -0800 (PST)
Raw View
------=_Part_1538_192872793.1484478051812
Content-Type: multipart/alternative;
boundary="----=_Part_1539_840258771.1484478051813"
------=_Part_1539_840258771.1484478051813
Content-Type: text/plain; charset=UTF-8
>
> >
> > I wasn't saying you can't use a string, I was trying to say that it
> seems
> > to be fmt should be able to format into more than just a string.
> > Like an std::array, or std::vector or or whatever, via an adaptor or
> > otherwise. anything conforming to a buffer concept of some kind.
>
> Why can't we call that adaptor "std::string"?
>
Well nobody knows for sure until we seen the options and what the problems
are with each option. And it might mean that their are several interfaces
required. cpp format seems to have a few so that probably tells you that we
will need a few and more than just string.
but to me in theory at least, if there is going to be only one interface,
it can't be string as having to allocate to do a format is a non starter to
me.
it's too slow. I don't see it as viable that you have to allocate to format.
> > i.e. any thing that can present a block of memory containing characters.
>
> And that can be reallocated to extend its size, or truncated once the true
> size is known. And is contiguous, of course.
>
> > quite how that works I'm not sure yet, I specifically wouldn't be keen
> to
> > only a format that worked only with a string and then need to copy that
> > somewhere else unless there was a good reason. There may be a good
> reason,
> > but it seems we should be aware of this.
>
> Let's start with the good reason. It has to be good enough to overcome the
> need to make the library function more complex for the 99.99% of the uses.
>
> I know he C library does it, and that it can reuse the same formatters to
> output to a preallocated string (snprintf) or a file (fprintf). But that
> probably only works because the C library internally writes to a buffer
> and
> flushes it periodically. So in order to do the same for us, for multiple
> different output classes, the formatting function would likely have to
> have
> its own buffering. That's what I meant when I said it would be more
> complex
> than it needs to be for the 99.99% of the uses.
>
> > I also don't want to format have to create that thing either, so I don't
> > see why we should be forced to dynamically create memory in order to
> format
> > which a string only thing would force.
>
> If it can't allocate or reallocate, then it must be prepared for failing
> in
> case of buffer overrun. When formatting, you usually don't want that
> because
> formatting can't be easily restarted from where it failed.
>
>
I think being prepared for failure is always a reality isn't it?
reallocation can fail, so?
but having to do memory allocation thing is the main issue here for me and
string is all that.
if I have a C interface where the caller passes me an array that's large
enough, why should I have to allocate memory to use it.
aren't I at risk of creating a string intensive api which is often a slow
down for many apps?
just string isn't 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b1a9b65a-42c7-4964-b9d0-1c4464bacba8%40isocpp.org.
------=_Part_1539_840258771.1484478051813
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;">>=20
<br>> I wasn't saying you can't use a string, I was trying to sa=
y that it seems
<br>> to be fmt should be able to format into more than just a string.
<br>> Like an std::array, or std::vector or or whatever, via an adaptor =
or
<br>> otherwise. anything conforming to a buffer concept of some kind.
<br>
<br>Why can't we call that adaptor "std::string"?
<br></blockquote><div><br></div><div>Well nobody knows for sure until we se=
en=C2=A0the options and what the problems are with each option. And it migh=
t mean that their are several interfaces required. cpp format seems to have=
a few so that probably tells you that we will need a few and more than jus=
t string.</div><div><br></div><div>but to me in theory at least, if there i=
s going to be only one interface, it can't be string as having to alloc=
ate to do a format is a non starter to me.</div><div>it's too slow.=C2=
=A0I don't see it as viable that you have to=C2=A0allocate to format.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">
<br>> i.e. any thing that can present a block of memory containing chara=
cters.
<br>
<br>And that can be reallocated to extend its size, or truncated once the t=
rue=20
<br>size is known. And is contiguous, of course.
<br>
<br>> quite how that works I'm not sure yet, I specifically wouldn&#=
39;t be keen to
<br>> only a format that worked only with a string and then need to copy=
that
<br>> somewhere else unless there was a good reason. There may be a good=
reason,
<br>> but it seems we should be aware of this.
<br>
<br>Let's start with the good reason. It has to be good enough to overc=
ome the=20
<br>need to make the library function more complex for the 99.99% of the us=
es.
<br>
<br>I know he C library does it, and that it can reuse the same formatters =
to=20
<br>output to a preallocated string (snprintf) or a file (fprintf). But tha=
t=20
<br>probably only works because the C library internally writes to a buffer=
and=20
<br>flushes it periodically. So in order to do the same for us, for multipl=
e=20
<br>different output classes, the formatting function would likely have to =
have=20
<br>its own buffering. That's what I meant when I said it would be more=
complex=20
<br>than it needs to be for the 99.99% of the uses.
<br>
<br>> I also don't want to format have to create that thing either, =
so I don't
<br>> see why we should be forced to dynamically create memory in order =
to format
<br>> which a string only thing would force.
<br>
<br>If it can't allocate or reallocate, then it must be prepared for fa=
iling in=20
<br>case of buffer overrun. When formatting, you usually don't want tha=
t because=20
<br>formatting can't be easily restarted from where it failed.=20
<br>
<br></blockquote><div><br></div><div>I think being prepared for failure is =
always a reality isn't it?</div><div>reallocation can fail, so?</div><d=
iv>but having to do memory allocation thing is the main issue here for me a=
nd string is all that.</div><div><br></div><div>if I have a C interface whe=
re the caller passes me an array that's large enough, why should I have=
to allocate memory to use it.</div><div>aren't I at risk of creating a=
string intensive api which is often a slow down for many apps?</div><div><=
br></div><div>just string isn't enough</div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b1a9b65a-42c7-4964-b9d0-1c4464bacba8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1a9b65a-42c7-4964-b9d0-1c4464bacba8=
%40isocpp.org</a>.<br />
------=_Part_1539_840258771.1484478051813--
------=_Part_1538_192872793.1484478051812--
.
Author: Victor Zverovich <victor.zverovich@gmail.com>
Date: Sun, 15 Jan 2017 15:51:50 +0000
Raw View
--001a11417e48366d400546240cba
Content-Type: text/plain; charset=UTF-8
>
> Why can't we call that adaptor "std::string"?
We can use std::string but it will add extra copying and memory allocation
when formatting anywhere else. For this reason the fmt library decouples
buffer management and formatting.
>
> Let's start with the good reason. It has to be good enough to overcome the
> need to make the library function more complex for the 99.99% of the uses.
>
See above. Also the complexity added by making buffer management more
generic is very small compared to the complexity of the actual formatting.
And formatting to std::string, although one of the main use cases, from my
experience is not anywhere close to 99%.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANawtxZftVjJ9ynSDYa1jwiVZ77qStuFv4rwzWVxF6Gwwg8n7Q%40mail.gmail.com.
--001a11417e48366d400546240cba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<br class=3D"gmail_msg">
Why can't we call that adaptor "std::string"?</blockquote><di=
v><br></div><div>We can use std::string but it will add extra copying and m=
emory allocation when formatting anywhere else. For this reason the fmt lib=
rary decouples buffer management and formatting.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<br class=3D"gmail_msg">
Let's start with the good reason. It has to be good enough to overcome =
the<br class=3D"gmail_msg">
need to make the library function more complex for the 99.99% of the uses.<=
br class=3D"gmail_msg"></blockquote><div><br></div><div>See above. Also the=
complexity added by making buffer management more generic is very small co=
mpared to the complexity of the actual formatting. And formatting to std::s=
tring, although one of the main use cases, from my experience is not anywhe=
re close to 99%.</div><div>=C2=A0</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANawtxZftVjJ9ynSDYa1jwiVZ77qStuFv4rw=
zWVxF6Gwwg8n7Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANawtxZftVjJ9ynS=
DYa1jwiVZ77qStuFv4rwzWVxF6Gwwg8n7Q%40mail.gmail.com</a>.<br />
--001a11417e48366d400546240cba--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 15 Jan 2017 11:13:32 -0800
Raw View
On domingo, 15 de janeiro de 2017 09:54:16 PST Magnus Fromreide wrote:
> I think that one primary motivation for a fmt type interface is to ease
> internationalization efforts. From there follows that one common output
> target would be a streambuf. Now, I know that streams and performance in the
> same sentence is dodgy at best but why make it even worse with an unneeded
> temporary std::string?
streambuf is fine, I guess. We need one output, not a template/concept.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4588951.Nx5ORMnJHp%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 15 Jan 2017 11:17:01 -0800
Raw View
On domingo, 15 de janeiro de 2017 03:00:51 PST gmisocpp@gmail.com wrote:
> I think being prepared for failure is always a reality isn't it?
> reallocation can fail, so?
> but having to do memory allocation thing is the main issue here for me and
> string is all that.
When a memory allocation fails, you get std::bad_alloc, which throws away the
entire attempt. So you don't attempt to continue, you just fail completely and
your out buffer contains unspecified contents.
Sized format functions like snprintf print as much as they can, then return it
saying they actually needed more. That's more complex.
> if I have a C interface where the caller passes me an array that's large
> enough, why should I have to allocate memory to use it.
> aren't I at risk of creating a string intensive api which is often a slow
> down for many apps?
Understood. I am saying that has to be weighed against the normal use-case
which is to output to a std::string. That has to be EASY to write and perform
really well.
> just string isn't enough
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/49574038.x7SjvB0W84%40tjmaciei-mobl1.
.
Author: gmisocpp@gmail.com
Date: Sun, 15 Jan 2017 14:35:08 -0800 (PST)
Raw View
------=_Part_3002_71103677.1484519708185
Content-Type: multipart/alternative;
boundary="----=_Part_3003_776856737.1484519708186"
------=_Part_3003_776856737.1484519708186
Content-Type: text/plain; charset=UTF-8
On Monday, January 16, 2017 at 8:13:38 AM UTC+13, Thiago Macieira wrote:
>
> On domingo, 15 de janeiro de 2017 09:54:16 PST Magnus Fromreide wrote:
> > I think that one primary motivation for a fmt type interface is to ease
> > internationalization efforts. From there follows that one common output
> > target would be a streambuf. Now, I know that streams and performance in
> the
> > same sentence is dodgy at best but why make it even worse with an
> unneeded
> > temporary std::string?
>
> streambuf is fine, I guess. We need one output, not a template/concept.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
I don't know for sure, but if it took bets I suspect a template/concept is
exactly what you want here.
Or at least one of the options.
I don't know what the template/concept would be, but at a minimum it would
be a buffer template/concept.
I think we need this anyway. At a maximum maybe something like formatable
or something is needed
that employed the former somehow. But I've no idea and I haven't looked at
what cpp format does hardly.
But it seems to have such words there and I'm sure it has the feature set
covered.
The issue to me is how much nicer/simpler it can be if it's in the standard
and the standard can change to accommodate making it nicer.
If the end result looked anything less than easy to use or fast for string
then I wouldn't object
to string having a special case that addressed this.
But I seems remiss if don't support these use cases:
extern "C" bool get_logfilename(char* buffer, int buffer_length)
{
fixed_buffer fb(buffer, buffer_length), whatever);
auto status = cpp::format(fb, whatever);
return !status.failed();
}
std::pair<bool, std::size_t> get_logfilename(char* buffer, int
buffer_length)
{
fixed_buffer fb(buffer, buffer_length), whatever);
auto format_status = cpp::format(fb, whatever);
if (format_status.failed())
return {false,{}};
return {true, buffer, format_satus.format_length);
}
std::pair<bool, std::size_t> get_logfilename(char* buffer, int
buffer_length)
{
auto fb { std::make_fixed_buffer(buffer,, buffer_length) };
auto format_status = cpp::format(fb, whatever);
if (format_status.failed())
return {false,{}};
return {true, buffer, format_satus.format_length);
}
std::string get_logfilename()
{
std::string logfilename
strng_buffer sb(logfilename);
auto format_status = cpp::format(sb, whatever);
return logfilename;
}
So we have these adaptors that adapt types as needed, .e.g. string_buffer
etc.
They model a buffer concept that would seem to require this:
is_fixed_size()
size()
resize()
resize_default_init(); // The boost/nicol proposal
capacity()
The fixed_buffer type provides an interface that models buffer
but allow writing into an arbitrary fixed size memory region.
A buffer that can't resize has is_fixed_size return true.
And then the other adaptors like string_buffer as needed but:
I don't see why std::unique_ptr can't also be invited to the party here.
But if not, oh well.
But I see no reason why std::string, std::vector, std::array can't model a
buffer directly but they don't have to.
If they did, wouldn't you be down to:
std::string get_logfilename()
{
std::string logfilename
auto format_status = cpp::format(logfilename, whatever);
return logfilename;
}
I don't want anyone to get hung up on this particular interface. The main
things
to me (in order of importance) is what the interface support these goals,
* we don't require memory allocation to format. (essential)
* we support types beyond string unless there is a good reason not to.
* we can format and avoid exceptions if we wish
* we can diagnose when something failed and why so we can then throw if
it's important.
* we enable init/default initialized resize to be used here to help
efficiency. it seems formatting can use this.
We need to know how certain formatting conditions fail and not just have
only a failed bit to check.
IMO we need to know at least:
out of memory (malloc/new failure),
buffer full (i.e. wanted to resize() but is_fixed_size() said no),
bad format string,
bad argument
I think we need to maximally attempt to format as much as possible and not
throw.
but format_status can contain an std::expected or something that exactly
says the issue.
you can expect that but typically wouldn't.
But lets see evidence supports these positions.
All of this seems achievable and cpp format seems to provide a lot of this
feature set.
To me it's just seeing if cpp format does support this needs and how and
why not and then
seeing how the Standard needs to change to make formatting even
easier/simpler than
whatever cpp format already does without that support today.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0136a5fe-14a0-41d8-ae27-330cd513fde8%40isocpp.org.
------=_Part_3003_776856737.1484519708186
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, January 16, 2017 at 8:13:38 AM UTC+13, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On domingo, 15 de janeir=
o de 2017 09:54:16 PST Magnus Fromreide wrote:
<br>> I think that one primary motivation for a fmt type interface is to=
ease
<br>> internationalization efforts. From there follows that one common o=
utput
<br>> target would be a streambuf. Now, I know that streams and performa=
nce in the
<br>> same sentence is dodgy at best but why make it even worse with an =
unneeded
<br>> temporary std::string?
<br>
<br>streambuf is fine, I guess. We need one output, not a template/concept.
<br></blockquote><div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><br>-- <br>Thiago Macie=
ira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" hr=
ef=3D"http://macieira.info/" target=3D"_blank" rel=3D"nofollow">macieira.in=
fo</a> - thiago (AT) <a onmousedown=3D"this.href=3D'http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHG=
RJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" href=3D"htt=
p://kde.org/" target=3D"_blank" rel=3D"nofollow">kde.org</a> <br>=C2=A0 =C2=
=A0Software Architect - Intel Open Source Technology Center=C2=A0<br>=C2=A0=
</blockquote></div><div><br></div><div>I don't know for sure, but if it=
took bets I suspect a template/concept is exactly what you want here.</div=
><div>Or at least one of the options.</div><div><br></div><div>I don't =
know what the template/concept would be, but at a=C2=A0minimum it would be =
a buffer template/concept.</div><div>I think we need this anyway. At a maxi=
mum maybe something like formatable or something is needed</div><div>that e=
mployed the former somehow. But I've no idea and I haven't looked a=
t what cpp format does hardly.</div><div>But it seems to have such words th=
ere and I'm sure it has the feature set covered.</div><div>The issue to=
me is how much nicer/simpler it can be if it's in the standard and the=
standard=C2=A0can change to accommodate making it nicer.</div><div><br></d=
iv><div>If=C2=A0the end result looked anything less than easy=C2=A0to use o=
r fast for string then=C2=A0I wouldn't object</div><div>to string havin=
g a special case that addressed this.</div><div><br></div><div>But I seems =
remiss if=C2=A0don't support these=C2=A0use cases:</div><div><br></div>=
<div>extern "C" bool get_logfilename(char* buffer, int buffer_len=
gth)</div><div>{</div><div>=C2=A0=C2=A0 fixed_buffer fb(buffer, buffer_leng=
th), whatever);</div><div>=C2=A0=C2=A0 auto status =3D cpp::format(fb, what=
ever);</div><div>=C2=A0=C2=A0 return !status.failed();</div><div>}</div><di=
v><br></div><div><div>std::pair<bool, std::size_t> get_logfilename(ch=
ar* buffer, int buffer_length)</div><div>{</div><div>=C2=A0=C2=A0 fixed_buf=
fer fb(buffer, buffer_length), whatever);</div><div>=C2=A0=C2=A0 auto forma=
t_status =3D cpp::format(fb, whatever);</div><div>=C2=A0=C2=A0 if (format_s=
tatus.failed())</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return {fals=
e,{}};</div><div>=C2=A0=C2=A0 return {true, buffer, format_satus.format_len=
gth);</div><div>}</div><div><br></div><div><div><div>std::pair<bool, std=
::size_t> get_logfilename(char* buffer, int buffer_length)</div><div>{</=
div><div>=C2=A0=C2=A0=C2=A0auto fb=C2=A0{=C2=A0std::make_fixed_buffer(buffe=
r,, buffer_length) };</div><div>=C2=A0=C2=A0 auto format_status =3D cpp::fo=
rmat(fb, whatever);</div><div>=C2=A0=C2=A0 if (format_status.failed())</div=
><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return {false,{}};</div><div>=C2=
=A0=C2=A0 return {true, buffer, format_satus.format_length);</div><div>}</d=
iv><div>=C2=A0</div></div></div><div>std::string get_logfilename()</div><di=
v>{</div><div>=C2=A0=C2=A0 std::string logfilename<br><br></div><div>=C2=A0=
=C2=A0 strng_buffer sb(logfilename);</div><div>=C2=A0=C2=A0 auto format_sta=
tus =3D cpp::format(sb, whatever);</div><div>=C2=A0=C2=A0 return logfilenam=
e;</div><div>}</div><div><br></div><div>So we have=C2=A0these=C2=A0adaptors=
that adapt types as needed, .e.g. string_buffer etc.</div></div><div>They=
=C2=A0model a buffer concept that would seem to require=C2=A0this:</div><di=
v>is_fixed_size()</div><div>size()</div><div>resize()</div><div>resize_defa=
ult_init(); //=C2=A0The boost/nicol proposal</div><div>capacity()</div><div=
><br></div><div><div>The=C2=A0fixed_buffer=C2=A0type=C2=A0provides=C2=A0an =
interface=C2=A0that models buffer</div><div>but allow=C2=A0writing into an =
arbitrary fixed size memory region.</div><div><div><div>A buffer=C2=A0that =
can't resize=C2=A0has is_fixed_size return true.</div></div></div></div=
><div><br></div><div>And then the other adaptors like string_buffer as need=
ed but:</div><div><div><div>I=C2=A0don't see why std::unique_ptr can=
9;t also be invited to the party here. But if not, oh well.</div></div></di=
v><p><br></p><div>But I see no reason why std::string, std::vector, std::ar=
ray can't model=C2=A0a buffer directly but they don't have to.</div=
><div>If they did, wouldn't you be down to:</div><div><div><br></div></=
div><div><div>std::string get_logfilename()</div><div>{</div><div>=C2=A0=C2=
=A0 std::string logfilename<br><br></div><div>=C2=A0=C2=A0 auto format_stat=
us =3D cpp::format(logfilename, whatever);</div><div>=C2=A0=C2=A0 return lo=
gfilename;</div><div>}</div></div><div><br></div><div>I don't want anyo=
ne to get hung up on this particular interface. The main things</div><div>t=
o me=C2=A0(in order of importance) is what the interface support these goal=
s,</div><div>* we don't require memory allocation to format. (essential=
)</div><div>*=C2=A0we support=C2=A0types beyond string=C2=A0unless there is=
a good reason not to.</div><div>* we can format and avoid exceptions if we=
wish</div><div>* we can diagnose when something failed and why so we can t=
hen throw if it's important.</div><div>*=C2=A0we enable=C2=A0init/defau=
lt initialized resize=C2=A0to be used=C2=A0here to help efficiency. it=C2=
=A0seems formatting=C2=A0can use this.</div><div><br></div><div>We=C2=A0nee=
d to=C2=A0know=C2=A0how certain formatting conditions fail and not just=C2=
=A0have only a=C2=A0failed bit to check.</div><div>IMO we=C2=A0need to know=
at least:</div><div>out of memory (malloc/new failure),</div><div>buffer f=
ull (i.e. wanted to resize() but is_fixed_size() said no),</div><div>bad fo=
rmat string,</div><div>bad argument</div><div><br></div><div>I think we nee=
d to maximally attempt to format as much as possible and not throw.</div><d=
iv>but format_status can contain an std::expected or something that exactly=
says the issue.</div><div>you can expect that but typically wouldn't.<=
/div><div><br></div><div>But lets see evidence supports these=C2=A0position=
s.</div><div><br></div><div>All of this seems achievable and cpp format see=
ms to provide=C2=A0a lot of=C2=A0this feature set.</div><div><br></div><div=
>To me it's just seeing if=C2=A0cpp format does support this needs and =
how and why not and then</div><div>seeing how the Standard needs to change =
to make formatting even easier/simpler=C2=A0than</div><div>whatever cpp for=
mat already does=C2=A0without that support today.</div><div><br></div><div>=
<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0136a5fe-14a0-41d8-ae27-330cd513fde8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0136a5fe-14a0-41d8-ae27-330cd513fde8=
%40isocpp.org</a>.<br />
------=_Part_3003_776856737.1484519708186--
------=_Part_3002_71103677.1484519708185--
.
Author: masse.nicolas@gmail.com
Date: Wed, 18 Jan 2017 14:10:47 -0800 (PST)
Raw View
------=_Part_2330_1490349458.1484777447719
Content-Type: multipart/alternative;
boundary="----=_Part_2331_858648000.1484777447719"
------=_Part_2331_858648000.1484777447719
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi all,
I haven't read all the post, but from what I've read, i'd say there is 2=20
subject here:
- 1st Concatenating several string easily and efficiently
For doing so what i've done on my side is to implement an algorithm (called=
=20
concat) able to do it.
It take as argument several strings in a container (can bean array, an=20
initializer_list, an vector, whatever..) and return the concatenated=20
string. The concatenation compute the required size so that it do only one=
=20
allocation.
Note that I also implemented an variant able to add a separator between=20
each std::dtring given in parameter.
- 2nd Be able to create a string from a predefined format
This is what printf is often used for. Having something similar in cpp=20
would be nice. But I think this will require adding something on the=20
std::string interface since I hardly see an algorithm being able to do that=
=20
because it is something quite string-specific .
Just my 2 cents,
Masse Nicolas.
Le mercredi 28 d=C3=A9cembre 2016 09:50:40 UTC+1, Olaf van der Spek a =C3=
=A9crit :
>
> Hi,
>
> One frequently needs to append stuff to strings, but the standard way
> (s +=3D "A" + "B" + to_string(42)) isn't optimal due to temporaries.
> A variadic append() for std::string seems like the obvious solution.
> It could support string_view, integers, maybe floats
> but without formatting options..
> It could even be extensible by calling append(s, t);
>
> append(s, "A", "B", 42);
>
> Would this be useful for the C++ std lib?
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/99ace3a8-f706-48d2-a8dd-fe916713fe49%40isocpp.or=
g.
------=_Part_2331_858648000.1484777447719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi all,<br>I haven't read all the post, but from what =
I've read, i'd say there is 2 subject here:<br>- 1st Concatenating =
several string easily and efficiently<br>For doing so what i've done on=
my side is to implement an algorithm (called concat) able to do it.<br>It =
take as argument several strings in a container (can bean array, an initial=
izer_list, an vector, whatever..) and return the concatenated string. The c=
oncatenation compute the required size so that it do only one allocation.<b=
r>Note that I also implemented an variant able to add a separator between e=
ach std::dtring given in parameter.<br><br>- 2nd Be able to create a string=
from a predefined format<br>This is what printf is often used for. Having =
something similar in cpp would be nice. But I think this will require addin=
g something on the std::string interface since I hardly see an algorithm be=
ing able to do that because it is something quite string-specific .<br><br>=
Just my 2 cents,<br>Masse Nicolas.<br><br>Le mercredi 28 d=C3=A9cembre 2016=
09:50:40 UTC+1, Olaf van der Spek a =C3=A9crit=C2=A0:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><span style=3D"font-family:arial,s=
ans-serif;font-size:12.8px">Hi,</span><br style=3D"font-family:arial,sans-s=
erif;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;font-size:=
12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">One f=
requently needs to append stuff to strings, but the standard way</span><br =
style=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font=
-family:arial,sans-serif;font-size:12.8px">(s +=3D "A" + "B&=
quot; + to_string(42)) isn't optimal due to temporaries.</span><br styl=
e=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fam=
ily:arial,sans-serif;font-size:12.8px">A variadic append() for std::string =
seems like the obvious solution.</span><br style=3D"font-family:arial,sans-=
serif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-si=
ze:12.8px">It could support string_view, integers, maybe floats</span><br s=
tyle=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-=
family:arial,sans-serif;font-size:12.8px">but without formatting options..<=
/span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span sty=
le=3D"font-family:arial,sans-serif;font-size:12.8px">It could even be exten=
sible by calling append(s, t);</span><br style=3D"font-family:arial,sans-se=
rif;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;font-size:1=
2.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">append=
(s, "A", "B", 42);</span><br style=3D"font-family:arial=
,sans-serif;font-size:12.8px"><br style=3D"font-family:arial,sans-serif;fon=
t-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px=
">Would this be useful for the C++ std lib?</span><br></div></blockquote></=
div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99ace3a8-f706-48d2-a8dd-fe916713fe49%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99ace3a8-f706-48d2-a8dd-fe916713fe49=
%40isocpp.org</a>.<br />
------=_Part_2331_858648000.1484777447719--
------=_Part_2330_1490349458.1484777447719--
.
Author: G M <gmisocpp@gmail.com>
Date: Thu, 19 Jan 2017 13:28:08 +1300
Raw View
--001a114525688b1f7b0546679b7b
Content-Type: text/plain; charset=UTF-8
>
> - 2nd Be able to create a string from a predefined format
> This is what printf is often used for. Having something similar in cpp
> would be nice. But I think this will require adding something on the
> std::string interface since I hardly see an algorithm being able to do that
> because it is something quite string-specific .
>
> Just my 2 cents,
> Masse Nicolas.
>
>
>
string exposes all that is needed to write or expand it and inquire it's
size.
vector also exposes all these facilities.
So format doesn't need to be a member function of string to use these
services to write data into a string,
And if it were a member of string, we'd not have the ability to use a
vector even though vector offers the same services as string to access the
internal array. so if vector offers the ability why shouldn't we use it.
The ability to write into a C array seems essential to me, both for writing
C compatible libraries, and to avoid memory allocation. Once you want to
avoid memory allocation, you may want to format into std::array also.
So supporting non memory allocating buffers is essential to my
mind. And you can't do that if your format function is tied into a string.
It seems to me a buffer concept would unify these and allow format to work
with anything and be no less or little less easy to use.
The cpp format has features that enable other containers to work. But I've
yet to look into cpp format in detail. But if formatting gets into the
standard as it surely must I'm sure it can make it even easier to use.
There may be good reasons not to go this route but I haven't heard anything
that convinces me yet that this isn't the way to go. Having only a single
string member function is a bad option to my mind. A member function of
string and other options too, sure, if there's a good reason for it, but
not the as the only option.
I note we have std::size() and std::data(). A question for the
Committee, if we also had std::is_fixed_size() and std::resize() could we
not make an std::format(container, ...) work with any of these types
without anything concepty being required?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGxCow2ZX4LixZj3ZOZiqzAZjfS-KoAMu55OhMpCj8w2oymT-w%40mail.gmail.com.
--001a114525688b1f7b0546679b7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-lef=
t:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-=
style:solid"><div dir=3D"ltr">- 2nd Be able to create a string from a prede=
fined format<br>This is what printf is often used for. Having something sim=
ilar in cpp would be nice. But I think this will require adding something o=
n the std::string interface since I hardly see an algorithm being able to d=
o that because it is something quite string-specific .=C2=A0</div></blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pad=
ding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bord=
er-left-style:solid"><div dir=3D"ltr"><br>Just my 2 cents,<br>Masse Nicolas=
..<span><br><br></span><br></div></blockquote><div>=C2=A0</div><div>string e=
xposes all that is needed to write or expand it and inquire it's size.<=
/div><div>vector also=C2=A0exposes all these facilities.</div><div><br></di=
v><div>So format doesn't need to be a member function of string to use =
these services to write data into a string,</div><div>And if it were a memb=
er of string, we'd not have the ability to use a vector even though vec=
tor offers the same services as string to access the internal array. so if =
vector offers the ability why shouldn't we use it.</div><div><br></div>=
<div>The ability to write into a C array seems essential to me, both for=C2=
=A0writing C compatible libraries,=C2=A0and to avoid memory allocation. Onc=
e you want to avoid memory allocation, you may want to format into std::arr=
ay also.</div><div>So supporting non memory allocating buffers is essential=
to my mind.=C2=A0And=C2=A0you can't do that=C2=A0if your format functi=
on is tied into a string.</div><div><br></div><div>It seems to me a buffer =
concept would unify these and allow format to work with anything and be no =
less or little less easy to use.</div><div><br></div><div>The cpp format ha=
s features that enable other containers to work. But I've yet to look i=
nto cpp format in detail. But if formatting gets into the standard as it su=
rely must I'm sure it can make it even easier to use.</div><div><br></d=
iv><div>There may be good reasons not to go this route=C2=A0but I haven'=
;t heard anything that convinces me yet that this isn't the way to go.=
=C2=A0Having only=C2=A0a single string member function is a bad option to m=
y mind. A member function of string and other options too, sure, if there&#=
39;s a good reason for it, but not the as the only option.</div><div><br></=
div><div><div>I note=C2=A0we have std::size() and std::data(). A question f=
or the Committee,=C2=A0if=C2=A0we also had=C2=A0std::is_fixed_size() and st=
d::resize()=C2=A0could we not=C2=A0make an std::format(container, ...)=C2=
=A0work with any of these types without anything concepty being required?</=
div></div><div><br></div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGxCow2ZX4LixZj3ZOZiqzAZjfS-KoAMu55O=
hMpCj8w2oymT-w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGxCow2ZX4LixZj3=
ZOZiqzAZjfS-KoAMu55OhMpCj8w2oymT-w%40mail.gmail.com</a>.<br />
--001a114525688b1f7b0546679b7b--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Fri, 20 Jan 2017 02:58:48 -0800 (PST)
Raw View
------=_Part_474_218542863.1484909928408
Content-Type: multipart/alternative;
boundary="----=_Part_475_1389729474.1484909928408"
------=_Part_475_1389729474.1484909928408
Content-Type: text/plain; charset=UTF-8
On Thursday, 19 January 2017 00:28:10 UTC, G M wrote:
>
> - 2nd Be able to create a string from a predefined format
>> This is what printf is often used for. Having something similar in cpp
>> would be nice. But I think this will require adding something on the
>> std::string interface since I hardly see an algorithm being able to do that
>> because it is something quite string-specific .
>>
>
>> Just my 2 cents,
>> Masse Nicolas.
>>
>>
>>
> string exposes all that is needed to write or expand it and inquire it's
> size.
> vector also exposes all these facilities.
>
> So format doesn't need to be a member function of string to use these
> services to write data into a string,
> And if it were a member of string, we'd not have the ability to use a
> vector even though vector offers the same services as string to access the
> internal array. so if vector offers the ability why shouldn't we use it.
>
> The ability to write into a C array seems essential to me, both
> for writing C compatible libraries, and to avoid memory allocation. Once
> you want to avoid memory allocation, you may want to format into std::array
> also.
> So supporting non memory allocating buffers is essential to my
> mind. And you can't do that if your format function is tied into a string.
>
> It seems to me a buffer concept would unify these and allow format to work
> with anything and be no less or little less easy to use.
>
> The cpp format has features that enable other containers to work. But I've
> yet to look into cpp format in detail. But if formatting gets into the
> standard as it surely must I'm sure it can make it even easier to use.
>
> There may be good reasons not to go this route but I haven't heard
> anything that convinces me yet that this isn't the way to go. Having only a
> single string member function is a bad option to my mind. A member function
> of string and other options too, sure, if there's a good reason for it, but
> not the as the only option.
>
> I note we have std::size() and std::data(). A question for the
> Committee, if we also had std::is_fixed_size() and std::resize() could we
> not make an std::format(container, ...) work with any of these types
> without anything concepty being required?
>
Formatting into a container is overly restrictive; one may also want to be
able to format into a preallocated subrange (e.g. character positions 10-20
of a string) or to an output stream (console, file or network).
I think the more general concept is OutputRange, which could encapsulate
e.g. a back inserter for string or vector (expandable storage), a pair of
char pointers for an array, C array or subrange, or an ostreambuf_iterator
for an output stream.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5ab16bc7-c497-494c-a12b-cf5740173a65%40isocpp.org.
------=_Part_475_1389729474.1484909928408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, 19 January 2017 00:28:10 UTC, G M wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid"><div dir=3D"ltr">- 2nd Be able to create =
a string from a predefined format<br>This is what printf is often used for.=
Having something similar in cpp would be nice. But I think this will requi=
re adding something on the std::string interface since I hardly see an algo=
rithm being able to do that because it is something quite string-specific .=
=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><br>Just my 2 ce=
nts,<br>Masse Nicolas.<span><br><br></span><br></div></blockquote><div>=C2=
=A0</div><div>string exposes all that is needed to write or expand it and i=
nquire it's size.</div><div>vector also=C2=A0exposes all these faciliti=
es.</div><div><br></div><div>So format doesn't need to be a member func=
tion of string to use these services to write data into a string,</div><div=
>And if it were a member of string, we'd not have the ability to use a =
vector even though vector offers the same services as string to access the =
internal array. so if vector offers the ability why shouldn't we use it=
..</div><div><br></div><div>The ability to write into a C array seems essent=
ial to me, both for=C2=A0writing C compatible libraries,=C2=A0and to avoid =
memory allocation. Once you want to avoid memory allocation, you may want t=
o format into std::array also.</div><div>So supporting non memory allocatin=
g buffers is essential to my mind.=C2=A0And=C2=A0you can't do that=C2=
=A0if your format function is tied into a string.</div><div><br></div><div>=
It seems to me a buffer concept would unify these and allow format to work =
with anything and be no less or little less easy to use.</div><div><br></di=
v><div>The cpp format has features that enable other containers to work. Bu=
t I've yet to look into cpp format in detail. But if formatting gets in=
to the standard as it surely must I'm sure it can make it even easier t=
o use.</div><div><br></div><div>There may be good reasons not to go this ro=
ute=C2=A0but I haven't heard anything that convinces me yet that this i=
sn't the way to go.=C2=A0Having only=C2=A0a single string member functi=
on is a bad option to my mind. A member function of string and other option=
s too, sure, if there's a good reason for it, but not the as the only o=
ption.</div><div><br></div><div><div>I note=C2=A0we have std::size() and st=
d::data(). A question for the Committee,=C2=A0if=C2=A0we also had=C2=A0std:=
:is_fixed_size() and std::resize()=C2=A0could we not=C2=A0make an std::form=
at(container, ...)=C2=A0work with any of these types without anything conce=
pty being required?</div></div></div></div></div></blockquote><div><br></di=
v><div>Formatting into a container is overly restrictive; one may also want=
to be able to format into a preallocated subrange (e.g. character position=
s 10-20 of a string) or to an output stream (console, file or network).</di=
v><div><br></div><div>I think the more general concept is OutputRange, whic=
h could encapsulate e.g. a back inserter for string or vector (expandable s=
torage), a pair of char pointers for an array, C array or subrange, or an o=
streambuf_iterator for an output stream.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5ab16bc7-c497-494c-a12b-cf5740173a65%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5ab16bc7-c497-494c-a12b-cf5740173a65=
%40isocpp.org</a>.<br />
------=_Part_475_1389729474.1484909928408--
------=_Part_474_218542863.1484909928408--
.
Author: gmisocpp@gmail.com
Date: Fri, 20 Jan 2017 04:22:35 -0800 (PST)
Raw View
------=_Part_2128_968810093.1484914955645
Content-Type: multipart/alternative;
boundary="----=_Part_2129_1299403795.1484914955645"
------=_Part_2129_1299403795.1484914955645
Content-Type: text/plain; charset=UTF-8
>
>
>> I note we have std::size() and std::data(). A question for the
>> Committee, if we also had std::is_fixed_size() and std::resize() could we
>> not make an std::format(container, ...) work with any of these types
>> without anything concepty being required?
>>
>
> Formatting into a container is overly restrictive; one may also want to be
> able to format into a preallocated subrange (e.g. character positions 10-20
> of a string) or to an output stream (console, file or network).
>
> I think the more general concept is OutputRange, which could encapsulate
> e.g. a back inserter for string or vector (expandable storage), a pair of
> char pointers for an array, C array or subrange, or an ostreambuf_iterator
> for an output stream.
>
I agree. I was experimenting today with an interface where you create a
buffer object to format into that was also flushable.
A make buffer routine creates a wrapper object for a vector, array, c
array, stream etc. type but exposing a common interface
of data() and resize and flush methods and also can_resize() and can_flush.
and I passed that to my format routine.
The format routine just writes into the buffer extending the buffer if
possible until a maximum size has been reached,
It the buffer advertised it can be flushed it is flushed and the process is
repeated until the formatting is done.
If the buffer is not flushable or cannot be extended writing stops and
there is an error.
An std::vector would not advertise it can flush and it's flush method would
do nothing.
An std:;array would not advertise it can be extended and resizing would do
nothing.
A stream might advertise itself as being a buffer that can be extended and
flushed. or it may say its a fixed size but can be flushed.
vectors and strings and arrays are buffers, streams wrap buffers. so they
can all provide a unified buffer interface.
I tried a little test out of that and it seemed to be workable. I just had
one format routine and it was able to write to these types.
And also the buffer interface isn't format specific so any other type
of append or whatever routine could use it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27c61e0a-57ec-4d9d-b438-00b14518ca87%40isocpp.org.
------=_Part_2129_1299403795.1484914955645
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div><div>I=
note=C2=A0we have std::size() and std::data(). A question for the Committe=
e,=C2=A0if=C2=A0we also had=C2=A0std::is_fixed_size() and std::resize()=C2=
=A0could we not=C2=A0make an std::format(container, ...)=C2=A0work with any=
of these types without anything concepty being required?</div></div></div>=
</div></div></blockquote><div><br></div><div>Formatting into a container is=
overly restrictive; one may also want to be able to format into a prealloc=
ated subrange (e.g. character positions 10-20 of a string) or to an output =
stream (console, file or network).</div><div><br></div><div>I think the mor=
e general concept is OutputRange, which could encapsulate e.g. a back inser=
ter for string or vector (expandable storage), a pair of char pointers for =
an array, C array or subrange, or an ostreambuf_iterator for an output stre=
am.</div></div></blockquote><div><br></div><div>I agree.=C2=A0I was experim=
enting today=C2=A0with an interface where you=C2=A0create a buffer object=
=C2=A0to format into that was also flushable.</div><div>A make buffer routi=
ne=C2=A0creates a wrapper object for a vector, array, c array, stream=C2=A0=
etc. type but exposing=C2=A0a common interface </div><div>of data() and res=
ize and flush methods and also can_resize() and can_flush. and I=C2=A0passe=
d that to my format routine.</div><div><br></div><div>The format routine ju=
st=C2=A0writes into the buffer=C2=A0extending the buffer if possible until =
a maximum size has been reached,</div><div>It the buffer=C2=A0advertised it=
can be flushed it is=C2=A0flushed and the process is repeated until the fo=
rmatting is done.</div><div>If the buffer is not flushable or cannot be ext=
ended=C2=A0writing stops and there is an error.</div><div>An std::vector wo=
uld not advertise it can flush and it's flush method would do nothing.<=
/div><div>An std:;array would not advertise it can be extended and resizing=
would do nothing.</div><div>A stream might advertise itself as being a buf=
fer that can be=C2=A0extended=C2=A0and flushed. or it may say its a fixed s=
ize but can be flushed.</div><div><br></div><div>vectors and strings and ar=
rays are buffers, streams=C2=A0wrap buffers. so=C2=A0they can all provide a=
unified buffer interface.</div><div><br></div><div>I tried a little test o=
ut of that and it seemed to be workable. I just had one format routine and =
it was able to write to these types.</div><div>And also the buffer interfac=
e isn't format specific so any other type of=C2=A0append or whatever ro=
utine could use it.</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/27c61e0a-57ec-4d9d-b438-00b14518ca87%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27c61e0a-57ec-4d9d-b438-00b14518ca87=
%40isocpp.org</a>.<br />
------=_Part_2129_1299403795.1484914955645--
------=_Part_2128_968810093.1484914955645--
.
Author: olaf@join.cc
Date: Tue, 24 Jan 2017 07:56:00 -0800 (PST)
Raw View
------=_Part_267_988016572.1485273360760
Content-Type: multipart/alternative;
boundary="----=_Part_268_1506609181.1485273360760"
------=_Part_268_1506609181.1485273360760
Content-Type: text/plain; charset=UTF-8
Op vrijdag 20 januari 2017 11:58:48 UTC+1 schreef Edward Catmur:
>
>
> Formatting into a container is overly restrictive; one may also want to be
> able to format into a preallocated subrange (e.g. character positions 10-20
> of a string) or to an output stream (console, file or network).
>
> I think the more general concept is OutputRange, which could encapsulate
> e.g. a back inserter for string or vector (expandable storage), a pair of
> char pointers for an array, C array or subrange, or an ostreambuf_iterator
> for an output stream.
>
Sounds good, how would that interact with calls to reserve() and memcpy()
optimizations (for larger strings) though?
I don't think anything is stopping one from providing both variants.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34c01da3-f647-491f-a836-7e185218262a%40isocpp.org.
------=_Part_268_1506609181.1485273360760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Op vrijdag 20 januari 2017 11:58:48 UTC+1 schreef =
Edward Catmur:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><br></div><div>Formatting into a container is overly restrictive; one=
may also want to be able to format into a preallocated subrange (e.g. char=
acter positions 10-20 of a string) or to an output stream (console, file or=
network).</div><div><br></div><div>I think the more general concept is Out=
putRange, which could encapsulate e.g. a back inserter for string or vector=
(expandable storage), a pair of char pointers for an array, C array or sub=
range, or an ostreambuf_iterator for an output stream.</div></div></blockqu=
ote><div><br></div><div>Sounds good, how would that interact with calls to =
reserve() and memcpy() optimizations (for larger strings) though?=C2=A0</di=
v><div><br></div><div>I don't think anything is stopping one from provi=
ding both variants.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34c01da3-f647-491f-a836-7e185218262a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34c01da3-f647-491f-a836-7e185218262a=
%40isocpp.org</a>.<br />
------=_Part_268_1506609181.1485273360760--
------=_Part_267_988016572.1485273360760--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 28 Jan 2017 18:39:38 +0000
Raw View
--f403045ee6d8aaa65e05472be727
Content-Type: text/plain; charset=UTF-8
On 24 Jan 2017 3:56 pm, <olaf@join.cc> wrote:
Op vrijdag 20 januari 2017 11:58:48 UTC+1 schreef Edward Catmur:
>
> Formatting into a container is overly restrictive; one may also want to be
> able to format into a preallocated subrange (e.g. character positions 10-20
> of a string) or to an output stream (console, file or network).
>
> I think the more general concept is OutputRange, which could encapsulate
> e.g. a back inserter for string or vector (expandable storage), a pair of
> char pointers for an array, C array or subrange, or an ostreambuf_iterator
> for an output stream.
>
Sounds good, how would that interact with calls to reserve() and memcpy()
optimizations (for larger strings) though?
That's a good point, and it's probably not enough (though theoretically
correct) to say that exponential growth makes reserve() moot. What I'd like
would be an OutputRange concept that allows creation of a contiguous memory
range, probably via the & and += operators, so giving output iterators more
of the hierarchy that input iterators demonstrate. Since a back inserter is
aware of its container target, it can know whether the container is
contiguous. For example:
auto it = back_inserter(s); // it models ContiguousOutputIterator
auto p = &*it; // returns s.data() + s.size()
it += 12; // performs s.resize(s.size() + 12, uninitialized)
memcpy(p, buf, 12);
I don't think anything is stopping one from providing both variants.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOahJN4j%3Df124UvFnxANt9t6Gz7FX%3DRWj-Or9j4iF6iCiw%40mail.gmail.com.
--f403045ee6d8aaa65e05472be727
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 24 Jan 2017 3:56 pm, <olaf@join.cc> wrote:<br type=3D"a=
ttribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>Op vrijdag 20=
januari 2017 11:58:48 UTC+1 schreef Edward Catmur:<div class=3D"quoted-tex=
t"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>=
<div>Formatting into a container is overly restrictive; one may also want t=
o be able to format into a preallocated subrange (e.g. character positions =
10-20 of a string) or to an output stream (console, file or network).</div>=
<div><br></div><div>I think the more general concept is OutputRange, which =
could encapsulate e.g. a back inserter for string or vector (expandable sto=
rage), a pair of char pointers for an array, C array or subrange, or an ost=
reambuf_iterator for an output stream.</div></div></blockquote><div><br></d=
iv></div><div>Sounds good, how would that interact with calls to reserve() =
and memcpy() optimizations (for larger strings) though?=C2=A0</div><div></d=
iv></div></blockquote></div></div></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">That's a good point, and it's probably not enough (thoug=
h theoretically correct) to say that exponential growth makes reserve() moo=
t. What I'd like would be an OutputRange concept that allows creation o=
f a contiguous memory range, probably via the & and +=3D operators, so =
giving output iterators more of the hierarchy that input iterators demonstr=
ate. Since a back inserter is aware of its container target, it can know wh=
ether the container is contiguous. For example:</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">auto it =3D back_inserter(s); // it models Contiguo=
usOutputIterator</div><div dir=3D"auto">auto p =3D &*it; // returns s.d=
ata() + s.size()</div><div dir=3D"auto">it +=3D 12; // performs s.resize(s.=
size() + 12, uninitialized)</div><div dir=3D"auto">memcpy(p, buf, 12);</div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><br></div><div>I don't think anything is stop=
ping one from providing both variants.</div></div><div class=3D"quoted-text=
">
<p></p><br></div></blockquote></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOahJN4j%3Df124UvFnxANt9t6Gz7FX%=
3DRWj-Or9j4iF6iCiw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOahJN4j=
%3Df124UvFnxANt9t6Gz7FX%3DRWj-Or9j4iF6iCiw%40mail.gmail.com</a>.<br />
--f403045ee6d8aaa65e05472be727--
.
Author: olafvdspek@gmail.com
Date: Sat, 17 Jun 2017 00:30:06 -0700 (PDT)
Raw View
------=_Part_1268_1837129130.1497684606323
Content-Type: multipart/alternative;
boundary="----=_Part_1269_1156431917.1497684606324"
------=_Part_1269_1156431917.1497684606324
Content-Type: text/plain; charset="UTF-8"
Op woensdag 28 december 2016 09:50:40 UTC+1 schreef Olaf van der Spek:
>
> Hi,
>
> One frequently needs to append stuff to strings, but the standard way
> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
> A variadic append() for std::string seems like the obvious solution.
> It could support string_view, integers, maybe floats
> but without formatting options..
> It could even be extensible by calling append(s, t);
>
> append(s, "A", "B", 42);
>
> Would this be useful for the C++ std lib?
>
So I wrote some trivial functions and IMO it works nicely. The
implementation of append might not be as smart as it could be but it's good
enough for me and I really like the interface.
inline std::string& operator<<(std::string& a, std::string_view b)
{
return a += b;
}
inline std::string& operator<<(std::string& a, long long b)
{
return a += std::to_string(b);
}
inline void append(std::string&)
{
}
template<class T, class... A>
void append(std::string& s, const T& v, const A&... a)
{
s << v;
append(s, a...);
}
template<class... A>
std::string concat(const A&... a)
{
std::string s;
append(s, a...);
return s;
}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3ce32531-babd-49d9-9607-cabd5a229df4%40isocpp.org.
------=_Part_1269_1156431917.1497684606324
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Op woensdag 28 december 2016 09:50:40 UTC+1 schreef Olaf v=
an der Spek:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
span style=3D"font-family:arial,sans-serif;font-size:12.8px">Hi,</span><br =
style=3D"font-family:arial,sans-serif;font-size:12.8px"><br style=3D"font-f=
amily:arial,sans-serif;font-size:12.8px"><span style=3D"font-family:arial,s=
ans-serif;font-size:12.8px">One frequently needs to append stuff to strings=
, but the standard way</span><br style=3D"font-family:arial,sans-serif;font=
-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px"=
>(s +=3D "A" + "B" + to_string(42)) isn't optimal d=
ue to temporaries.</span><br style=3D"font-family:arial,sans-serif;font-siz=
e:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">A v=
ariadic append() for std::string seems like the obvious solution.</span><br=
style=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"fon=
t-family:arial,sans-serif;font-size:12.8px">It could support string_view, i=
ntegers, maybe floats</span><br style=3D"font-family:arial,sans-serif;font-=
size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">=
but without formatting options..</span><br style=3D"font-family:arial,sans-=
serif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-si=
ze:12.8px">It could even be extensible by calling append(s, t);</span><br s=
tyle=3D"font-family:arial,sans-serif;font-size:12.8px"><br style=3D"font-fa=
mily:arial,sans-serif;font-size:12.8px"><span style=3D"font-family:arial,sa=
ns-serif;font-size:12.8px">append(s, "A", "B", 42);</sp=
an><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><br style=3D=
"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-family:=
arial,sans-serif;font-size:12.8px">Would this be useful for the C++ std lib=
?</span></div></blockquote><div><br></div><div>So I wrote some trivial func=
tions and IMO it works nicely. The implementation of append might not be as=
smart as it could be but it's good enough for me and I really like the=
interface.</div><div><br></div><div>inline std::string& operator<&l=
t;(std::string& a, std::string_view b)</div><div>{</div><div><span styl=
e=3D"white-space:pre"> </span>return a +=3D b;</div><div>}</div><div><br></=
div><div>inline std::string& operator<<(std::string& a, long =
long b)</div><div>{</div><div><span style=3D"white-space:pre"> </span>retur=
n a +=3D std::to_string(b);</div><div>}</div><div><br></div><div>inline voi=
d append(std::string&)</div><div>{</div><div>}</div><div><br></div><div=
>template<class T, class... A></div><div>void append(std::string&=
s, const T& v, const A&... a)</div><div>{</div><div><span style=3D=
"white-space:pre"> </span>s << v;</div><div><span style=3D"white-spac=
e:pre"> </span>append(s, a...);</div><div>}</div><div><br></div><div>templa=
te<class... A></div><div>std::string concat(const A&... a)</div><=
div>{</div><div><span style=3D"white-space:pre"> </span>std::string s;</div=
><div><span style=3D"white-space:pre"> </span>append(s, a...);</div><div><s=
pan style=3D"white-space:pre"> </span>return s;</div><div>}</div><div><br><=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3ce32531-babd-49d9-9607-cabd5a229df4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3ce32531-babd-49d9-9607-cabd5a229df4=
%40isocpp.org</a>.<br />
------=_Part_1269_1156431917.1497684606324--
------=_Part_1268_1837129130.1497684606323--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 17 Jun 2017 18:42:10 -0400
Raw View
--f403045f5836cdce3005522f9c52
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 14, 2017 at 9:31 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On s=C3=A1bado, 14 de janeiro de 2017 14:33:01 PST gmisocpp@gmail.com wro=
te:
> > I was just in the process of replying to say that decoupling formatting
> > from string would be great. And that seems to do that.
> > I didn't see exactly how it's used but it seems (but I'm sure someone
> will
> > correct me here) it would be nice if this worked:
> >
> > std::vector v;
> > So fmt(v. "whatever");
>
> Sorry, but.. why?
>
> Why can't you just use std::string? Why does it need to be something
> different?
>
I might want to format into a QString? Without the copy in between?
>
> The formatting code is likely to be big, so it's most likely not going to
> be
> inline. Therefore, it can't be templated.
>
>
I agree there might be trade offs that need to be weighed.
I don't think we really know what they will be yet.
--=20
Be seeing you,
Tony
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOHCbitrot%3Dkin8LA_h97ATwuaKaMMLebSywjYpYiySF1=
-Jc5Q%40mail.gmail.com.
--f403045f5836cdce3005522f9c52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jan 14, 2017 at 9:31 PM, Thiago Macieira <span dir=3D"ltr"><=
<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
On s=C3=A1bado, 14 de janeiro de 2017 14:33:01 PST <a href=3D"mailto:gmisoc=
pp@gmail.com">gmisocpp@gmail.com</a> wrote:<br>
> I was just in the process of replying to say that decoupling formattin=
g<br>
> from string would be great. And that seems to do that.<br>
> I didn't see exactly how it's used but it seems (but I'm s=
ure someone will<br>
> correct me here) it would be nice if this worked:<br>
><br>
> std::vector v;<br>
> So fmt(v. "whatever");<br>
<br>
</span>Sorry, but.. why?<br>
<br>
Why can't you just use std::string? Why does it need to be something<br=
>
different?<br></blockquote><div><br></div><div>I might want to format into =
a QString?=C2=A0 Without the copy in between?</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>
The formatting code is likely to be big, so it's most likely not going =
to be<br>
inline. Therefore, it can't be templated.<br>
<span class=3D""><br></span></blockquote><div><br></div><div>I agree there =
might be trade offs that need to be weighed.</div><div>I don't think we=
really know what they will be yet.</div><div>=C2=A0<br></div></div>-- <br>=
<div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitrot%3Dkin8LA_h97ATwuaKaMMLebS=
ywjYpYiySF1-Jc5Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitrot%3Dk=
in8LA_h97ATwuaKaMMLebSywjYpYiySF1-Jc5Q%40mail.gmail.com</a>.<br />
--f403045f5836cdce3005522f9c52--
.