--nextPart41905915.4XH7qBRFeR
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>> [: Chusslove Illich :]
>> QString("%1 %1").arg("foo").arg("bar")
>>
>> results in "foo bar", while
>
> [: Nicolas Goutte :]>
> Ooh, I have not know this trap!

It is undefined behaviour as per Qt 3.3 docs, and no mention in Qt 4.0=20
docs. But rest assured, it is being used with precisely this intention;=20
check message containing "Welcome to Kontact" in=20
kdepim/kontact/src/mainwindow.cpp of branch 3.5. And someone also wanted=20
it the other (proper?) way around, so he had to use a workaround, check in=
=20
kmail/kmstartup.cpp message with comment containing "only replaces the=20
first occurrence" appended.

This template solution would get rid of such problems. And again,=20
programmers wouldn't have to remember to use multiple arg() instead of two=
=20
single arg() methods in situations which require that for safety.

So I wonder, is this enough to outweight the problem of mixing call names=20
(taking into account these can be discovered by code-checking scripts)?

> [: Nicolas Goutte :]
> [qarg()] is pretty much useless. If we go so far away from QString, we
> can directly use QString::number, which is static. (That would be
> better than to have QString-like arg functions but that do not work
> like QString::arg functions.)

I did mean that qarg() would behave same as corresponding arg() (ie. one=20
qarg() for every formatting arg() method). But, as I said, this is=20
completely orthogonal feature, shouldn't have even mentioned it at this=20
point :)

=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)

--nextPart41905915.4XH7qBRFeR
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDZQDKMSGXgigGr3ERApZNAJ4oqXZFxR+Nw7LhlcjxO7tWN7XAGwCgqyKQ
8iQQk5eJCmG5ynTZZnzjOsM=
=w60z
-----END PGP SIGNATURE-----

--nextPart41905915.4XH7qBRFeR--