Здравствуйте, Kluev, Вы писали:
Z>>Ну и приведите пример универсального решения, которое будет эффективно делать то-же, что и lexical_cast. Не забывая, естественно про поддержку custom types. И вообще, прежде чем наезжать на буст, я бы посоветовал, скажем, заменит строчку "3.1415" на экспоненциальную нотацию или на "NAN" и посмотреть это схавает ваш хвалёный велосипед.
по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN"
да и экспоненциальная нотация, имхо, хороша только для научных работников и соответствующего им софта
Здравствуйте, Ligen, Вы писали:
L>по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN" L>да и экспоненциальная нотация, имхо, хороша только для научных работников и соответствующего им софта
Ой, сколько я повидал вырванного волосяного покрова из одного места, когда проектировали исходя из таких вот "редко", "наверное" и "кажется", а на деле оказывалось, что вовсе не редко и именно что кажется.
Здравствуйте, Kluev, Вы писали: K>lexical_cast не универсален. например понадобится конвертнуть строку с парой чисел разделенных запятыми. lexical_cast — облом, iostream — облом. K>а старые добрые strtod/strtol вполне подойдут (их только нелепый strlen внутри портит).
K>по настоящему универсальным решением было бы семейство "низкоуровневых" перегруженных функций для разбора чисел + шаблонная обертка вокруг.
K>
Фу, с char* сам работай в С++ коде, а я не мазохист
"To protect people you must slay people. To let people live you must let people die. This is the true teaching of the sword."
-Seijuro Hiko, "Rurouni Kensin"
Может это заговор с производителями памяти и процессоров ? Может специально делают такие медленные библимотеки ? Чтобы потом было чем грузить процессор?
P.S. Флаги бы компиляции привел, чтоль ... компилятор версию.
А по делу , документацию читать не пробовали ? говорят может помочь ...
Здравствуйте, Kluev, Вы писали:
K>решил сделать небольшой тест. померял скорость работы boost::lexical_cast, strtod и своего велосипеда. K>велосипед мне пришлось написать т.к. strtod внутри вызывает strlen и производительность сильно падает на длинных строках.
K>результаты, сек K>
K>bicycle: 0.135
K>crt:: 0.682 (в 5 раз медленнее)
K>boost: 6.289 (в 46.5 раз медленнее велосипеда и в 10 раз медленнее crt)
K>
(bicycle implementation was not found in the original post )
Если взглянуть на профайл, что я боюсь, тебе сделать не удалось (по причине либо отсутствия профайлера, либо неумения им пользоваться), то видно, что это очередной micro-benchmark, который ничего не значит. Кстати lexical_cast'а в профайле вообще не видно (оптимизация, понимаешь!).
Чтобы удобнее было смотреть, скопируй профайл в .csv файл и открой в Excel'е.
Где здесь что: 5-6 строки — это явный вызов crt strtod, строки 27-28 — вызов strtod из lexical_cast. Производительность lexical_cast определяется полностью выбором basic_istream для преобразования строки в число. Кстати, istream, будучи более общим решением, выбросит исключение, если ему дать не число. А crt ничего не сделает, и будет делать вид, что все нормально. Так что по функциональности эти два подхода не эквивалентны.
Что указывает на то, что это micro-benchmark: начинают выделяться всякие левые вещи и функции, в которых никакой работы не происходит. Здесь это видно на примере Ios_base_dtor, locale::scalar deleting destructor, etc. В обычной программе такого расклада обычно не наблюдается, и соответственно, разницы между lexical_cast и прямым вызовом strtod не будет заметно. Соответственно вывод от сюда такой, что lexical_cast является удовлетворительным решением, пригодным для использования в большинстве случаев. lexical_cast не вносит дополнительного overhead'а по сравнению со стандартной C++-ной библиотекой ввода/вывода.
Конечно, если все что ты делаешь, это перевод миллиона строк в double, то тебе в любом случае нужно специализированное решение. Все существующие библиотечные решения будут медленнее, потому как они расчитаны на более или менее общий случай, а не на твой конкретный.
Здравствуйте, Kluev, Вы писали:
K>решил сделать небольшой тест. померял скорость работы boost::lexical_cast, strtod и своего велосипеда. K>велосипед мне пришлось написать т.к. strtod внутри вызывает strlen и производительность сильно падает на длинных строках.
K>результаты, сек K>
K>bicycle: 0.135
K>crt:: 0.682 (в 5 раз медленнее)
K>boost: 6.289 (в 46.5 раз медленнее велосипеда и в 10 раз медленнее crt)
K>
Здравствуйте, Ligen, Вы писали:
L>по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN"
Редко то редко, но когда софт упадет на загрузке файла "бабло.приход" из-за NAN ...
Re: boost - вон из профессии
От:
Аноним
Дата:
12.06.08 10:21
Оценка:
Здравствуйте, Kluev, Вы писали:
K>...
Если уж приходится парсить такие объемы данных, на которых становится заметной разница между lexical_cast и strtod, разумнее воспользоваться специализированным решением, написать парсер что ли.
Здравствуйте, alnsn, Вы писали:
A>>Попробуй еще BOOST_LEXICAL_CAST_ASSUME_C_LOCALE. A>Поторопился я с ответом, это не работает для чисел с плавающей точкой. Их сложнее оптимизировать, чтобы никто разницы с ostream не заметил.
Здравствуйте, alnsn, Вы писали:
A>Редко то редко, но когда софт упадет на загрузке файла "бабло.приход" из-за NAN ...
NaN это Not a Number
Не число т.е.
Функция не должна его отрабатывать, а должна вернуть ошибку — мол, фигню подсунули.
Равно как и при попытке подсунуть "ksdhfiwnerxifwer" для преобразования.
В чем проблема то?
Или считаешь что отлов ошибочных данных имеет право делать только boost, а "велосипедная" функция этого уметь не может по определению?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Kluev, Вы писали:
A>Если взглянуть на профайл, что я боюсь, тебе сделать не удалось (по причине либо отсутствия профайлера, либо неумения им пользоваться), то видно, что это очередной micro-benchmark, который ничего не значит. Кстати lexical_cast'а в профайле вообще не видно (оптимизация, понимаешь!).
Профайлер здесь и не нужен. Я посмотрел в исходники и обнаружил там быдлокодец вокруг iostream.
Кстати, в недрах этого чуда несколько раз вызывается new, поэтому производительность в реальных условиях будет еще сильно зависить от состояния кучи. А сам факт динамического выделения памяти для операции string -> number говорит о низкой культуре программирования у бустовских кодеров. Видимо на первом месте в бусте стоит "чистота концепций", а все остальные вопросы игнорируются.
Здравствуйте, CreatorCray, Вы писали: CC>NaN это Not a Number CC>Не число т.е. CC>Функция не должна его отрабатывать, а должна вернуть ошибку — мол, фигню подсунули. CC>Равно как и при попытке подсунуть "ksdhfiwnerxifwer" для преобразования.
Ну скажем не NAN, a INF. Хотя в каком-нибудь столбце вполне может стоит и NAN, и далеко не факт что это ошибка, и совершенно точно парсер от такого падать не должен.
CC>В чем проблема то? CC>Или считаешь что отлов ошибочных данных имеет право делать только boost, а "велосипедная" функция этого уметь не может по определению?
Проблема "велосипедных" функций, в том, что кроме автора (и то, далеко не всегда) не знает что там происходит. В стандартных библиотечных функций, как минимум можно знать чего ожидать, или во всяком случае куда обращаться. Я лично, как-то отыскивая источник memory corruption потратил неделю на чтения мемори дампов и кода, только чтоб обнаружить, что человек, давно в фирме не работающей, когда-то написал "простой" велосипед как-то там конвертирующий строки и числа, и который упал через несколько лет когда в первый раз в неё попала строка с какой-то экзотической локалью, вроде японского.
"To protect people you must slay people. To let people live you must let people die. This is the true teaching of the sword."
-Seijuro Hiko, "Rurouni Kensin"
Здравствуйте, Zigmar, Вы писали:
Z>Ну скажем не NAN, a INF. Хотя в каком-нибудь столбце вполне может стоит и NAN, и далеко не факт что это ошибка, и совершенно точно парсер от такого падать не должен.
А с чего вдруг ему падать? Откуда такая уверенность что самописное априори хуже библиотечного? Библиотеки по сути такое же сборище велосипедов, и все гарантии качества только на совести их разработчиков и тестеров.
Качество кода (велосипеда или буста или CRT или еще чего) определяется ровностью рук и качеством мозгов программера, их написавшего, и тестера их оттестировавшего.
Z>Проблема "велосипедных" функций, в том, что кроме автора (и то, далеко не всегда) не знает что там происходит.
Для этого есть документирование и комментарии.
Z> В стандартных библиотечных функций, как минимум можно знать чего ожидать, или во всяком случае куда обращаться.
Они ничуть не лучше нормально написанных, оттестированных и задокументированных "велосипедных" функций.
Z> Я лично, как-то отыскивая источник memory corruption потратил неделю на чтения мемори дампов и кода, только чтоб обнаружить, что человек, давно в фирме не работающей, когда-то написал "простой" велосипед как-то там конвертирующий строки и числа, и который упал через несколько лет когда в первый раз в неё попала строка с какой-то экзотической локалью, вроде японского.
Ну так товарищ сам дурак — писать надо нормально. С таким же успехом он мог накосячить в любом другом месте.
Зачем он кстати там писал свое преобразование? Причины на то были?
Если кто не понял — я про то веду речь, что нормально написанный "велосипед" может быть лучше библиотечных функций.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Zigmar, Вы писали:
CC>>В чем проблема то? CC>>Или считаешь что отлов ошибочных данных имеет право делать только boost, а "велосипедная" функция этого уметь не может по определению? Z>Проблема "велосипедных" функций, в том, что кроме автора (и то, далеко не всегда) не знает что там происходит. В стандартных библиотечных функций, как минимум можно знать чего ожидать, или во всяком случае куда обращаться. Я лично, как-то отыскивая источник memory corruption потратил неделю на чтения мемори дампов и кода, только чтоб обнаружить, что человек, давно в фирме не работающей, когда-то написал "простой" велосипед как-то там конвертирующий строки и числа, и который упал через несколько лет когда в первый раз в неё попала строка с какой-то экзотической локалью, вроде японского.
Из этого не следует, что все велосипеды г-но, а буст хороший. Я прошелся дебаггером по lexical_cast и обнаружил, что качество кода в нем очень низкое. Даже если он одобрен миллионом слепых глаз суть от этого не меняется.
Качество кода определяется самим кодом, а не тем он входит ли он в буст или из доморощенного велосипеда.
CreatorCray wrote:
> Качество кода (велосипеда или буста или CRT или еще чего) определяется > ровностью рук и качеством мозгов программера, их написавшего, и тестера > их оттестировавшего.
Просто обычно у стандартных библиотек гораздо больше тестеров и возможных вариантов использования.
А вообще говоря странно, что тут решили бабло парсить в плавучку.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай