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

M>А теперь вопрос , это кому в голову опять приходит мысль использовать вместо специализированных парсеров свои велосипеды на std::string, std::stringstream?

Я чесно пытался понять, что здесь написано, но не понял. Поэтому хочу задать уточняющий вопрос: в случаях парсинга больших объемов текстовых файлов или серверов под высокой нагрузкой что нужно использовать? boost::lexical_cast, специализированные парсеры, собственные велосипеды на основе std::string*, собственные велосипеды не на основе std::string* или что-то еще?

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

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

M>>А теперь вопрос , это кому в голову опять приходит мысль использовать вместо специализированных парсеров свои велосипеды на std::string, std::stringstream?

E>Я чесно пытался понять, что здесь написано, но не понял. Поэтому хочу задать уточняющий вопрос: в случаях парсинга больших объемов текстовых файлов или серверов под высокой нагрузкой что нужно использовать? boost::lexical_cast, специализированные парсеры, собственные велосипеды на основе std::string*, собственные велосипеды не на основе std::string* или что-то еще?

Для меня выбор очевиден , а вы подумайте. Судя по вашемк предыдущему посту, вы предпочитаете "собственные велосипеды на основе std::string"

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

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

M>>А теперь вопрос , это кому в голову опять приходит мысль использовать вместо специализированных парсеров свои велосипеды на std::string, std::stringstream?

E>Я чесно пытался понять, что здесь написано, но не понял. Поэтому хочу задать уточняющий вопрос: в случаях парсинга больших объемов текстовых файлов или серверов под высокой нагрузкой что нужно использовать? boost::lexical_cast, специализированные парсеры, собственные велосипеды на основе std::string*, собственные велосипеды не на основе std::string* или что-то еще?

Вообще, для полного счастья достаточно было-бы иметь пару функций для парзинга чисел. Одна должна работать с парой итераторов Begin,End
вторая с одним итератором и нулем в качестве терминатора. На базе этого можно уже строить все, что угодно. Хоть lexical_cast, хоть специализированные парзеры. Именно так должны строится нормальные библиотеки: в основе низкоуровневые универсальные вещи, сверху удобные оболочки аля lexical_cast iostream и т.п.

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

M>А теперь вопрос , это кому в голову опять приходит мысль использовать вместо специализированных парсеров свои велосипеды на std::string, std::stringstream?
Приведи пример "специализированных парсеров" для использования в "парсере больших текстов или в неком сервере под нагрузкой с большим к-вом запросов" плз.

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

M>>>А теперь вопрос , это кому в голову опять приходит мысль использовать вместо специализированных парсеров свои велосипеды на std::string, std::stringstream?

E>>Я чесно пытался понять, что здесь написано, но не понял. Поэтому хочу задать уточняющий вопрос: в случаях парсинга больших объемов текстовых файлов или серверов под высокой нагрузкой что нужно использовать? boost::lexical_cast, специализированные парсеры, собственные велосипеды на основе std::string*, собственные велосипеды не на основе std::string* или что-то еще?

M>Для меня выбор очевиден , а вы подумайте. Судя по вашемк предыдущему посту, вы предпочитаете "собственные велосипеды на основе std::string"

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

Что касается выбора того или другого инструмента, то его хорошо делать, когда параметры задачи определены изначально. Если же разработка начинается с одних требований, а через несколько лет успешной эксплуатации нагрузка возрастает до объемов в 1000 раз больших первоначально запланированных, то ситуация сильно меняется. Например, логирование, в котором для форматирования некоторых объектов применяется lexical_cast, приходится менять на более специализированные вещи. API, в котором параметры принимались через const std::string & приходится заменять на const StringPiece &. Выбрасывать возврат значений по std::auto_ptr (который был сделан из-за соображений безопасности исключений). Отказываться от piml для некоторых объектов. Заменять std::set с 20-30 значениями на std::vector и std::lower_bound. И т.д.

И если при первоначальной разработке описанные выше вещи применялись для того, чтобы быстро получить корректную реализацию, то с течением времени просто корректной реализации становиться мало.

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

L>по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN"
L>да и экспоненциальная нотация, имхо, хороша только для научных работников и соответствующего им софта
что на выходе из crt то у нее и на входе Это может быть не пользователь, а текстовый формат и поддержка НАН логична (на входе понимается +-НАН). CRT писал по моему еще К и Р и стех пор она только подправляется слегка.

За локаль поубивать мало
если документ двуязычный то писать 100,01 rub и 100.01 руб ? что делать если у компа одна локаль а у сервера другая? или пользователь должен знать какая десятичная точка в каком случае?
И как все это отлаживать?

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

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

K>>

K>>int num_parse
K>>

мдаа... -1 за int
Kluev, поставь мне тоже

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

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

K>>>

K>>>int num_parse
K>>>

anc>мдаа... -1 за int
anc>Kluev, поставь мне тоже

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

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


K>суть претензий сначала обьясни.

тип возврата num_parse() int?

туплю

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

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

E>>Здравствуйте, Kluev

E>>Складывается впечатление, что возражающим Kluev-у товарищам, вероятно, никогда не приходилось выбрасывать из программы вещи типа std::string, std::stringstream и std::set/map после работы с профайлером.

PD>Мне не приходилось. Я их к своим программам, когда изначально известно, что нужна скорость, близко не подпускаю


Обычно процентах в 80% то мест всё равно можно оставить stl.
Хотя я вот совсем недавно столкнулся с такой фигней. std::vector. Постоянно приходится получать размер. А у msvc'шного вектора размер реализован как ((end — begin) / sizeof element_t). Вычитание-то — фиг с ним, но там деление! Если размер элемента равен 2^N, то всё замечательно — там будет сдвиг вправо. Но у меня размер элемента получился 24. Компилятор заменил деление на умножение, т.к. размер делитель известен во время компиляции. Но всё равно мало приятного. Пришлось pad'дить структуру до 32. Но это ещё допереть надо, что там такая засада. Уж казалось бы, что простые операции над вектором должны быть максимально эффективными — ну там косвенные обращения, сложения/вычитания и т.д. Ан нет.

Или вот ещё засада с rand():
http://www.rsdn.ru/forum/message/2985806.1.aspx

Автор: remark
Дата: 12.06.08

Оказывается он там внутрях использует 64-битные умножения и деления, в итоге программа больше трети времени проводила в этих операциях.


Но тем самым не говорю, что std::vector, rand() и boost "вон из профессии". Это замечательные вещи для *общего случая*. А для каждой конкретной ситуации, конечно, можно сделать более быстро.

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

R>Но тем самым не говорю, что std::vector, rand() и boost "вон из профессии". Это замечательные вещи для *общего случая*. А для каждой конкретной ситуации, конечно, можно сделать более быстро.

для *общего случая* есть языки попроще С++

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

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

R>>Но тем самым не говорю, что std::vector, rand() и boost "вон из профессии". Это замечательные вещи для *общего случая*. А для каждой конкретной ситуации, конечно, можно сделать более быстро.

K>для *общего случая* есть языки попроще С++

Но в языке попроще С++ ты, когда это понадобится, не сможешь реализовать частный случай.
А С++ + STL + boost дают уникальную комбинацию: ты с одной стороны можешь очень быстро разрабатывать, а с другой — любой аспект программы ты всегда можешь реализовать "для частного случая".
Просто не надо для заведомо требовательного к производительности кода использовать заведомо неоптимальные средства... хотя тоже можно, просто потом больше работы.

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

P>поддержка НАН логична
NaN это сигнализация об ошибке в вычислениях. Выводить ее еще понятно зачем. Но на кой ее поддерживать для ввода?

P>+-НАН
Нет такого кадавра в стандарте IEEE

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

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

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

R>>>Но тем самым не говорю, что std::vector, rand() и boost "вон из профессии". Это замечательные вещи для *общего случая*. А для каждой конкретной ситуации, конечно, можно сделать более быстро.

K>>для *общего случая* есть языки попроще С++

R>Но в языке попроще С++ ты, когда это понадобится, не сможешь реализовать частный случай.
R>А С++ + STL + boost дают уникальную комбинацию: ты с одной стороны можешь очень быстро разрабатывать, а с другой — любой аспект программы ты всегда можешь реализовать "для частного случая".

так программировать себе дороже. лучше сразу использовать эффективные хорошо масштабируемые вещи.
а boost и stl они скорее деффективные чем эффективные:
xml парзер на spirit
malloc/free в lexical_cast<double>(string);
vector<shared_ptr<>>
и т.д и т.п.

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

K>>>для *общего случая* есть языки попроще С++

R>>Но в языке попроще С++ ты, когда это понадобится, не сможешь реализовать частный случай.
R>>А С++ + STL + boost дают уникальную комбинацию: ты с одной стороны можешь очень быстро разрабатывать, а с другой — любой аспект программы ты всегда можешь реализовать "для частного случая".

K>так программировать себе дороже. лучше сразу использовать эффективные хорошо масштабируемые вещи.
K>а boost и stl они скорее деффективные чем эффективные:
K>xml парзер на spirit
K>malloc/free в lexical_cast<double>(string);
K>vector<shared_ptr<>>
K>и т.д и т.п.


Допустим надо реализовать код загрузки конфигурационного файла при старте сервера. Конфигурационный файл включает и XML и числа с плавающей запятой.
Ты предлагаешь писать какой-то кастомный код под это дело. Правильно? Да ещё код эффективный и хорошо масштабируемый. Правильно?
При этом надо добиться предела совершенства. Т.е. несколько месяцев искать/разрабатывать базовые алгоритмы и структуры данных. Потом математически доказывать их оптимальность. Потом реализовывать это всё на ассемблере под каждую модель процессора, под каждую ОС и компилятор.
Так?
Если нет, то как определить сколько эффективности и масштабируемости достаточно для парсинга конфигурационного файла при старте сервера? Сколько времени я должен провести с профайлером, что определить, что код готов?

Я бы написал это код на boost.spirit и потратил бы... ну примерно 20 минут. Да, мой сервер стартовал бы 200 мкс, в отличие от твоего, который бы стртовал 7.5 мкс. Но у тебя бы только на считывание файла ушло бы... ну месяца 2...

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

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

K>>>>для *общего случая* есть языки попроще С++

R>>>Но в языке попроще С++ ты, когда это понадобится, не сможешь реализовать частный случай.
R>>>А С++ + STL + boost дают уникальную комбинацию: ты с одной стороны можешь очень быстро разрабатывать, а с другой — любой аспект программы ты всегда можешь реализовать "для частного случая".

K>>так программировать себе дороже. лучше сразу использовать эффективные хорошо масштабируемые вещи.
K>>а boost и stl они скорее деффективные чем эффективные:
K>>xml парзер на spirit
K>>malloc/free в lexical_cast<double>(string);
K>>vector<shared_ptr<>>
K>>и т.д и т.п.

R>Я бы написал это код на boost.spirit и потратил бы... ну примерно 20 минут. Да, мой сервер стартовал бы 200 мкс, в отличие от твоего, который бы стртовал 7.5 мкс. Но у тебя бы только на считывание файла ушло бы... ну месяца 2...

это не совсем правильный пример. хмл парзер для конфига — это локальный относительно легко заменяемый компонент.
можно взять TiXml или что-то другое, предаврительно потестив производительность, если нужно.
Другое дело когда по всей программе используется vector<shared_ptr<>> или что-то подобное, а число обьектов внезапно начинает зашкаливать. Такие вещи иногда проще с нуля переписать чем до ума довести.
Я, например, в качестве основного контейнера использую интрузивный список и вся оптимизация если нужно сводится к переопределению new и выделению памяти через самописный пул. Т.е. гарантия масштабируемости обеспечена с самого начала разработки.

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

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

P>>поддержка НАН логична
CC>NaN это сигнализация об ошибке в вычислениях. Выводить ее еще понятно зачем. Но на кой ее поддерживать для ввода?
для ввода текстовых файлов выведенных другой программой

P>>+-НАН
CC>Нет такого кадавра в стандарте IEEE
не знаю как в стандарте но по факту знаковый бит никуда не девается и выводится +Nan и -Nan Вводится исключительно Nan со знаком
scanf printf

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

R>>Я бы написал это код на boost.spirit и потратил бы... ну примерно 20 минут. Да, мой сервер стартовал бы 200 мкс, в отличие от твоего, который бы стртовал 7.5 мкс. Но у тебя бы только на считывание файла ушло бы... ну месяца 2...

K>это не совсем правильный пример. хмл парзер для конфига — это локальный относительно легко заменяемый компонент.
K>можно взять TiXml или что-то другое, предаврительно потестив производительность, если нужно.
K>Другое дело когда по всей программе используется vector<shared_ptr<>> или что-то подобное, а число обьектов внезапно начинает зашкаливать. Такие вещи иногда проще с нуля переписать чем до ума довести.


И какое отношение это всё имеет к "boost — вон из профессии"?
Я не вижу логической связи между "не нужно по *всей* программе использовать vector<shared_ptr<>>" и "не нужно использовать boost *вообще*".
В программе всегда есть запуск, остановка, редко выполняемые действия и с ними может быть связано, к примеру, 2/3 всего кода приложения. И тут boost и stl — это замечательнейшие вещи.


K>Я, например, в качестве основного контейнера использую интрузивный список и вся оптимизация если нужно сводится к переопределению new и выделению памяти через самописный пул. Т.е. гарантия масштабируемости обеспечена с самого начала разработки.

LOL
Списки — это во многих случаях очень сильно не оптимальная структура. Она может работать в 10 раз медленнее std::vector на переборе элементов. О поиске и говорить нечего. Повсеместное применение интрузивных списков — это паттерн С-программиста 15-летней давности. Тогда это действительно было очень хорошее решение.
Причины:
1. Переход по указателям. Эффективно не поддерживается современным аппаратным обеспечением. Программы активно оперирующие указателями сейчас работают, допустим, с CPI=2, вместо максимальных CPI=0.3
2. Не локальные обращения к памяти. Эффективно не поддерживается современным аппаратным обеспечением. Могут замедлять работу программы до 10 раз.
3. Увеличение потребления памяти. С каждым узлом надо хранить 2 указателя (что бы хоть как-то выгодно отличаться от массива нам нужны двух-связанные списки). Если взять предельный случай: храним один char (1 байт) + 2 указателя (на 64-битной машине = 16 байт) = 94% места под вспомогательные данные. Помимо увеличенного потребления памяти, как следствие, это может привести к тому, что workset программы перестанет влезать в кэш какого-то уровня.
4. Нет возможности прямой индексации. Соотв. бинарный поиск отпадает, только последовательный.

Сейчас все эксперты дают обратный совет: vector — структура по-умолчанию, пока нет прямых указаний использовать что-то другое.
Вот видишь, а ты говоришь boost...

з.ы. кстати в boost есть интрузивные списки (а так же двух-связанные списки, бинарные деревья, хэш-таблицы, красно-черные деревья, AVL деревья и др.), и аллокаторы типа pool и region там тоже есть.

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

_>Здравствуйте, Kluev, Вы писали:
_>Сделайте что-то такое же удобное, и безопасное
насчет удобства ИМХО через операторы удобней

#include <iostream>
struct Lexical_cast
{  char *v;
   Lexical_cast(char *v):v(v){}
   operator int    () {return 1;}
   operator float  () {return 2;}
   operator double () {return 3;}
};
int main()
{
    int a=Lexical_cast("");
    float b=Lexical_cast("");
    std::cout << "Hello, world!" << a <<" "<< b<<" "<<(double)Lexical_cast("")<<std::endl;
    return 0;
}

здесь проверил как работает