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

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

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

Специализированные парсеры. В общем случае я бы посмотрел на универсальные парсеры начиная от бизона и заканчивая спиритом. В частных случаях , например XML я бы смотрел в сторону Xerses, и.т.п.

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


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

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

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

2. При обнаружении факта что логирование тормозит я бы подумал о 2х решениях.
а) сократить к-во логируемой информации.
б) отказаться от форматирования на этапе логирования , а писать исключительно бинарное компактное представление событий, и вынести форматирование лога в отдельное приложение.


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

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

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

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

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

Z>>Ну скажем не NAN, a INF. Хотя в каком-нибудь столбце вполне может стоит и NAN, и далеко не факт что это ошибка, и совершенно точно парсер от такого падать не должен.
CC>А с чего вдруг ему падать? Откуда такая уверенность что самописное априори хуже библиотечного? Библиотеки по сути такое же сборище велосипедов, и все гарантии качества только на совести их разработчиков и тестеров.
CC>Качество кода (велосипеда или буста или CRT или еще чего) определяется ровностью рук и качеством мозгов программера, их написавшего, и тестера их оттестировавшего.

Только вот у велосипедов обычно один тестер всего, иногда два, и тестируют они велосипед опять же в одном сценарии использования, иногда в двух.
А у библиотек их тысячи (и тестеров, и сценариев использования).
Вот и все.

You will always get what you always got
  If you always do  what you always did

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

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

Ты хочешь сказать, что никогда не сталкивался с тормозами при использовании, скажем, канонической вещи типа std::set<std::string> или std::map<std::string,std::string>?
Подсказка: чаще всего создание строки — это выделение памяти в хипе, есть только у тебя строки не настолько коротки, чтоб уместиться в short string optimization, если таковая наличествует в твоей STL.

Естественно, вначале ты пишешь программу с использованием этих удобных вещей, ибо писать с ними можно довольно быстро, но потом профилируешь — и меняешь на что-нть более быстродействующее.

You will always get what you always got
  If you always do  what you always did

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

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

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

J>Ты хочешь сказать, что никогда не сталкивался с тормозами при использовании, скажем, канонической вещи типа std::set<std::string> или std::map<std::string,std::string>?
J>Подсказка: чаще всего создание строки — это выделение памяти в хипе, есть только у тебя строки не настолько коротки, чтоб уместиться в short string optimization, если таковая наличествует в твоей STL.

Нет, не сталкивался ни разу.
Просто чувствую себя жалким неудачником , вот у всех тормозит , а у меня нет , слова какие то странные "это выделение памяти в хипе", "short string optimization" , зхачем мне знать устройство всей этой кухни?

"выделение памяти в хипе" это наверное что то страшное и противоестиественное ? Может я им не пользуюсь , я только std::string использую и не выделяю ничего , может ошибся дет опять ?

J>Естественно, вначале ты пишешь программу с использованием этих удобных вещей, ибо писать с ними можно довольно быстро, но потом профилируешь — и меняешь на что-нть более быстродействующее.

ЗюЫю Да это сарказм.

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

M>Нет, не сталкивался ни разу.
M>Просто чувствую себя жалким неудачником , вот у всех тормозит , а у меня нет , слова какие то странные "это выделение памяти в хипе", "short string optimization" , зхачем мне знать устройство всей этой кухни?

M>"выделение памяти в хипе" это наверное что то страшное и противоестиественное ? Может я им не пользуюсь , я только std::string использую и не выделяю ничего , может ошибся дет опять ?

M>ЗюЫю Да это сарказм.

Вижу, что сарказм, но вот смысл его от меня ускользает.
Ты чего сказать хотел-то?

You will always get what you always got
  If you always do  what you always did

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

M>2. При обнаружении факта что логирование тормозит я бы подумал о 2х решениях.
M> а) сократить к-во логируемой информации.
M> б) отказаться от форматирования на этапе логирования , а писать исключительно бинарное компактное представление событий, и вынести форматирование лога в отдельное приложение.

в корень надо смотреть. форматирование тормозит из-за динамического выделения памяти в std::string, iostream, lexical_cast и других "изделиях". в логах на основе vsnprintf/fprintf тормозов не наблюдается.

M>Я немного в замешательстве , у меня действительно в практике не было случаев когда была необходимость ускорять использование STL.
Какой смысл тогда вообще мучатся с С++?

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

да какой там микроскоп, как работает lexical_cast? создает класс наследный от iostream запихивает в него входной параметр и читает выходной. это обычный быдлокод со всеми вытекающими malloc/free последствиями. В рабочем коде накиданном на скорую руку такое еще приемлемо, а в библиотеках, имхо, качество кода должно быть на порядок выше.

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

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

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

J>Ты хочешь сказать, что никогда не сталкивался с тормозами при использовании, скажем, канонической вещи типа std::set<std::string> или std::map<std::string,std::string>?
J>Подсказка: чаще всего создание строки — это выделение памяти в хипе, есть только у тебя строки не настолько коротки, чтоб уместиться в short string optimization, если таковая наличествует в твоей STL.

J>Естественно, вначале ты пишешь программу с использованием этих удобных вещей, ибо писать с ними можно довольно быстро, но потом профилируешь — и меняешь на что-нть более быстродействующее.

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

J>std::string .... использованием этих удобных вещей
ага, из std::string удобство так и прет

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

J>Вижу, что сарказм, но вот смысл его от меня ускользает.
J>Ты чего сказать хотел-то?

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

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

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

M>>2. При обнаружении факта что логирование тормозит я бы подумал о 2х решениях.
M>> а) сократить к-во логируемой информации.
M>> б) отказаться от форматирования на этапе логирования , а писать исключительно бинарное компактное представление событий, и вынести форматирование лога в отдельное приложение.

K>в корень надо смотреть. форматирование тормозит из-за динамического выделения памяти в std::string, iostream, lexical_cast и других "изделиях". в логах на основе vsnprintf/fprintf тормозов не наблюдается.

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

Использование vsnprintf/fprintf СОВЕРШЕННО не сопоставимо с использование стандартных потоков ввода вывода по безопастности использования. Ты наверное думаешь что они были введены в язык для галочки ?



M>>Я немного в замешательстве , у меня действительно в практике не было случаев когда была необходимость ускорять использование STL.
K>Какой смысл тогда вообще мучатся с С++?

Мучаешься с языком пока только ты. У меня вышеописанных проблем с boost не возникает. Постарайся вести диалог более цивилизованно , не выдумывай фактов с которыми потом будешь спорить.

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

K>да какой там микроскоп, как работает lexical_cast? создает класс наследный от iostream запихивает в него входной параметр и читает выходной. это обычный быдлокод со всеми вытекающими malloc/free последствиями. В рабочем коде накиданном на скорую руку такое еще приемлемо, а в библиотеках, имхо, качество кода должно быть на порядок выше.

Я уже давал тебе совет ,по каким критериям и как оценивать библиотеки , в том числе и буст.

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

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

K>>в корень надо смотреть. форматирование тормозит из-за динамического выделения памяти в std::string, iostream, lexical_cast и других "изделиях". в логах на основе vsnprintf/fprintf тормозов не наблюдается.

M>Гм ... ты пытаешься бороться с симптомами. Я лично считаю что твой метод решения описанной проблемы тупиковый. Я уже описал достаточно простое решение которое избавляет от проблем на корню.

Писать бинарный/сокращенный лог? не смеши меня.

M>Использование vsnprintf/fprintf СОВЕРШЕННО не сопоставимо с использование стандартных потоков ввода вывода по безопастности использования. Ты наверное думаешь что они были введены в язык для галочки ?

iostream — фейлдизайн, как и почти все вещи которые разрабатывают для других.

    stringstream ss;
    string a, b, c = "vasya pupkin";

    ss << c;
    ss >> a >> b;

при этом он совершенно не "настраивается" и уступает в удобстве функциям *printf.

M>Мучаешься с языком пока только ты. У меня вышеописанных проблем с boost не возникает. Постарайся вести диалог более цивилизованно , не выдумывай фактов с которыми потом будешь спорить.

Видимо тебя просто устраивает его скорость. Между тем бустовские решения, например, vector<shared_ptr<>> гораздо тормознее чем аналогичные вещи в шарпе и яве. И программа написанная в стиле буст "заткнется" гораздо быстрее чем аналогичная на шарпе. Хотя бы из-за фрагментации кучи вызванной бездарным использованием оперативной памяти. Просто есть класс задач которые все равно на чем писать. А по качеству реализации буст библиотека именно этого уровная — "все равно как сделано".

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

M>Хочу работать в фирме которая готова разрабатывать библиотеки качественее буста.
А в чём проблема?

Здравствуйте, Аноним, Вы писали:

K>>Код, между прочим, элементарный. Та всего три простых цикла — это и понимать нечего.
А>Его просто вы писали. Впрочем это неважно, у меня простой критерий — если я понять функцию спинным мозгом не могу, а необходимо напрягать головной — то значит стиль хреновый

Интересно бы узнать, что конкретно вызвало затруднения?

E>Интересно бы узнать, что конкретно вызвало затруднения?
Слишком много субьектов для содержания в памяти — человек в мозгу может удерживать на лету порядка 7ми объектов — по мнению психологов. Так что если в функции больше 7м циклов, переменных, переходов и прочих самостоятельных сущностей — эта функция сложна для восприятия. (тоже самое кстати можно сказать про классы и далее двигаяь по дереву абстракций). Мозг нужно задействовать для восприятия общей архитектуры, функции же, как абстаркции 1го уровня, должны читаться "сходу". Кстати учтите что для профи for_each например воспринимается проще, нежели for(;), реализующй функционал foreach.

Здравствуйте, Аноним, Вы писали:

E>>Интересно бы узнать, что конкретно вызвало затруднения?
А>Слишком много субьектов для содержания в памяти — человек в мозгу может удерживать на лету порядка 7ми объектов — по мнению психологов. Так что если в функции больше 7м циклов, переменных, переходов и прочих самостоятельных сущностей — эта функция сложна для восприятия. (тоже самое кстати можно сказать про классы и далее двигаяь по дереву абстракций). Мозг нужно задействовать для восприятия общей архитектуры, функции же, как абстаркции 1го уровня, должны читаться "сходу".
Это не ответ на мой вопрос. Я про конкретную функцию спросил, если не понятно...

А>Кстати учтите что для профи for_each например воспринимается проще, нежели for(;), реализующй функционал foreach.
IMHO? tckb xedак пишет на С++ и испытывает затруднения с чтением конструкции for(;), то он кто угодно, но не профи

А>>Слишком много субьектов для содержания в памяти — человек в мозгу может удерживать на лету порядка 7ми объектов — по мнению психологов. Так что если в функции больше 7м циклов, переменных, переходов и прочих самостоятельных сущностей — эта функция сложна для восприятия. (тоже самое кстати можно сказать про классы и далее двигаяь по дереву абстракций). Мозг нужно задействовать для восприятия общей архитектуры, функции же, как абстаркции 1го уровня, должны читаться "сходу".
E>Это не ответ на мой вопрос. Я про конкретную функцию спросил, если не понятно...
Понимаете ли, еслиб вы смотрели сцылку которую я привел, вы бы заметили что там всего ОДНА функция длиной 160 строчек. Для справки — у нас на проектах принятно ограничение (правда скорее ориентировочное, нежели обязательное) — 40 строчек.

А>>Кстати учтите что для профи for_each например воспринимается проще, нежели for(;), реализующй функционал foreach.
E>IMHO? tckb xedак пишет на С++ и испытывает затруднения с чтением конструкции for(;), то он кто угодно, но не профи
for(;) в отличии от for_each требует понимания того что это именно проход по некоей последовательности. Дело не в заструднении понимания, а в очевидности и декларативности поведения написанного кода. Это не столько уменьшает время для понимания кода, сколько уменьшает вероятность совершения ошибки при его модификации.

Здравствуйте, Аноним, Вы писали:

E>>Это не ответ на мой вопрос. Я про конкретную функцию спросил, если не понятно...
А>Понимаете ли, еслиб вы смотрели сцылку которую я привел, вы бы заметили что там всего ОДНА функция длиной 160 строчек. Для справки — у нас на проектах принятно ограничение (правда скорее ориентировочное, нежели обязательное) — 40 строчек.

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

А>for(;) в отличии от for_each требует понимания того что это именно проход по некоей последовательности. Дело не в заструднении понимания, а в очевидности и декларативности поведения написанного кода. Это не столько уменьшает время для понимания кода, сколько уменьшает вероятность совершения ошибки при его модификации.
IMHO, если человек не в состоянии понять что написано в fоr( ; ; ), или испытывает проблемы с модификацией такого кода -- он некомпетентен, как С++ программист. Хотя я и согласен, что код

for( int i = 0; i < count; i++ ) {
    doIt( i );
}

намного более общепринят, чем

int i = 0;
for(;;) {
    if( i < count ) {
        doIt( i++ );
    } else {
        break;
    }
}

Но второй вариант от первого отличается только стилем. К качеству када, IMHO, это никакого прямого отношения не имеет.

Это примерно как споры о том, какой код качественнее в CamelCase или в dash_style

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

E>Интересно бы узнать, что конкретно вызвало затруднения?

Я расскажу, что непонятно:
1. Абсолютно неочевидно, асилит ли код шестнадцатиричные числа.
2. Неясно, что будет, если разделитель — запятая.
3. Куда goto?
4. Зачем goto? Можно ли без?
5. Что за сравнение с 'E' и 'D' в середине?
6. А вдруг юникод?

Это не говоря о кошмарном форматировании и диковато выглядящей сигнатуре функции.

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

K>решил сделать небольшой тест. померял скорость работы boost::lexical_cast, strtod и своего велосипеда.

Результаты обсуждения можно свести к следующему:

RSDN снова занимается оптимизацией сферической программы в вакууме


P.S. 2 Kluev — твой код банально не прошел бы code review во всех конторах, где я работал.

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

L>1. Абсолютно неочевидно, асилит ли код шестнадцатиричные числа.
IMHO понятно, что выдаст ошибку. При этом не ясно зачем бы float point numbers шестнадцатиричными числами записывать? Это кто-то вообще делает?
L>2. Неясно, что будет, если разделитель — запятая.
Ошибка формата будет. Тоже вроде как ясно...
L>3. Куда goto?
На метки...

L>4. Зачем goto? Можно ли без?
Наверное можно. В чём неясность я не понял.

L>5. Что за сравнение с 'E' и 'D' в середине?
Экспоненциальная запись числа, вестимо (что-то типа 1.17e-8)

L>6. А вдруг юникод?
А вдруг суахили?
Или китайские, скажем цифры. Ты, кстати, какую именно кодировку юникода хотел бы поддержать, в const char*? Если UTF-8, то таки всё будет работать...

L>Это не говоря о кошмарном форматировании и диковато выглядящей сигнатуре функции.
Просто C-style. Если думаешь, что в crt как-то не так, советую почитать

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

L>P.S. 2 Kluev — твой код банально не прошел бы code review во всех конторах, где я работал.
Это, кстати, правда. Так писать сейчас не принято. Но не ясно почему этот код низкого качества.
Лично у меня к нему есть две существенные претензии
1) Мало комментариев
2) Мало (вернее нет) assert'ов.

Но и то, обе претензии, IMHO, обсуждаемы...