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

L>>>>2. Неясно, что будет, если разделитель — запятая.
E>>>Ошибка формата будет. Тоже вроде как ясно...
L>>А если надо пофискить?
E>А в какой форме ты бы хотел фиксить? Это таки аналог рантаймовской функции...
Как в какой? Пусть правильно обрабатывает как запятую, так и точку.
L>>Если юзер вдруг пробел между e и -8 ввел, что будет? Из кода совершенно не понятно.
E>Странно. Мне понятно.
Что, прям так сразу и с наскока? Мне этого вот так сразу и не видно. Если, конечно, есть юнит-тест, то можно и не смотреть, с другой стороны.
E>Там же код устроен так, что каждая часть числа начинается с метки. И когда мы находим конец или не находим начало очередной части, то переходим на следующую.
E>Каждая часть разбирается очень просто. Либо просто смотрят на конкретные символы, либо крутят какой-то цикл по символам. Например, пропускают пробелы, или накапливают целую или дробную часть числа...
E>Я так и не понял, что за проблемы с чтением или модификацией этой функции?
Этот код non-maintainable. Очень страшная реализация конечного автомата. Это я еще к форматированию придираться не начал
L>>Вопрос в том, скольких усилий будет стоить адаптация функции?
E>Ну дык ты пока что не пояснил что значит "адаптация". Написать аналог на wchar_t? -- Нисколько не будет стоить. Пишешь копию, где вместо char* используешь wcahr_t*, а перед всеми символьными литералами приписываешь L и всё...
Копи-пейст, стало быть? Ну-ну.
L>>>>Это не говоря о кошмарном форматировании и диковато выглядящей сигнатуре функции.
E>>>Просто C-style. Если думаешь, что в crt как-то не так, советую почитать
L>>CRT вместе с C-style трудно назвать образцами юзабилити и читаемости.
E>Мы вроде о КАЧЕСТВЕ кода говорили, а не о юзабилити?
Мы уже вроде договорились, что качество кода тут, мягко говоря, не на высоте.

Это не говоря о том, что все это выглядит как попытка сделать ядреную пушку, чтобы по комарам стрелять.
Что толку от офигенно быстрого парсера, если 99% времени программа висит на select(), например?