Если у вас появились ошибки при округлении преобразовании double в QString, то обратите внимание на наш опыт:
Пример из практики:
Есть допустим такое число 20455.869999999999 - так показывается в отладчике. Но qDebug() его выводит странным образом, а именно:
20455.9 и вы думаете - кто-то бредит...
И дело не локали (QLocale) или еще в каких-то глобальных настройках.
ba = QByteArray::number(value, 'g' ); // ! так не делай, т.к. будет 20455.9
ba = QByteArray::number(value, 'f' ); // 20455.870000Обратите внимание чем отличается использование 'f' от 'g'. Это важно.
Чтобы не терять данные, конечно надо использовать 'f' вариант. Ибо при варианте 'g' только 6 цифр у вас останется (считая слева , т.е. сначала).
Еще для примера несколько других вариантов, но уже через QString (хотя с QByteArray одно и тоже):
QString::number( 20455.87 , 'g' , 2 ) "20455.9"
QString::number( 20455.87 , 'g' , 4 ) "2.046e+04"
QString::number( 20455.87 , 'g' , 6 ) "2e+04"
QString::number( 20455.87 , 'f' , 3 ) "20455.870"
QString::number( 20455.87 , 'f' , 4 ) "20455.8700"
QString::number( 20455.87 , 'f' , 2 ) "20455.87"
QString::number( 20455.87 , 'f' , 4 ) "20455.8700"
QString::number( 20455.87 , 'f' ) "20455.870000"'g' вариант вообще выдает при больших значениях экспоненциальное представление, а оно вам надо?...
Зато 'f' вариант без указания количества знаков после запятой (у нас точки) - выдает максимально полный вариант без потерь данных. А дальше лишние нули после точки в самом конце можно убрать.
