From kde-core-devel Sun Oct 30 18:45:26 2005 From: Ingo =?iso-8859-15?q?Kl=F6cker?= Date: Sun, 30 Oct 2005 18:45:26 +0000 To: kde-core-devel Subject: Re: New i18n interface for KDE 4, second try Message-Id: <200510301945.37244 () erwin ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=113069796529414 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2010769.87C53aZWsH" --nextPart2010769.87C53aZWsH Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 30 October 2005 18:19, Chusslove Illich wrote: > > [: Ingo Kl=F6cker :] > > I wonder whether we really need such a complicated solution for > > multiple arguments. I'm a bit concerned about the performance > > penalty that's caused by this complicated construction. > > Performance is really not an issue here, as we're talking about GUI > stuff. > > Anyway, if you'd really want to know, this particular thing (simple > message, three placeholders, all QString arguments: the worst case) > slow current code down about twice, but still delivering over 200,000 > messages per second on my 1.67 GHz. And if I make all tree arguments > ints, than it is only factor 1.3 slower. In general, any further > complication (like plurals, context, future enhancements) will only > narrow this gap of few indirections. > > > Therefore at least for me, in the multiple argument case, something > > like i18n( const char *text, const QString & a1, const QString & > > a2, const QString & a3 ) > > would suffice because currently for using QString::arg( a1, a2, a3 > > ) we already need to convert numbers to QString ourselves. > > But if you don't have to, why not allow for that (performance not > being the issue)? Thanks for checking the performance penalty. As far as I'm concerned,=20 please go ahead with your proposal. Regards, Ingo --nextPart2010769.87C53aZWsH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBDZRTRGnR+RTDgudgRAmoNAKCsw7B4ZSRzdnMBSxETobGoe2MhZgCfWdXs ykWq7AH4KrvMhBp5XwtlB3E= =28zt -----END PGP SIGNATURE----- --nextPart2010769.87C53aZWsH--