Особенности функции atof Опции

[Tonal]

Ещё раз - для ввода пользователя десятичный разделитель зависит от локали. Если в локали прописано, что разделитель должен быть символ + значит его и нужно корректно обрабатывать.

У нас в стране с этим просто бардак, как и со всем остальным.
Но, по возможности, этот бардак нужно уменьшать - при отображении и выводе документов использовать то, что прописано (кстати Qt именно так и делает - посмотри QDoubleSpinBox например).
При вводе либо запрещать вводить другой, либо корректировать.
Для текстовых форматов - следовать спецификациям. Если спецификации нет или нои не точные - предоставлять возможность настройки.
При создании своих текстовых, читаемых пользователями форматов, учитывать и сохранять текущую локаль.

Это не в стране разруха а в головах. (с)

[niXman]

AD, Не подумал бы Спасибо, буду внимателен.

а по мне дак это чушь полная, т.к. в исходном коде программ десятичный разделитель всегда был точкой!

Абсолютно верно!

Но в связи с повсеместным распространением кривых программ, которые не учитывают локаль, сейчас часто используют и точку и запятую.

Я всегда, в независимости от локали, заменяю запятую на точку, до передачи функции.

Лично по мне, так я не считаю удобным то, что программисту приходится следить за тем, что поставлено: точка или запятая. Мне кажется, что надо бы было сделать функцию так, чтобы она понимала оба этих разделителя одновременно.

Опять верно!

[Tonal]

Программисту нужно следить за тем, чтобы было удобно пользоваться его программой.
А за тем, что удобно было программисту должна отвечать среда программирования: язык, библиотеки, IDE...

Представь, что строители начали строить дома ориентируясь только на то как ми удобно, мы бы жили в ямах и шалашиках из плит - это всяко проще "построить" чем возводить нормальный дом.

Сообщение отредактировал Tonal - 25.8.2008, 7:21

[AD]

Покопался в Qt-шных аналогах функции atof! Выяснилось, что функция ToDouble(bool* ok) тоже зависит от локали. Но есть отличия:
1) есть возможность увидеть ошибку быстрее, так как программисту предлагают после преобразования проверять значение ok
2) очень важное отличие - при установке такого формата setlocale(LC_ALL, 0) функция преобразует и строчку "1234,45" and "1234.45" в вещественное число 1234.45!

Так что, если используете библиотеку Qt есть такие советы:
1) Указывать в приложении напрямую setlocale()!
2) Использовать qt-шные средства преобразования в вещественные числа! Преобразование легче отследить и немного универсальнее!

P.S. Немцы молодцы!

 QLocale::setDefault(QLocale::C);
 d = QString( "1234,56" ).toDouble(&ok); // ok=false
 d = QString( "1234.56" ).toDouble(&ok); // ok=true, d = 1234.56

 QLocale::setDefault(QLocale::German);
 d = QString( "1234,56" ).toDouble(&ok); // ok=true, d = 1234.56
 d = QString( "1234.56" ).toDouble(&ok); // ok=true, d = 1234.56

Сообщение отредактировал AD - 26.8.2008, 11:38

[Litkevich Yuriy]

функция преобразует и строчку "1234,45" and "1234.45"

вообще я думаю так бы оно и должно бы быть, а отделять группы разрядов можно и сверху (апострофом)
Но америкосы используют для этого запятую.

[AD]

вообще я думаю так бы оно и должно бы быть, а отделять группы разрядов можно и сверху (апострофом)
Но америкосы используют для этого запятую.

Ну это уже локальные вещи. В крайних случаях при работе с такими заказчиками просто заранее обсуждать эти моменты!!! На примере Германии я уже показал, что я не один такой, который считает, что оба разделителя считать адекватными!

[Tonal]

И что ты с америкосовской записью будешь делать где тысячи запятой отделяются а десятые точкой?
Я же говорю - разделитель от локали зависит.

[AD]

И что ты с америкосовской записью будешь делать где тысячи запятой отделяются а десятые точкой?
Я же говорю - разделитель от локали зависит.

А кому вопрос?

Да и... я разве спорил с этим?

1) Указывать в приложении напрямую setlocale()!

[Andrew Selivanov]

А вот std::stringstream (#include <sstream>) как стандартный способ преобразования почему-то никто и не вспомнил...

[NordWest]

Не очень понял всех докладчиков. У меня такая проблема. На debian стоят такие локали:

LANG=ru_RU.KOI8-R
LC_CTYPE="ru_RU.KOI8-R"
LC_NUMERIC="ru_RU.KOI8-R"
LC_TIME="ru_RU.KOI8-R"
LC_COLLATE="ru_RU.KOI8-R"
LC_MONETARY="ru_RU.KOI8-R"
LC_MESSAGES="ru_RU.KOI8-R"
LC_PAPER="ru_RU.KOI8-R"
LC_NAME="ru_RU.KOI8-R"
LC_ADDRESS="ru_RU.KOI8-R"
LC_TELEPHONE="ru_RU.KOI8-R"
LC_MEASUREMENT="ru_RU.KOI8-R"
LC_IDENTIFICATION="ru_RU.KOI8-R"
LC_ALL=

В вычислениях везде точки и под виндой проблем не возникает. В линуксе же воспринимаются запятые, а у чисел точками отбрасывается дробная часть. Вот например код:

int main(int argc, char *argv[])
{
...
double d = atof(argv[3]);
...
}

Если в командной строке ввести 15.5, то d=15, а если 15,5 - 15.5. Причём qDebug() выдает точки.
Пишу вначале main команду setlocale(LC_ALL, 0); - результата тот же. С QLocale::setDefault(QLocale::C); - то же самое. Если считывать данные из файла - результат будет аналогичным. А мне нужно и локаль себе не портить системную и чтобы программа работала с точками.