faure at kde.org
Mon May 2 12:35:38 BST 2005
On Monday 02 May 2005 13:22, Klaus Niederkrueger wrote:
> Somehow I think the way it has been coded is strange: The above function
> just calls
> return formatNumber(numStr.toDouble());
> where in "formatNumber(double num, int prec)", the double is converted
> back to a string
Yes, well nothing strange there since the QString one is deprecated :)
(but shouldn't that conversion use 'g' instead of 'f', since it's a double and not a float?)
> The problem is
> that kcalc uses "long long double" to handle numbers internally, which
> does not work correctly with "Klocale". By having "formatNumber(QString)"
> working on arbitrarily long QStrings, I could delete a part of the
Ah, and formatNumber(QString) wouldn't use QString::number() at all, right?
And if it's formatNumber(QString num, int prec) you would handle the precision
by doing a string manipulation directly. OK, then it makes sense. Only small problem,
for the formatNumber(double) case, the precision-handling would sort of happen
twice (once in the QString::number call, and once in the formatNumber(QString)
> My first question is: Is it o.k. if I change this?
I think so, but it would probably be a good idea to post a full patch here first :)
> If yes, my second question: "formatNumber(double, int)" has two arguments,
> whereas "formatNumber(QString)" only has one. If I change the second
> function to "formatNumber(QString num, int prec = -1)" is this still
> binary compatible with the old code?
No. You'll have to add a formatNumber(const QString& num, int prec) and make
formatNumber(const QString& num) call formatNumber(num,-1). Add a comment
about merging the two in KDE4.
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel