Здравствуйте, landerhigh, Вы писали:

L>Видимо, нет. Но код возврата функции навевает на мысли, что парсим целое число. И лишь внимательное рассмотрение сигнатуры показывает, что это не так.
Ну хотя бы семантику функции стоит таки выяснить, IMHO. Вот уж к прототипу функци претензии совсем не понятны...

L>>>2. Неясно, что будет, если разделитель — запятая.
E>>Ошибка формата будет. Тоже вроде как ясно...
L>А если надо пофискить?
А в какой форме ты бы хотел фиксить? Это таки аналог рантаймовской функции...

L>>>5. Что за сравнение с 'E' и 'D' в середине?
E>>Экспоненциальная запись числа, вестимо (что-то типа 1.17e-8)
L>Если юзер вдруг пробел между e и -8 ввел, что будет? Из кода совершенно не понятно.
Странно. Мне понятно.
Там же код устроен так, что каждая часть числа начинается с метки. И когда мы находим конец или не находим начало очередной части, то переходим на следующую.
Каждая часть разбирается очень просто. Либо просто смотрят на конкретные символы, либо крутят какой-то цикл по символам. Например, пропускают пробелы, или накапливают целую или дробную часть числа...
Я так и не понял, что за проблемы с чтением или модификацией этой функции?

L>Вопрос в том, скольких усилий будет стоить адаптация функции?
Ну дык ты пока что не пояснил что значит "адаптация". Написать аналог на wchar_t? -- Нисколько не будет стоить. Пишешь копию, где вместо char* используешь wcahr_t*, а перед всеми символьными литералами приписываешь L и всё...

L>>>Это не говоря о кошмарном форматировании и диковато выглядящей сигнатуре функции.
E>>Просто C-style. Если думаешь, что в crt как-то не так, советую почитать
L>CRT вместе с C-style трудно назвать образцами юзабилити и читаемости.
Мы вроде о КАЧЕСТВЕ кода говорили, а не о юзабилити?

В чём проблемы с читабельностью, что в известных мне рантаймах, что в этом коде я так и не понял. И в рантаймах и в этой функции я легко разобрался. Чего не скажешь о многих известных мне образцах "качественного" кода