boost - вон из профессии
От: Kluev  
Дата: 11.06.08 13:07
Оценка: 7 (2) +1 -14 :))) :)
решил сделать небольшой тест. померял скорость работы boost::lexical_cast, strtod и своего велосипеда.
велосипед мне пришлось написать т.к. strtod внутри вызывает strlen и производительность сильно падает на длинных строках.

результаты, сек
bicycle:  0.135
crt::     0.682   (в 5 раз медленнее)
boost:    6.289   (в 46.5 раз медленнее велосипеда и в 10 раз медленнее crt)


тест:
#pragma comment(lib, "Winmm.lib")

int main(int argc, char* argv[])
{
    DWORD t;
    double d, tmp;
    const char *str = "3.1415", *end = str + strlen(str);

    for (int k = 0; k < 3; k++)
    {
    // boost
        d = 0; t = timeGetTime();
        for (int i = 0; i < 1000000; i++)
        {
            d += lexical_cast<double>(str);
        }
        t = timeGetTime() - t;
        printf("boost: %g: %g\n", d, t*1e-3);

    // crt
        d = 0; t = timeGetTime();
        for (int i = 0; i < 1000000; i++)
        {
            char *p;
            d += strtod(str, &p);
        }
        t = timeGetTime() - t;
        printf("crt: %g: %g\n", d, t*1e-3);

    // bicycle
        d = 0; t = timeGetTime();
        for (int i = 0; i < 1000000; i++)
        {
            const char *cp;
            num_parse(&tmp, &cp, str, end);
            d += tmp;
        }
        t = timeGetTime() - t;
        printf("bicycle: %g: %g\n", d, t*1e-3);
    }
    return 0;
}



19.06.08 15:05: Перенесено модератором из 'C/C++' — получился флейм — Кодт
Re: boost - вон из профессии
От: LaptevVV Россия  
Дата: 11.06.08 13:15
Оценка:
Здравствуйте, 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>


А попробуй еще стандартные строковые потоки -интересно сравнить.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: boost - вон из профессии
От: php-coder Чехия http://slava-semushin.blogspot.com
Дата: 11.06.08 13:23
Оценка: 3 (1) +3
Здравствуйте, Kluev, Вы писали:

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


Собственно, ничего нового и удивительного:

Но не смотря на свою красоту, универсальность и соответствие общепринятым стандартам преобразования, у boost::lexical_cast есть и следущие недостатки:

1. Низкая скорость работы. По тестам, проведенным Гербом Саттером, результаты которых он описал в своих “Новых сложных задачах на С++”, boost::lexical_cast работает на порядок медленнее, чем тот же sprintf.


и далее:

Два из трех указанных выше недостатков достаточно легко обходятся. Поскольку boost::lexical_cast — это шаблон, то достаточно несложно написать необходимую специализацию, выполняющую преобразование настолько быстро, насколько это необходимо разработчику, а также учитывающую особенности типа wchar_t в VC++.


Взято отсюда: http://sources.ru/wiki/doku.php?id=doc:cpp:boost:lexical_cast
Re: boost - вон из профессии
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 11.06.08 13:28
Оценка:
Здравствуйте, Kluev, Вы писали:

Тоже мне, открытие Америки
Re: мы мним себя в наполеоны...(с)
От: dip_2000 Россия  
Дата: 11.06.08 13:41
Оценка:
Здравствуйте, Kluev, Вы писали:
Сделайте что-то такое же удобное, и безопасное
Re: boost - вон из профессии
От: Zigmar Израиль  
Дата: 11.06.08 13:42
Оценка: 5 (3) +4
Здравствуйте, 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>


boost в данном случае даёт наиболее простое и универсальное решение, которое естественно, не самое быстрое. Если именно этот кусок у вас является баттлнеком — то и стоит оптимизировать, но для остальных 95% случаев, лучше воспользоваться более читабельным, надёжным и аккуратным решением. Мессадж в названии топика вообще глупый — практически для любой задачи, можно придумать специализированное решение более быстрое чем общее, и это не значит что ради сомнительных микрооптимизаций нужно выкинуть на помойку все удобные и универсальные инструменты.

Конкретно на тему lexical_cast, никто не мешает сделать вам специализацию для вашего конкретного случая. И достоинство его не в том, что он должен, как вам кажется, на синтетическом тесте бить велосипед по скорости конвертирования стрингов в числа, а в том, что это удобный и понятный способ конвертировать любой тип данных в текстовое представление и наоборот.
"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"
Re[2]: мы мним себя в наполеоны...(с)
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 11.06.08 13:49
Оценка:
Здравствуйте, dip_2000, Вы писали:

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

_>Сделайте что-то такое же удобное, и безопасное

Вариация на тему:
template<class VAL, class Ch> inline
VAL from_string(const std::basic_string<Ch> &str)
{
    static std::locale loc("Russian_Russia");
    static std::ios_base::iostate st = 0;
    static std::basic_istringstream<Ch> iss;
    VAL ret_val;
    std::use_facet<num_get<Ch, typename std::basic_string<Ch>::const_iterator> >(loc).get(str.begin(), str.end(), iss, st, ret_val);
    return ret_val;
}


Использовать так:
double d = from_string<double>(str);


Можно сравнить по скорости.
Re: boost - вон из профессии
От: Кодт Россия  
Дата: 11.06.08 13:51
Оценка: 2 (2) :)
Здравствуйте, Kluev, Вы писали:

Минус за глупое обобщение в сабже.
Верёвка достаточной длины, чтобы обмотаться сверху донизу и наконец выстрелить в ногу.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[2]: мы мним себя в наполеоны...(с)
От: Kluev  
Дата: 11.06.08 13:56
Оценка: -1
Здравствуйте, dip_2000, Вы писали:

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

_>Сделайте что-то такое же удобное, и безопасное

в этом нет ничего трудного, достаточно написать обертку вокруг strtod/strtol
lexical_cast представляет из себя бездарно написанную обертку вокруг iostream,
а iostream в конечном итоге все равно вызывает crt-шные strtod/strtol.
Re: boost - вон из профессии
От: korzh.pavel Россия  
Дата: 11.06.08 13:57
Оценка:
Здравствуйте, Kluev, Вы писали:

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

K>велосипед мне пришлось написать т.к. strtod внутри вызывает strlen и производительность сильно падает на длинных строках.

[...]

мне ещё из подобных средств нравится boost::spirit::real_parser — очень хорошо настраиваемый.
Я один раз встроил его в один проект в котором активно делалось преобразование str->double
Естественно выкинул всё лишнее, работал он быстрее strtod и надёжнее
Автор: korzhik
Дата: 08.08.05
Re[2]: boost - вон из профессии
От: Kluev  
Дата: 11.06.08 14:07
Оценка: +2 -8
Здравствуйте, Zigmar, Вы писали:

Z>boost в данном случае даёт наиболее простое и универсальное решение, которое естественно, не самое быстрое.


Вообще-то нет никаких причин которые мешают написать его по человечески и эффективно.
Вместо этого нагромождение быдлокода, весьма характерное для boost.
Re[2]: boost - вон из профессии
От: CreatorCray  
Дата: 11.06.08 14:14
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>А попробуй еще стандартные строковые потоки -интересно сравнить.

Тоже скорость кошмарная.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: boost - вон из профессии
От: CreatorCray  
Дата: 11.06.08 14:14
Оценка:
Здравствуйте, 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>


Агаа
У меня такая же хрень — велосипеды рулят.

StrToDouble: Done
  CRT     : ( 1.734827)  4'648'555'990
  CrayLib : ( 0.082319)    220'579'670
  Difference : 21.074272


Для int поскромнее — всего в 4 раза разница
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: boost - вон из профессии
От: Zigmar Израиль  
Дата: 11.06.08 14:21
Оценка:
Здравствуйте, Kluev, Вы писали:
Z>>boost в данном случае даёт наиболее простое и универсальное решение, которое естественно, не самое быстрое.
K>Вообще-то нет никаких причин которые мешают написать его по человечески и эффективно.
K>Вместо этого нагромождение быдлокода, весьма характерное для boost.
Ну и приведите пример универсального решения, которое будет эффективно делать то-же, что и lexical_cast. Не забывая, естественно про поддержку custom types. И вообще, прежде чем наезжать на буст, я бы посоветовал, скажем, заменит строчку "3.1415" на экспоненциальную нотацию или на "NAN" и посмотреть это схавает ваш хвалёный велосипед.
"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"
Re[3]: мы мним себя в наполеоны...(с)
От: dip_2000 Россия  
Дата: 11.06.08 14:23
Оценка:
Здравствуйте, Kluev, Вы писали:

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


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

_>>Сделайте что-то такое же удобное, и безопасное

K>в этом нет ничего трудного, достаточно написать обертку вокруг strtod/strtol

K>lexical_cast представляет из себя бездарно написанную обертку вокруг iostream,
K>а iostream в конечном итоге все равно вызывает crt-шные strtod/strtol.

я вас уверяю, по русски, писать гораздо проще(и безопаснее :D ) чем на с++ Вы напишите на с++, и опубликуйте... да хоть здесь. я с удовольствием поставлю вам столько плюсов сколько смогу
Re[4]: boost - вон из профессии
От: Kluev  
Дата: 11.06.08 14:48
Оценка: +1
Здравствуйте, Zigmar, Вы писали:

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

Z>>>boost в данном случае даёт наиболее простое и универсальное решение, которое естественно, не самое быстрое.
K>>Вообще-то нет никаких причин которые мешают написать его по человечески и эффективно.
K>>Вместо этого нагромождение быдлокода, весьма характерное для boost.
Z>Ну и приведите пример универсального решения, которое будет эффективно делать то-же, что и lexical_cast. Не забывая, естественно про поддержку custom types. И вообще, прежде чем наезжать на буст, я бы посоветовал, скажем, заменит строчку "3.1415" на экспоненциальную нотацию или на "NAN" и посмотреть это схавает ваш хвалёный велосипед.

lexical_cast не универсален. например понадобится конвертнуть строку с парой чисел разделенных запятыми. lexical_cast — облом, iostream — облом.
а старые добрые strtod/strtol вполне подойдут (их только нелепый strlen внутри портит).

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

template <class Char> int // разбор сишной строки
    parse(double &result, const Char *str);

template <class Char> int // разбор фрагмента строки
    parse(double &result, const Char *&pos, const Char *end);

template <class Char> int // аналогично для интов
    parse(int &result, const Char *str);

template <class Char> int
    parse(int &result, const Char *&pos, const Char *end);

template <class Result, class Char> Result
    lexical_cast(const Char *str)
{
    Result r;
    if (int errcode = parse(r, str))
        throw CastError(errcode);
    return r;
}


для еще более полной универсальности вместо const char* можно использовать итераторы.
Re[4]: мы мним себя в наполеоны...(с)
От: Kluev  
Дата: 11.06.08 15:05
Оценка: +1
Здравствуйте, dip_2000, Вы писали:

на бaзе банальных strtod/l

bool parse(int &r, const char *s)
{
    char *p;
    r = strtol(s, &p, 10);
    if (s == p || errno)
        return false;
    return *p == 0 || isspace((int)*p);
}

bool parse(double &r, const char *s)
{
    char *p;
    r = strtod(s, &p);
    if (s == p || errno)
        return false;
    return *p == 0 || isspace((int)*p);
}

// .....

template <class Result> Result
    lexical_cast(const char *str)
{
    if (!str)
        throw std::exception();

    Result r;
    if (!parse(r, str))
        throw std::exception();
    return r;
}
Re: boost - вон из профессии
От: nen777w  
Дата: 11.06.08 15:07
Оценка:
У меня lexical_cast трудится в калбеках от FLEX парсера.
ИМХО для таких задач возможности lexical_cast это самое то.
Re: premature optimization - туда же
От: Аноним  
Дата: 11.06.08 15:32
Оценка: +2 -2 :))) :)
Re[2]: boost - вон из профессии
От: Sergey Россия  
Дата: 11.06.08 16:16
Оценка:
korzh.pavel пишет:

> мне ещё из подобных средств нравится boost::spirit::real_parser — очень

> хорошо настраиваемый.
> Я один раз встроил его в один проект в котором активно делалось
> преобразование str->double
> Естественно выкинул всё лишнее, работал он быстрее strtod и надёжнее

Со спиритом другая проблема — фиг поймешь, где их глобальный мьютекс
используется, а где нет.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re: Оптимизация
От: Roman Odaisky Украина  
Дата: 11.06.08 16:20
Оценка:
Здравствуйте, Kluev, Вы писали:

K>померял скорость работы boost::lexical_cast


Там к нему давно есть оптимизация
Автор: korzhik
Дата: 02.09.06
. Правда, она не вошла в 1.35 — очень уж спешили выпустить новую версию.
До последнего не верил в пирамиду Лебедева.
Re[2]: Оптимизация
От: Аноним  
Дата: 11.06.08 16:36
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

K>>померял скорость работы boost::lexical_cast


RO>Там к нему давно есть оптимизация
Автор: korzhik
Дата: 02.09.06
. Правда, она не вошла в 1.35 — очень уж спешили выпустить новую версию.

Эта оптимизация затрагивает числа с плавающей точкой?
Re[5]: boost - вон из профессии
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 11.06.08 16:49
Оценка: +1 -4
Здравствуйте, Kluev, Вы писали:

Z>>Ну и приведите пример универсального решения, которое будет эффективно делать то-же, что и lexical_cast. Не забывая, естественно про поддержку custom types. И вообще, прежде чем наезжать на буст, я бы посоветовал, скажем, заменит строчку "3.1415" на экспоненциальную нотацию или на "NAN" и посмотреть это схавает ваш хвалёный велосипед.


по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN"
да и экспоненциальная нотация, имхо, хороша только для научных работников и соответствующего им софта
Viva el Junta Militar! Viva el Presidente!
Re[3]: Оптимизация
От: Roman Odaisky Украина  
Дата: 11.06.08 18:01
Оценка:
Здравствуйте, Аноним, Вы писали:

RO>>Там к нему давно есть оптимизация
Автор: korzhik
Дата: 02.09.06
. Правда, она не вошла в 1.35 — очень уж спешили выпустить новую версию.

А>Эта оптимизация затрагивает числа с плавающей точкой?

Именно та — нет. Может, с тех пор уже приделали, не знаю.
До последнего не верил в пирамиду Лебедева.
Re[5]: мы мним себя в наполеоны...(с)
От: dip_2000 Россия  
Дата: 11.06.08 18:13
Оценка:
Здравствуйте, Kluev, Вы писали:

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


K>на бaзе банальных strtod/l


K>
K>bool parse(int &r, const char *s)
K>{
K>    char *p;
K>    r = strtol(s, &p, 10);
K>    if (s == p || errno)
K>        return false;
K>    return *p == 0 || isspace((int)*p);
K>}

K>bool parse(double &r, const char *s)
K>{
K>    char *p;
K>    r = strtod(s, &p);
K>    if (s == p || errno)
K>        return false;
K>    return *p == 0 || isspace((int)*p);
K>}

K>// .....

K>template <class Result> Result
K>    lexical_cast(const char *str)
K>{
K>    if (!str)
K>        throw std::exception();

K>    Result r;
K>    if (!parse(r, str))
K>        throw std::exception();
K>    return r;
K>}
K>


http://www.boost.org/doc/libs/1_35_0/libs/conversion/lexical_cast.htm

//The following example uses numeric data in a string expression: void log_message(const std::string &);

void log_errno(int yoko)
{
    log_message("Error " + boost::lexical_cast<std::string>(yoko) + ": " + strerror(yoko));
}

быстро, но неудобно
Re[6]: boost - вон из профессии
От: landerhigh Пират  
Дата: 11.06.08 22:50
Оценка: 2 (2) +6 :)
Здравствуйте, Ligen, Вы писали:

L>по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN"

L>да и экспоненциальная нотация, имхо, хороша только для научных работников и соответствующего им софта
Ой, сколько я повидал вырванного волосяного покрова из одного места, когда проектировали исходя из таких вот "редко", "наверное" и "кажется", а на деле оказывалось, что вовсе не редко и именно что кажется.
www.blinnov.com
Re[5]: boost - вон из профессии
От: Zigmar Израиль  
Дата: 11.06.08 23:47
Оценка: 1 (1) +1 :)))
Здравствуйте, Kluev, Вы писали:
K>lexical_cast не универсален. например понадобится конвертнуть строку с парой чисел разделенных запятыми. lexical_cast — облом, iostream — облом.
K>а старые добрые strtod/strtol вполне подойдут (их только нелепый strlen внутри портит).

K>по настоящему универсальным решением было бы семейство "низкоуровневых" перегруженных функций для разбора чисел + шаблонная обертка вокруг.


K>
K>template <class Char> int // разбор сишной строки
K>    parse(double &result, const Char *str);
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"
Re: Спасибо за разоблачение !
От: minorlogic Украина  
Дата: 12.06.08 06:47
Оценка:
Может это заговор с производителями памяти и процессоров ? Может специально делают такие медленные библимотеки ? Чтобы потом было чем грузить процессор?

P.S. Флаги бы компиляции привел, чтоль ... компилятор версию.
А по делу , документацию читать не пробовали ? говорят может помочь ...
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: boost - вон из профессии
От: alexeiz  
Дата: 12.06.08 06:50
Оценка: 2 (1) :)
Здравствуйте, 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>


У меня после всех оптимизаций:
boost: 3.1415e+006: 3.027
crt: 3.1415e+006: 0.639
boost: 3.1415e+006: 3.042
crt: 3.1415e+006: 0.64
boost: 3.1415e+006: 3.042
crt: 3.1415e+006: 0.624

(bicycle implementation was not found in the original post )

Если взглянуть на профайл, что я боюсь, тебе сделать не удалось (по причине либо отсутствия профайлера, либо неумения им пользоваться), то видно, что это очередной micro-benchmark, который ничего не значит. Кстати lexical_cast'а в профайле вообще не видно (оптимизация, понимаешь!).
Level,Function Name,Inclusive Samples,Exclusive Samples,Inclusive Samples %,Exclusive Samples %,Module Name,
0,"lexical_cast_perf.exe","2,183",0,100.00,0.00,"",
0,"_mainCRTStartup","2,183",0,100.00,0.00,"lexical_cast_perf.exe",
4,"[4 rows folded ending in "__fltin2"]",323,12,14.80,0.55,"lexical_cast_perf.exe",
5,"___strgtold12_l",266,188,12.19,8.61,"lexical_cast_perf.exe",
6,"___mtold12",78,78,3.57,3.57,"lexical_cast_perf.exe",
1,"Unknown Frame(s)","1,811",0,82.96,0.00,"UNKNOWN",
2,"_main","1,677",51,76.82,2.34,"lexical_cast_perf.exe",
3,"__Mtxunlock",78,5,3.57,0.23,"lexical_cast_perf.exe",
4,"[ntdll.dll]",67,67,3.07,3.07,"ntdll.dll",
4,"[2 rows folded ending in "_malloc"]",89,12,4.08,0.55,"lexical_cast_perf.exe",
5,"[ntdll.dll]",77,23,3.53,1.05,"ntdll.dll",
4,"[2 rows folded ending in "__Mtxlock"]",93,6,4.26,0.27,"lexical_cast_perf.exe",
5,"[ntdll.dll]",87,87,3.99,3.99,"ntdll.dll",
3,"std::ios_base::_Ios_base_dtor(class std::ios_base *)",106,4,4.86,0.18,"lexical_cast_perf.exe",
4,"std::locale::`scalar deleting destructor'(unsigned int)",96,10,4.40,0.46,"lexical_cast_perf.exe",
4,"[2 rows folded ending in "__Mtxdst"]",79,2,3.62,0.09,"lexical_cast_perf.exe",
5,"[ntdll.dll]",77,15,3.53,0.69,"ntdll.dll",
3,"std::_Mutex::_Mutex(void)",145,7,6.64,0.32,"lexical_cast_perf.exe",
5,"[2 rows folded ending in "[ntdll.dll]"]",74,4,3.39,0.18,"ntdll.dll",
6,"[ntdll.dll]",70,9,3.21,0.41,"ntdll.dll",
3,"std::basic_istream<char,struct std::char_traits<char> >::operator>>(double &)",801,36,36.69,1.65,"lexical_cast_perf.exe",
4,"std::num_get<char,class std::istreambuf_iterator<char,struct std::char_traits<char> > >::do_get(class std::istreambuf_iterator<char,struct std::char_traits<char> >,class std::istreambuf_iterator<char,struct std::char_traits<char> >,class std::ios_base &,int &,double &)const ",650,11,29.78,0.50,"lexical_cast_perf.exe",
5,"std::num_get<char,class std::istreambuf_iterator<char,struct std::char_traits<char> > >::_Getffld(char *,class std::istreambuf_iterator<char,struct std::char_traits<char> > &,class std::istreambuf_iterator<char,struct std::char_traits<char> > &,class std::locale const &)const ",168,98,7.70,4.49,"lexical_cast_perf.exe",
6,"[2 rows folded ending in "_strtod"]",335,4,15.35,0.18,"lexical_cast_perf.exe",
8,"[2 rows folded ending in "__fltin2"]",294,8,13.47,0.37,"lexical_cast_perf.exe",
9,"___strgtold12_l",250,164,11.45,7.51,"lexical_cast_perf.exe",
10,"___mtold12",84,83,3.85,3.80,"lexical_cast_perf.exe",


Чтобы удобнее было смотреть, скопируй профайл в .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, то тебе в любом случае нужно специализированное решение. Все существующие библиотечные решения будут медленнее, потому как они расчитаны на более или менее общий случай, а не на твой конкретный.
Re: boost - вон из профессии
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 12.06.08 10:07
Оценка:
Здравствуйте, 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>


Попробуй еще BOOST_LEXICAL_CAST_ASSUME_C_LOCALE.
Re[2]: boost - вон из профессии
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 12.06.08 10:14
Оценка:
Здравствуйте, alnsn, Вы писали:

A>Попробуй еще BOOST_LEXICAL_CAST_ASSUME_C_LOCALE.


Поторопился я с ответом, это не работает для чисел с плавающей точкой. Их сложнее оптимизировать, чтобы никто разницы с ostream не заметил.
Re[6]: boost - вон из профессии
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 12.06.08 10:18
Оценка:
Здравствуйте, Ligen, Вы писали:

L>по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN"


Редко то редко, но когда софт упадет на загрузке файла "бабло.приход" из-за NAN ...
Re: boost - вон из профессии
От: Аноним  
Дата: 12.06.08 10:21
Оценка:
Здравствуйте, Kluev, Вы писали:

K>...


Если уж приходится парсить такие объемы данных, на которых становится заметной разница между lexical_cast и strtod, разумнее воспользоваться специализированным решением, написать парсер что ли.
Re[3]: boost - вон из профессии
От: alnsn Великобритания http://nasonov.blogspot.com
Дата: 12.06.08 10:27
Оценка:
Здравствуйте, alnsn, Вы писали:

A>>Попробуй еще BOOST_LEXICAL_CAST_ASSUME_C_LOCALE.

A>Поторопился я с ответом, это не работает для чисел с плавающей точкой. Их сложнее оптимизировать, чтобы никто разницы с ostream не заметил.

BTW, давно хочу посмотреть на эту либу: http://article.gmane.org/gmane.comp.lib.boost.user/33648
Re[7]: boost - вон из профессии
От: CreatorCray  
Дата: 12.06.08 10:40
Оценка: 1 (1) +3
Здравствуйте, alnsn, Вы писали:

A>Редко то редко, но когда софт упадет на загрузке файла "бабло.приход" из-за NAN ...

NaN это Not a Number
Не число т.е.
Функция не должна его отрабатывать, а должна вернуть ошибку — мол, фигню подсунули.
Равно как и при попытке подсунуть "ksdhfiwnerxifwer" для преобразования.

В чем проблема то?
Или считаешь что отлов ошибочных данных имеет право делать только boost, а "велосипедная" функция этого уметь не может по определению?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: boost - вон из профессии
От: Kluev  
Дата: 12.06.08 11:24
Оценка: +2 -6
Здравствуйте, alexeiz, Вы писали:

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



A>Если взглянуть на профайл, что я боюсь, тебе сделать не удалось (по причине либо отсутствия профайлера, либо неумения им пользоваться), то видно, что это очередной micro-benchmark, который ничего не значит. Кстати lexical_cast'а в профайле вообще не видно (оптимизация, понимаешь!).


Профайлер здесь и не нужен. Я посмотрел в исходники и обнаружил там быдлокодец вокруг iostream.
Кстати, в недрах этого чуда несколько раз вызывается new, поэтому производительность в реальных условиях будет еще сильно зависить от состояния кучи. А сам факт динамического выделения памяти для операции string -> number говорит о низкой культуре программирования у бустовских кодеров. Видимо на первом месте в бусте стоит "чистота концепций", а все остальные вопросы игнорируются.
Re[8]: boost - вон из профессии
От: Zigmar Израиль  
Дата: 12.06.08 12:27
Оценка:
Здравствуйте, 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"
Re[9]: boost - вон из профессии
От: CreatorCray  
Дата: 12.06.08 13:03
Оценка: +1 -1
Здравствуйте, Zigmar, Вы писали:

Z>Ну скажем не NAN, a INF. Хотя в каком-нибудь столбце вполне может стоит и NAN, и далеко не факт что это ошибка, и совершенно точно парсер от такого падать не должен.

А с чего вдруг ему падать? Откуда такая уверенность что самописное априори хуже библиотечного? Библиотеки по сути такое же сборище велосипедов, и все гарантии качества только на совести их разработчиков и тестеров.
Качество кода (велосипеда или буста или CRT или еще чего) определяется ровностью рук и качеством мозгов программера, их написавшего, и тестера их оттестировавшего.

Z>Проблема "велосипедных" функций, в том, что кроме автора (и то, далеко не всегда) не знает что там происходит.

Для этого есть документирование и комментарии.

Z> В стандартных библиотечных функций, как минимум можно знать чего ожидать, или во всяком случае куда обращаться.

Они ничуть не лучше нормально написанных, оттестированных и задокументированных "велосипедных" функций.

Z> Я лично, как-то отыскивая источник memory corruption потратил неделю на чтения мемори дампов и кода, только чтоб обнаружить, что человек, давно в фирме не работающей, когда-то написал "простой" велосипед как-то там конвертирующий строки и числа, и который упал через несколько лет когда в первый раз в неё попала строка с какой-то экзотической локалью, вроде японского.

Ну так товарищ сам дурак — писать надо нормально. С таким же успехом он мог накосячить в любом другом месте.
Зачем он кстати там писал свое преобразование? Причины на то были?

Если кто не понял — я про то веду речь, что нормально написанный "велосипед" может быть лучше библиотечных функций.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: boost - вон из профессии
От: Kluev  
Дата: 12.06.08 13:18
Оценка: +3 -2
Здравствуйте, Zigmar, Вы писали:

CC>>В чем проблема то?

CC>>Или считаешь что отлов ошибочных данных имеет право делать только boost, а "велосипедная" функция этого уметь не может по определению?
Z>Проблема "велосипедных" функций, в том, что кроме автора (и то, далеко не всегда) не знает что там происходит. В стандартных библиотечных функций, как минимум можно знать чего ожидать, или во всяком случае куда обращаться. Я лично, как-то отыскивая источник memory corruption потратил неделю на чтения мемори дампов и кода, только чтоб обнаружить, что человек, давно в фирме не работающей, когда-то написал "простой" велосипед как-то там конвертирующий строки и числа, и который упал через несколько лет когда в первый раз в неё попала строка с какой-то экзотической локалью, вроде японского.

Из этого не следует, что все велосипеды г-но, а буст хороший. Я прошелся дебаггером по lexical_cast и обнаружил, что качество кода в нем очень низкое. Даже если он одобрен миллионом слепых глаз суть от этого не меняется.
Качество кода определяется самим кодом, а не тем он входит ли он в буст или из доморощенного велосипеда.
Re[10]: boost - вон из профессии
От: . Великобритания  
Дата: 12.06.08 14:40
Оценка: +1
CreatorCray wrote:

> Качество кода (велосипеда или буста или CRT или еще чего) определяется

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

А вообще говоря странно, что тут решили бабло парсить в плавучку.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.06.08 15:57
Оценка: +5 :)
Здравствуйте, Kluev

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

boost::lexical_cast, как и std::stringstream, изрядный тормоз и для некоторых вещей применять его совершенно неразумно. Вне зависимости о того, правомерно ли Kluev охаивает качество boost-а или нет.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: boost - вон из профессии
От: alexeiz  
Дата: 12.06.08 18:12
Оценка:
Здравствуйте, Kluev, Вы писали:

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


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



A>>Если взглянуть на профайл, что я боюсь, тебе сделать не удалось (по причине либо отсутствия профайлера, либо неумения им пользоваться), то видно, что это очередной micro-benchmark, который ничего не значит. Кстати lexical_cast'а в профайле вообще не видно (оптимизация, понимаешь!).


K>Профайлер здесь и не нужен. Я посмотрел в исходники и обнаружил там быдлокодец вокруг iostream.

K>Кстати, в недрах этого чуда несколько раз вызывается new, поэтому производительность в реальных условиях будет еще сильно зависить от состояния кучи. А сам факт динамического выделения памяти для операции string -> number говорит о низкой культуре программирования у бустовских кодеров. Видимо на первом месте в бусте стоит "чистота концепций", а все остальные вопросы игнорируются.

Странный ты человек. Взгляни хоть на профайл один раз. Где там вызывается new? Пока что ты здесь занимаешься игнорированием а не бустовские кодеры.
Re[4]: boost - вон из профессии
От: Kluev  
Дата: 12.06.08 18:57
Оценка: -1
Здравствуйте, alexeiz, Вы писали:

A>Странный ты человек. Взгляни хоть на профайл один раз. Где там вызывается new? Пока что ты здесь занимаешься игнорированием а не бустовские кодеры.


Re[10]: boost - вон из профессии
От: minorlogic Украина  
Дата: 12.06.08 19:01
Оценка: -1
Здравствуйте, CreatorCray, Вы писали:

Z>> В стандартных библиотечных функций, как минимум можно знать чего ожидать, или во всяком случае куда обращаться.

CC>Они ничуть не лучше нормально написанных, оттестированных и задокументированных "велосипедных" функций.

К сожалению я не могу разработать аналоги многих библиотек , в том числе буста с таким же качеством. Надеюсь это не моя бездарномть а просто нехватка ресурсов. Хочу работать в фирме которая готова разрабатывать библиотеки качественее буста.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: boost - вон из профессии
От: minorlogic Украина  
Дата: 12.06.08 19:04
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


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

Ты попал в точку. Мне не разу в жизни не пришлось выбрасывать "std::string, std::stringstream и std::set/map после работы с профайлером." Наверное я не дорос то того уровня абстракции.

А вот код где конкатенация строк оптимизировалась заменой std::string на strcpy видел.

E>boost::lexical_cast, как и std::stringstream, изрядный тормоз и для некоторых вещей применять его совершенно неразумно. Вне зависимости о того, правомерно ли Kluev охаивает качество boost-а или нет.

Подозреваю что это очевидно для людей интенсивно использующих буст ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: boost - вон из профессии
От: minorlogic Украина  
Дата: 12.06.08 19:05
Оценка: +1
Мне этот дамп напоминает дебаговую сборку ? я не прав ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: boost - вон из профессии
От: Kluev  
Дата: 12.06.08 19:17
Оценка: 5 (1)
Здравствуйте, minorlogic, Вы писали:

M>Мне этот дамп напоминает дебаговую сборку ? я не прав ?


Спешал фор ю.
Re: boost - вон из профессии
От: anc  
Дата: 12.06.08 19:52
Оценка:
Здравствуйте, Kluev, Вы писали:

K>решил сделать небольшой тест.


А попробуй еще мой bicycle


double my_bicycle(const char *)
{
    return 3.1415;
}


а если серьёзно — код num_parse в студию
Re[2]: boost - вон из профессии
От: Kluev  
Дата: 12.06.08 20:16
Оценка:
Здравствуйте, anc, Вы писали:

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


K>>решил сделать небольшой тест.


anc>А попробуй еще мой bicycle


anc>
anc>double my_bicycle(const char *)
anc>{
anc>    return 3.1415;
anc>}

anc>


anc>а если серьёзно — код num_parse в студию


int num_parse
(
  double    *num,
  const char  **stop,
  const char  *p,
  const char  *end
)
{
  i64    ct;
  int    neg;
  double val;
  int    ep;
  int    ep_neg;
  uchar  c;
  int    digs;
  double tmp;

  static CharType ctype;

  for ( ;; ) {
    if ( p < end )
      ct = ctype.type( c = *p );
    else
      goto err_eof;

    if ( ct & char_t::space )
      ++p;
    else
      break;
  }

  if ( ct & char_t::sign ) {
    neg = ( '-' == c );
    if ( ++p == end )
      goto err_eof;
    ct = ctype.type( c = *p );
  }
  else
    neg = false;

  // first char
  if ( ct & char_t::digit )
    { val = c - '0'; ++p; }
  else if ( '.' == c )
    { val = 0; ++p; digs = 0; goto dot_ok; }

  for (;;) {
    if ( p < end )
      ct = ctype.type( c = *p );
    else
      goto ip_eof;

    if ( ct & char_t::digit )
      val = val * 10 + (c-'0');
    else
      goto ip_ok;
    ++p;
  }

ip_ok:

  digs = 0;

  if ( '.' != c )
    goto fp_ok;
  else
    ++p;

dot_ok:

  for (;;) {
    if ( p < end )
      ct = ctype.type( c = *p );
    else
      goto fp_eof;

    if ( ct & char_t::digit ) {
      val = val * 10 + (c-'0');
      --digs;
    }
    else
      goto fp_ok;

    ++p;
  }

fp_ok:

  if ( 'E' == c || 'D' == c || 'e' == c || 'd' == c )
    ++p;
  else
    goto fp_eof;

  if ( p == end )
    goto err_eof;

  ct = ctype.type( c = *p );
  if ( ct & char_t::sign ) {
    ep_neg = ( '-' == c );
    if ( ++p == end )
      goto err_eof;
    else
      ct = ctype.type( c = *p );
  }
  else
    ep_neg = false;

// first char
  if ( ct & char_t::digit )
    { ep = c - '0'; ++p; }
  else
    goto err_syntax;
  
  for ( ;; ) {
    if ( p < end )
      ct = ctype.type( c = *p );
    else
      break;

    if ( ct & char_t::digit ) {
      ep = ep * 10 + (c-'0');
    }
    else
      break;
    
    ++p;
  }

  if ( ep_neg )
    digs -= ep;
  else
    digs += ep;

  *stop = p;
  tmp = pow( 10., digs );
  *num = neg ? -(tmp * val) : tmp * val;
  return num_parse_ok;

ip_eof:
  *stop = p;
  *num = neg ? 0.-val : val;
  return num_parse_ok;

fp_eof:
  *stop = p;
  tmp = pow( 10., digs );
  *num = neg ? -(tmp * val) : tmp * val;
  return num_parse_ok;

err_eof:
  *stop = p;
//  *num = 0;
  return num_parse_eof;

err_syntax:
  *stop = p;
//  *num = 0;
  return num_parse_syntax;

}
Re[2]: boost - вон из профессии
От: Аноним  
Дата: 12.06.08 21:31
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


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


Ну да, приходится переодически менять структуру данных X на Y и алгоритм Foo на Bar.
Тоже мне откровение
Re[11]: boost - вон из профессии
От: CreatorCray  
Дата: 12.06.08 21:37
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>К сожалению я не могу разработать аналоги многих библиотек, в том числе буста с таким же качеством.

Работай над этим

M> Надеюсь это не моя бездарномть а просто нехватка ресурсов.

а также времени и желания...

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

Их много. Не надо считать что буст идеален в плане качества.

Буст начинал как как большой репозиторий бесплатных велосипедов куда каждый мог выложить свой велосипед на peer-review.
Подробнее здесь: http://www.boost.org/users/proposal.pdf
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: boost - вон из профессии
От: landerhigh Пират  
Дата: 13.06.08 02:34
Оценка: 3 (1)
Здравствуйте, eao197, Вы писали:

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


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

std:string сотоварищами выбрасывать не приходилось. Приходилось выбрасывать глючный быдлокод, который рожали исходи из вот такого "был std::string и все тормозило". Не говоря уже о раздаче люлей любителям передавать контейнеры по значению и профилировать отладочную сборку.
www.blinnov.com
Re[2]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 13.06.08 02:35
Оценка: 2 (1)
Здравствуйте, eao197, Вы писали:

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


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


Приходилось, конечно, но почему-то ни разу в голову не пришло заявить "boost/ACE/STL/C++/whatever — вон из профессии"
И скорее всего потому, что на одно выброшенное приходится десять невыброшенных, которые отлично в своих ситуациях работают, давая простой и прозрачный для понимания код.

E>boost::lexical_cast, как и std::stringstream, изрядный тормоз и для некоторых вещей применять его совершенно неразумно. Вне зависимости о того, правомерно ли Kluev охаивает качество boost-а или нет.


А с этим никто и не спорит. Просто "некоторые вещи" и "boost — вон из профессии" несколько несовместимы по уровню обобщения.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: boost - вон из профессии
От: landerhigh Пират  
Дата: 13.06.08 02:37
Оценка: 1 (1) +2 :)))
Здравствуйте, Kluev, Вы писали:

[skip]

[Задумчиво] При прочтении данного кода на ум почему-то постоянно приходило слово "биореактор".
www.blinnov.com
Re[3]: boost - вон из профессии
От: anc  
Дата: 13.06.08 06:26
Оценка: 1 (1)
Здравствуйте, Kluev, Вы писали:


это не аналог strtod() — нет обработки overflow/underflow и напомнило http://www.rsdn.ru/forum/message/2795063.1.aspx

откуда CharType?

тест не правильный — выносить

*end = str + strlen(str);


из цикла подсчета времени нельзя!
Re[2]: boost - вон из профессии
От: Аноним  
Дата: 13.06.08 08:05
Оценка:
E>Складывается впечатление, что возражающим Kluev-у товарищам, вероятно, никогда не приходилось выбрасывать из программы вещи типа std::string, std::stringstream и std::set/map после работы с профайлером.
Честно говоря — выбрасывать нет, не приходилось
Re[4]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 08:30
Оценка:
Здравствуйте, anc, Вы писали:

anc>это не аналог strtod() — нет обработки overflow/underflow и напомнило http://www.rsdn.ru/forum/message/2795063.1.aspx

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

anc>откуда CharType?

Другой велосипед

anc>тест не правильный — выносить из цикла подсчета времени нельзя!

внутри функции можно легко заменить проверку p < end на *p, но мне было влом поэтому я просто поставил strlen
Re[3]: Kluev - вон из профессии
От: boost  
Дата: 13.06.08 08:56
Оценка: :))) :))) :))) :))
Здравствуйте, Kluev, Вы писали:

K>
K>int num_parse
K>... // га*нокод вырезал
K>
Re[2]: boost - вон из профессии
От: Pavel Dvorkin Россия  
Дата: 13.06.08 09:06
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

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


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


Мне не приходилось. Я их к своим программам, когда изначально известно, что нужна скорость, близко не подпускаю
With best regards
Pavel Dvorkin
Re[2]: boost - вон из профессии
От: minorlogic Украина  
Дата: 13.06.08 09:48
Оценка: 7 (3) +6
Здравствуйте, eao197, Вы писали:

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


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


E>boost::lexical_cast, как и std::stringstream, изрядный тормоз и для некоторых вещей применять его совершенно неразумно. Вне зависимости о того, правомерно ли Kluev охаивает качество boost-а или нет.


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

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

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


"boost::lexical_cast" даже по названию может прити в голову что это не инструмент конвертирования строки в дабл а некий универсальный преобразователь типов. И что варианты его использования предполагают и неимение информации о типе (я имею ввиду шаблонные конструкции).

Я не собираюсь идеализировать буст , тем более что он состоит из множества гетерогенных библиотек, но как бы и не хочется оставить без внимания воинствующую безграмотность. Для критики какой либо из бустовских библиотке (а весь буст критиковать это просто безграмотно) надо было бы рассотреть для чего она написанна, варианты использования , и предложить альтернативу лучше удовлетворяющую поставленным задачам.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.06.08 10:10
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: boost - вон из профессии
От: minorlogic Украина  
Дата: 13.06.08 10:34
Оценка: +1 -1 :)
Здравствуйте, eao197, Вы писали:

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


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


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


Для меня выбор очевиден , а вы подумайте. Судя по вашемк предыдущему посту, вы предпочитаете "собственные велосипеды на основе std::string"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 10:42
Оценка: +2
Здравствуйте, eao197, Вы писали:

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


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


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


Вообще, для полного счастья достаточно было-бы иметь пару функций для парзинга чисел. Одна должна работать с парой итераторов Begin,End
вторая с одним итератором и нулем в качестве терминатора. На базе этого можно уже строить все, что угодно. Хоть lexical_cast, хоть специализированные парзеры. Именно так должны строится нормальные библиотеки: в основе низкоуровневые универсальные вещи, сверху удобные оболочки аля lexical_cast iostream и т.п.
Re[3]: boost - вон из профессии
От: CreatorCray  
Дата: 13.06.08 10:49
Оценка:
Здравствуйте, minorlogic, Вы писали:

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

Приведи пример "специализированных парсеров" для использования в "парсере больших текстов или в неком сервере под нагрузкой с большим к-вом запросов" плз.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.06.08 11:19
Оценка: 23 (2) +4
Здравствуйте, 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. И т.д.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: boost - вон из профессии
От: Programador  
Дата: 13.06.08 12:09
Оценка:
Здравствуйте, Ligen, Вы писали:

L>по своему опыту, у нормального человека довольно редко возникает необходимость засунуть в программу в поле ввода, скажем "бабло:" значение "NAN"

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

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

имхо нужно понимать на входе обе десятичные точки и не пользовать запятую в качестве разделителя
Re[4]: Kluev - вон из профессии
От: anc  
Дата: 13.06.08 13:02
Оценка:
Здравствуйте, boost, Вы писали:

K>>
K>>int num_parse
K>>


мдаа... -1 за int
Kluev, поставь мне тоже
Re[5]: Kluev - вон из профессии
От: Kluev  
Дата: 13.06.08 13:26
Оценка:
Здравствуйте, anc, Вы писали:

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


K>>>
K>>>int num_parse
K>>>


anc>мдаа... -1 за int

anc>Kluev, поставь мне тоже

суть претензий сначала обьясни.
я вижу лишь, что любителям буста "концептуальная чистота" гораздо важнее быстродействия и качества кода.
Re[6]: Kluev - вон из профессии
От: anc  
Дата: 13.06.08 13:34
Оценка:
Здравствуйте, Kluev, Вы писали:


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


тип возврата num_parse() int?
Re[7]: Kluev - вон из профессии
От: anc  
Дата: 13.06.08 13:45
Оценка: +1
туплю
Re[3]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 13.06.08 13:54
Оценка: +2
Здравствуйте, 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 "вон из профессии". Это замечательные вещи для *общего случая*. А для каждой конкретной ситуации, конечно, можно сделать более быстро.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 14:11
Оценка: -1
Здравствуйте, remark, Вы писали:

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


для *общего случая* есть языки попроще С++
Re[5]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 13.06.08 14:17
Оценка: +3
Здравствуйте, Kluev, Вы писали:

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


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


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


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


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: boost - вон из профессии
От: CreatorCray  
Дата: 13.06.08 14:43
Оценка:
Здравствуйте, Programador, Вы писали:

P>поддержка НАН логична

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

P>+-НАН

Нет такого кадавра в стандарте IEEE
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 14:46
Оценка: -3
Здравствуйте, 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<>>
и т.д и т.п.
Re[7]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 13.06.08 15:20
Оценка: +3
Здравствуйте, 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...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 15:58
Оценка: -1
Здравствуйте, 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 и выделению памяти через самописный пул. Т.е. гарантия масштабируемости обеспечена с самого начала разработки.
Re[8]: boost - вон из профессии
От: Programador  
Дата: 13.06.08 16:53
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


P>>поддержка НАН логична

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

P>>+-НАН

CC>Нет такого кадавра в стандарте IEEE
не знаю как в стандарте но по факту знаковый бит никуда не девается и выводится +Nan и -Nan Вводится исключительно Nan со знаком
scanf printf
Re[9]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 13.06.08 17:07
Оценка: 3 (2) +2
Здравствуйте, 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 там тоже есть.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: мы мним себя в наполеоны...(с)
От: Programador  
Дата: 13.06.08 17:15
Оценка:
Здравствуйте, 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;
}

здесь проверил как работает
Re[3]: мы мним себя в наполеоны...(с)
От: remark Россия http://www.1024cores.net/
Дата: 13.06.08 17:24
Оценка:
Здравствуйте, Programador, Вы писали:

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


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

_>>Сделайте что-то такое же удобное, и безопасное

P>насчет удобства ИМХО через операторы удобней


P>
P>#include <iostream>
P>struct Lexical_cast
P>{  char *v;
P>   Lexical_cast(char *v):v(v){}
P>   operator int    () {return 1;}
P>   operator float  () {return 2;}
P>   operator double () {return 3;}
P>};
P>



Для такой штуки надо ещё перегрузить оператор сложения с std::basic_string<> и char_t const*, что б можно было писать:
std::string s = "number = " + Lexical_cast(3.14) + s2 + Lexical_cast(x);


Тогда совсем замечательно получается.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: boost - вон из профессии
От: Аноним  
Дата: 13.06.08 17:47
Оценка:
Если вы считаете что качество вашего кода вот тут вот высокое —
http://www.rsdn.ru/forum/message/2986004.1.aspx
Автор: Kluev
Дата: 13.06.08

Вы очень ошибаетесь. Так вообще давно не пишут.
Re[4]: boost - вон из профессии
От: Roman Odaisky Украина  
Дата: 13.06.08 17:59
Оценка:
Здравствуйте, alexeiz, Вы писали:

K>>Кстати, в недрах этого чуда несколько раз вызывается new, поэтому производительность в реальных условиях будет еще сильно зависить от состояния кучи.


A>Странный ты человек. Взгляни хоть на профайл один раз. Где там вызывается new?


Есть там new. Впрочем, у меня new вылазит иначе, чем у Клюева:

(gdb) break malloc
Breakpoint 2 at 0xb7cdcf36
(gdb) continue
Continuing.

Breakpoint 2, 0xb7cdcf36 in malloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7cdcf36 in malloc () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7ea56a7 in operator new () from /usr/lib/libstdc++.so.6
#2 0xb7e7f8c1 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6
#3 0xb7e805a8 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#4 0xb7e811b8 in std::string::reserve () from /usr/lib/libstdc++.so.6
#5 0xb7e7a5b3 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () from /usr/lib/libstdc++.so.6
#6 0xb7e7eecb in std::basic_streambuf<char, std::char_traits<char> >::xsputn () from /usr/lib/libstdc++.so.6
#7 0xb7e755af in std::__ostream_insert<char, std::char_traits<char> > () from /usr/lib/libstdc++.so.6
#8 0xb7e757ac in std::operator<< <std::char_traits<char> > () from /usr/lib/libstdc++.so.6
#9 0x08048ba7 in boost::detail::lexical_stream<double, char const*>::operator<< (this=0xbff63d98, input=@0xbff63e6c)
at /usr/include/boost/lexical_cast.hpp:151
#10 0x08048cf5 in boost::lexical_cast<double, char [4]> (arg=@0x8048ef7) at /usr/include/boost/lexical_cast.hpp:222
#11 0x0804899c in main () at lexical_cast.cpp:10
(gdb) continue
Continuing.

Breakpoint 2, 0xb7cdcf36 in malloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7cdcf36 in malloc () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7cdcf65 in malloc () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7ea56a7 in operator new () from /usr/lib/libstdc++.so.6
#3 0xb7e7f8c1 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6
#4 0xb7e805a8 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#5 0xb7e811b8 in std::string::reserve () from /usr/lib/libstdc++.so.6
#6 0xb7e7a5b3 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () from /usr/lib/libstdc++.so.6
#7 0xb7e7eecb in std::basic_streambuf<char, std::char_traits<char> >::xsputn () from /usr/lib/libstdc++.so.6
#8 0xb7e755af in std::__ostream_insert<char, std::char_traits<char> > () from /usr/lib/libstdc++.so.6
#9 0xb7e757ac in std::operator<< <std::char_traits<char> > () from /usr/lib/libstdc++.so.6
#10 0x08048ba7 in boost::detail::lexical_stream<double, char const*>::operator<< (this=0xbff63d98, input=@0xbff63e6c)
at /usr/include/boost/lexical_cast.hpp:151
#11 0x08048cf5 in boost::lexical_cast<double, char [4]> (arg=@0x8048ef7) at /usr/include/boost/lexical_cast.hpp:222
#12 0x0804899c in main () at lexical_cast.cpp:10
(gdb) continue
Continuing.

Breakpoint 2, 0xb7cdcf36 in malloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7cdcf36 in malloc () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7ea56a7 in operator new () from /usr/lib/libstdc++.so.6
#2 0xb7e7f8c1 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6
#3 0xb7e805a8 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#4 0xb7e811b8 in std::string::reserve () from /usr/lib/libstdc++.so.6
#5 0xb7e6de2c in std::num_get<char, std::istreambuf_iterator<char, std::char_traits<char> > >::do_get () from /usr/lib/libstdc++.so.6
#6 0xb7e53927 in std::istream::_M_extract<double> () from /usr/lib/libstdc++.so.6
#7 0xb7e539c4 in std::istream::operator>> () from /usr/lib/libstdc++.so.6
#8 0x08048bdd in boost::detail::lexical_stream<double, char const*>::operator>><double> (this=0xbff63d98, output=@0xbff63e60)
at /usr/include/boost/lexical_cast.hpp:166
#9 0x08048d11 in boost::lexical_cast<double, char [4]> (arg=@0x8048ef7) at /usr/include/boost/lexical_cast.hpp:222
#10 0x0804899c in main () at lexical_cast.cpp:10
(gdb) continue
Continuing.

Program exited normally.

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

Кстати, что в C++09 есть на тему преобразований строка — число?
До последнего не верил в пирамиду Лебедева.
Re[10]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 19:41
Оценка: +1 -1
Здравствуйте, remark, Вы писали:

R>LOL

R>Списки — это во многих случаях очень сильно не оптимальная структура.
ORLY?

R>1. Переход по указателям. Эффективно не поддерживается современным аппаратным обеспечением. Программы активно оперирующие указателями сейчас работают, допустим, с CPI=2, вместо максимальных CPI=0.3. Она может работать в 10 раз медленнее std::vector на переборе элементов.

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

R>О поиске и говорить нечего.

Аналогично несортированному вектору указателей.

R>2. Не локальные обращения к памяти. Эффективно не поддерживается современным аппаратным обеспечением. Могут замедлять работу программы до 10 раз.

R>3. Увеличение потребления памяти. С каждым узлом надо хранить 2 указателя (что бы хоть как-то выгодно отличаться от массива нам нужны двух-связанные списки). Если взять предельный случай: храним один char (1 байт) + 2 указателя (на 64-битной машине = 16 байт) = 94% места под вспомогательные данные.
Ерунда полная. 1 байт в интрузивный список никто не положит. Как правило в таких списках лежат полиморфные обьекты среднего размера.
Опять же в "вычислительном" списке можно вместо указатей использовать индексы, а выделенные элементы хранить в одном непрерывном массиве.

R>Помимо увеличенного потребления памяти, как следствие, это может привести к тому, что workset программы перестанет влезать в кэш какого-то уровня.

А злоупотребление массивами приводит к фрагментации памяти и в конечном итоге невозможности выделения больших непрерывных кусков.
Обьекты списка легко положить в пул и таким образом полностью ликвидировать проблему фрагментации. Для векторов переменного размера приходится использовать стандартный heap со всеми вытекающими последствиями.

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

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

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

intrusive там все еще на стадии одобрения и для меня он уже опоздал года на три.
Re[11]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 13.06.08 19:50
Оценка:
Здравствуйте, Kluev, Вы писали:

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

K>intrusive там все еще на стадии одобрения и для меня он уже опоздал года на три.

Он уже давно принят, интергирован в инстллятор, а документация интегрирована в основной сайт:
http://www.boost.org/doc/libs/1_35_0/doc/html/intrusive.html


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 19:51
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Если вы считаете что качество вашего кода вот тут вот высокое -

А>http://www.rsdn.ru/forum/message/2986004.1.aspx
Автор: Kluev
Дата: 13.06.08

А>Вы очень ошибаетесь. Так вообще давно не пишут.

этот код работает быстрее crt и при этом он лишен ее недостатков.
именно для этого он был и написан, а не для того чтобы заслужить одобрение анонимусов в форуме.
если вам нравится эстетически красивый код и плевать на производительность советую присмотрется к другим языкам
типа C#, java, pyton и т.п. и больше не мучатся с уродливым С++.
Re[12]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 19:55
Оценка:
Здравствуйте, remark, Вы писали:

R>Он уже давно принят, интергирован в инстллятор, а документация интегрирована в основной сайт:

R>http://www.boost.org/doc/libs/1_35_0/doc/html/intrusive.html

для меня не актуально. я уже давным давно уехал на своих велосипедах.
Re[11]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 13.06.08 20:09
Оценка: +1
Здравствуйте, Kluev, Вы писали:


R>>LOL

R>>Списки — это во многих случаях очень сильно не оптимальная структура.

K>ORLY?


Абсолютно.
Ты показал только то, что вектор может быть плох для некоторых ситуаций, и то, что список может быть хорош для некоторых ситуаций. С этим никто не спорит. Но в то же время это никак не опровергает то, что вектор — выбор по-умолчанию.


R>>1. Переход по указателям. Эффективно не поддерживается современным аппаратным обеспечением. Программы активно оперирующие указателями сейчас работают, допустим, с CPI=2, вместо максимальных CPI=0.3. Она может работать в 10 раз медленнее std::vector на переборе элементов.

K>Ничем не медленее вектора указателей или смартпоинтеров. Выигриш только в том случае если в векторе обьект лежит по значению,
K>что используется в основном для вещей вычислительных. Полиморфный обьект в вектор по значению не положишь.

Согласен.


R>>О поиске и говорить нечего.

K>Аналогично несортированному вектору указателей.

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


R>>2. Не локальные обращения к памяти. Эффективно не поддерживается современным аппаратным обеспечением. Могут замедлять работу программы до 10 раз.


R>>3. Увеличение потребления памяти. С каждым узлом надо хранить 2 указателя (что бы хоть как-то выгодно отличаться от массива нам нужны двух-связанные списки). Если взять предельный случай: храним один char (1 байт) + 2 указателя (на 64-битной машине = 16 байт) = 94% места под вспомогательные данные.

K>Ерунда полная. 1 байт в интрузивный список никто не положит.

Именно.
Тем не менее, иногда надо где-то хранить и один байт.


K>Как правило в таких списках лежат полиморфные обьекты среднего размера.

K>Опять же в "вычислительном" списке можно вместо указатей использовать индексы, а выделенные элементы хранить в одном непрерывном массиве.

Именно.
Потому что массив хорош.


R>>Помимо увеличенного потребления памяти, как следствие, это может привести к тому, что workset программы перестанет влезать в кэш какого-то уровня.

K>А злоупотребление массивами приводит к фрагментации памяти и в конечном итоге невозможности выделения больших непрерывных кусков.
K>Обьекты списка легко положить в пул и таким образом полностью ликвидировать проблему фрагментации. Для векторов переменного размера приходится использовать стандартный heap со всеми вытекающими последствиями.

Если у тебя полиморфные объекты в списке (читай разного размера), то тоже может быть фрагментация.


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

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


Обычно векторы не перевыделяют память, если уменьшаются. Поэтому периоодических ресайзов быть не может. Вектор просто достигает своего подходящего размера. Если сделать reserve(), то вообще никаких перевыделений не будет.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[12]: boost - вон из профессии
От: Kluev  
Дата: 13.06.08 20:56
Оценка: :)
Здравствуйте, remark, Вы писали:

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


R>Если у тебя полиморфные объекты в списке (читай разного размера), то тоже может быть фрагментация.

нет, число типов ограниченно, соотвественно и ограниченно число размеров. на каждый тип или на размер свой пул. поэтому фрагментации нет в принципе. вектор имеет непредсказуемую длинну поэтому с ним все гораздо сложнее.

R>Обычно векторы не перевыделяют память, если уменьшаются. Поэтому периоодических ресайзов быть не может. Вектор просто достигает своего подходящего размера. Если сделать reserve(), то вообще никаких перевыделений не будет.


если их много, например больше 100к, то само выделение уже может быть проблемой.
Re[12]: boost - вон из профессии
От: Аноним  
Дата: 14.06.08 00:30
Оценка: :)
K>этот код работает быстрее crt и при этом он лишен ее недостатков.
K>именно для этого он был и написан, а не для того чтобы заслужить одобрение анонимусов в форуме.
"Быстрее" это далеко не единственная обязанность кода. Код прежде всего должен быть ЧИТАЕМ человеком. Выгода от бОльшего количества продаж продукта, использующего ваш более быстрый вариант, будет съедена зарплатой 10 поколений индусов, поддерживающих и развивающих потом этот код. Подумайте над этим.
Re[13]: boost - вон из профессии
От: CreatorCray  
Дата: 14.06.08 07:08
Оценка:
Здравствуйте, <Аноним>, Вы писали:

K>>этот код работает быстрее crt и при этом он лишен ее недостатков.

K>>именно для этого он был и написан, а не для того чтобы заслужить одобрение анонимусов в форуме.
А>"Быстрее" это далеко не единственная обязанность кода. Код прежде всего должен быть ЧИТАЕМ человеком. Выгода от бОльшего количества продаж продукта, использующего ваш более быстрый вариант, будет съедена зарплатой 10 поколений индусов, поддерживающих и развивающих потом этот код. Подумайте над этим.
Оформление кода как раз не проблема. Переформатировал, переменные/функции переназвал и все.
А вот если алгоритм изначально плохой то тут надо выбрасывать и писать по новой.
Тем более что у автора написано вроде как на plain C
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: boost - вон из профессии
От: CreatorCray  
Дата: 14.06.08 07:08
Оценка: +1
Здравствуйте, Programador, Вы писали:

P>>>поддержка НАН логична

CC>>NaN это сигнализация об ошибке в вычислениях. Выводить ее еще понятно зачем. Но на кой ее поддерживать для ввода?
P>для ввода текстовых файлов выведенных другой программой
1) Нет легального способа присвоить IEEE fp значение NaN кроме как через неправильные вычисления, приводящие к NaN.
2) Нет никакого смысла использовать NaN в вычислениях. Любые вычисления с участием NaN в результате дадут NaN
3) NaN это индикация ОШИБКИ а не значение. И на него требуется реакция как на ошибку а не чтение как значения.
4) Вы в курсе что кроме записи "NaN" есть еще и "sNaN" и "qNaN". Что с ними делать? Тоже поддерживать? А CRT от MS выводит не NaN а IND — с этой самодеятельностью что делать?

P>>>+-НАН

CC>>Нет такого кадавра в стандарте IEEE
P>не знаю как в стандарте но по факту знаковый бит никуда не девается и выводится +Nan и -Nan Вводится исключительно Nan со знаком
P>scanf printf
Выводится кстати неправильно.
Есть стандарт IEEE 754 по которому NaN знака не имеет. Да и как вы себе представляете "знак NaN"? Вспомните как NaN получается и что означает.
Заморочки CRT — мимо кассы.

Кстати ради интереса:
void foo()
{
    char buf[64];
    float v1 = pow (10.0,1000000);
    float v2;

    v1 += -v1;    // Create qNaN

    crprintf (L"%f\n",v1);
    printf ("%f\n",v1);

    sprintf (buf,"%f",v1);
    sscanf (buf,"%f",&v2);

    printf ("%s -> %f\n",buf,v2);
}


Вот что выводит:

qNaN
-1.#IND00
-1.#IND00 -> -1.000000
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: boost - вон из профессии
От: Аноним  
Дата: 14.06.08 09:19
Оценка:
CC>Оформление кода как раз не проблема. Переформатировал, переменные/функции переназвал и все.
Дело не в форматировании. А в вещах типа разделения кода на функционально независимые и реюзабельные куски (функция у топик стартера — ужас какая длинная). Ясность и декларативность логики (в приведенном коду — куча переменных, goto (!!!)). И то все это формальные понятия. Реально если я смотрю на функцию больше 10..20 сек и все еще возникают вопросы тип "а че вот ето такое?" — значит код хреново понимается среднестатическим человеком, а гениев нанимать — дорогое удовольствие

CC>А вот если алгоритм изначально плохой то тут надо выбрасывать и писать по новой.

CC>Тем более что у автора написано вроде как на plain C
Ну дык на plain C ннче пишут тока драйвера, софт под контроллеры и опенсурс, который гордится своей компилируемостью под всем. Какой вообще смысл в сравнению буста с Сшным кодом?
Re[13]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 14.06.08 09:32
Оценка: +1
Здравствуйте, Kluev, Вы писали:


R>>Обычно векторы не перевыделяют память, если уменьшаются. Поэтому периоодических ресайзов быть не может. Вектор просто достигает своего подходящего размера. Если сделать reserve(), то вообще никаких перевыделений не будет.


K>если их много, например больше 100к, то само выделение уже может быть проблемой.



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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: boost - вон из профессии
От: Programador  
Дата: 14.06.08 16:42
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Вот что выводит:


CC>
CC>qNaN
CC>-1.#IND00
CC>-1.#IND00 -> -1.000000
CC>

посмотрел проект стандарта — текстовое представление не определено, нет ни #IND ни NaN , кстати есть макрос FP_NAN
MSDN тоже вроде обходит этот вопрос.

А вот в exel работает и импорт и экспорт http://support.microsoft.com/kb/78113/ru



здесь
Автор: Дядюшка Че
Дата: 07.01.06
функция разбора действительных чисел на чистом C++
Re[14]: boost - вон из профессии
От: Kluev  
Дата: 14.06.08 17:20
Оценка:
Здравствуйте, remark, Вы писали:

R>Ну по крайней мере одно выделение памяти под множество элементов не может быть большей проблемой, чем отдельные выделения каждого элемента.


Мы просто о разных вещах говорим. Ты видимо пытаешься сравить вектор простых копируемых типов с интрузивным списком простых типов.
Естественно в этой ситуации вектор будет лучше в 90% случаев. Если у нас полиморфные некопируемые типы, то сравнивать нужно с вектором указателей или c популярным vector<shared_ptr<>>
Re[15]: boost - вон из профессии
От: Kluev  
Дата: 14.06.08 17:24
Оценка:
Здравствуйте, Аноним, Вы писали:

CC>>Оформление кода как раз не проблема. Переформатировал, переменные/функции переназвал и все.

А>Дело не в форматировании. А в вещах типа разделения кода на функционально независимые и реюзабельные куски (функция у топик стартера — ужас какая длинная). Ясность и декларативность логики (в приведенном коду — куча переменных, goto (!!!)). И то все это формальные понятия. Реально если я смотрю на функцию больше 10..20 сек и все еще возникают вопросы тип "а че вот ето такое?" — значит код хреново понимается среднестатическим человеком, а гениев нанимать — дорогое удовольствие

Код, между прочим, элементарный. Та всего три простых цикла — это и понимать нечего.
В отличии, например, от математических алогритмов где функцию из 10 строк невозмоно понять без специального образования.
Re[15]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 14.06.08 17:41
Оценка:
Здравствуйте, Kluev, Вы писали:

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


R>>Ну по крайней мере одно выделение памяти под множество элементов не может быть большей проблемой, чем отдельные выделения каждого элемента.


K>Мы просто о разных вещах говорим. Ты видимо пытаешься сравить вектор простых копируемых типов с интрузивным списком простых типов.

K>Естественно в этой ситуации вектор будет лучше в 90% случаев. Если у нас полиморфные некопируемые типы, то сравнивать нужно с вектором указателей или c популярным vector<shared_ptr<>>


Не обязательно простых типов. Это может быть что-то типа:
struct person
{
  int id;
  std::string first_name;
  std::string last_name;
  int age;
  address_info address;
  document_info doc;
};



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[16]: boost - вон из профессии
От: Kluev  
Дата: 14.06.08 18:59
Оценка:
Здравствуйте, remark, Вы писали:

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


R>Не обязательно простых типов. Это может быть что-то типа:

R>
R>struct person
R>{
R>  int id;
R>  std::string first_name;
R>  std::string last_name;
R>  int age;
R>  address_info address;
R>  document_info doc;
R>};
R>


Это все хорошо пока снаружи нет ссылок на person. а если они потребуются, то указатели использовать, нельзя индексы тоже могуть "уплыть". Единственый гарантированный способ достучатся до person — уникальный id и поиск по всему вектору при каждом обращении.
Имхо такая схема настолько неудобна, что не стоит того выигрыша в производительности который она даст (если этот выигрыш кончано find не сожрет).
Re[16]: boost - вон из профессии
От: Аноним  
Дата: 15.06.08 13:01
Оценка: :)
K>Код, между прочим, элементарный. Та всего три простых цикла — это и понимать нечего.
Его просто вы писали. Впрочем это неважно, у меня простой критерий — если я понять функцию спинным мозгом не могу, а необходимо напрягать головной — то значит стиль хреновый
Re[6]: boost - вон из профессии
От: minorlogic Украина  
Дата: 15.06.08 15:21
Оценка:
Здравствуйте, 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.

По теме топике у меня основная мысль одна. Перед использованием инструмента неплохо было бы ознакомится с ним , а не писать что микроскоп хуже забивает гвозди чем самодельный каменный топор.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[10]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 15.06.08 15:46
Оценка: 1 (1) +3
Здравствуйте, CreatorCray, Вы писали:

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


Z>>Ну скажем не NAN, a INF. Хотя в каком-нибудь столбце вполне может стоит и NAN, и далеко не факт что это ошибка, и совершенно точно парсер от такого падать не должен.

CC>А с чего вдруг ему падать? Откуда такая уверенность что самописное априори хуже библиотечного? Библиотеки по сути такое же сборище велосипедов, и все гарантии качества только на совести их разработчиков и тестеров.
CC>Качество кода (велосипеда или буста или CRT или еще чего) определяется ровностью рук и качеством мозгов программера, их написавшего, и тестера их оттестировавшего.

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

You will always get what you always got
  If you always do  what you always did
Re[7]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 15.06.08 15:51
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

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


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

Естественно, вначале ты пишешь программу с использованием этих удобных вещей, ибо писать с ними можно довольно быстро, но потом профилируешь — и меняешь на что-нть более быстродействующее.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: boost - вон из профессии
От: minorlogic Украина  
Дата: 15.06.08 16:01
Оценка: :)
Здравствуйте, 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>Естественно, вначале ты пишешь программу с использованием этих удобных вещей, ибо писать с ними можно довольно быстро, но потом профилируешь — и меняешь на что-нть более быстродействующее.


ЗюЫю Да это сарказм.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[9]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 15.06.08 16:15
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Нет, не сталкивался ни разу.

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

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


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


Вижу, что сарказм, но вот смысл его от меня ускользает.
Ты чего сказать хотел-то?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: boost - вон из профессии
От: Kluev  
Дата: 15.06.08 16:18
Оценка: +4 -1
Здравствуйте, minorlogic, Вы писали:

M>2. При обнаружении факта что логирование тормозит я бы подумал о 2х решениях.

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

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

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

Какой смысл тогда вообще мучатся с С++?

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


да какой там микроскоп, как работает lexical_cast? создает класс наследный от iostream запихивает в него входной параметр и читает выходной. это обычный быдлокод со всеми вытекающими malloc/free последствиями. В рабочем коде накиданном на скорую руку такое еще приемлемо, а в библиотеках, имхо, качество кода должно быть на порядок выше.
Re[8]: boost - вон из профессии
От: Kluev  
Дата: 15.06.08 16:26
Оценка: +1
Здравствуйте, 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 удобство так и прет
Re[10]: boost - вон из профессии
От: minorlogic Украина  
Дата: 15.06.08 16:43
Оценка:
Здравствуйте, jazzer, Вы писали:

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

J>Ты чего сказать хотел-то?

Что у меня они не тормозят не потому что я не знаю об их устройстве , а потому что я не использую инстркменты не по назначени.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[8]: boost - вон из профессии
От: minorlogic Украина  
Дата: 15.06.08 17:01
Оценка: +1
Здравствуйте, 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 последствиями. В рабочем коде накиданном на скорую руку такое еще приемлемо, а в библиотеках, имхо, качество кода должно быть на порядок выше.


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

Если же у тебя душа болит за бустовские библиотеки и ты реально думаешь что можешь написать лучше , постарайся внести свои решения в состав буста . Если они пройдут довольно жесткий ревью , тогда ты принесешь пользу всему комьюнити и дашь авторам библиотек буст новый ориентир на качество кода.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[9]: boost - вон из профессии
От: Kluev  
Дата: 15.06.08 17:59
Оценка: 1 (1) +2
Здравствуйте, 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<>> гораздо тормознее чем аналогичные вещи в шарпе и яве. И программа написанная в стиле буст "заткнется" гораздо быстрее чем аналогичная на шарпе. Хотя бы из-за фрагментации кучи вызванной бездарным использованием оперативной памяти. Просто есть класс задач которые все равно на чем писать. А по качеству реализации буст библиотека именно этого уровная — "все равно как сделано".
Re[11]: boost - вон из профессии
От: Erop Россия  
Дата: 15.06.08 20:27
Оценка:
Здравствуйте, minorlogic, Вы писали:

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

А в чём проблема?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: boost - вон из профессии
От: Erop Россия  
Дата: 15.06.08 20:34
Оценка:
Здравствуйте, Аноним, Вы писали:

K>>Код, между прочим, элементарный. Та всего три простых цикла — это и понимать нечего.

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

Интересно бы узнать, что конкретно вызвало затруднения?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: boost - вон из профессии
От: Аноним  
Дата: 15.06.08 20:44
Оценка:
E>Интересно бы узнать, что конкретно вызвало затруднения?
Слишком много субьектов для содержания в памяти — человек в мозгу может удерживать на лету порядка 7ми объектов — по мнению психологов. Так что если в функции больше 7м циклов, переменных, переходов и прочих самостоятельных сущностей — эта функция сложна для восприятия. (тоже самое кстати можно сказать про классы и далее двигаяь по дереву абстракций). Мозг нужно задействовать для восприятия общей архитектуры, функции же, как абстаркции 1го уровня, должны читаться "сходу". Кстати учтите что для профи for_each например воспринимается проще, нежели for(;), реализующй функционал foreach.
Re[19]: boost - вон из профессии
От: Erop Россия  
Дата: 15.06.08 21:43
Оценка: +1
Здравствуйте, Аноним, Вы писали:

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

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

А>Кстати учтите что для профи for_each например воспринимается проще, нежели for(;), реализующй функционал foreach.

IMHO? tckb xedак пишет на С++ и испытывает затруднения с чтением конструкции for(;), то он кто угодно, но не профи
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: boost - вон из профессии
От: Аноним  
Дата: 15.06.08 21:51
Оценка: +1
А>>Слишком много субьектов для содержания в памяти — человек в мозгу может удерживать на лету порядка 7ми объектов — по мнению психологов. Так что если в функции больше 7м циклов, переменных, переходов и прочих самостоятельных сущностей — эта функция сложна для восприятия. (тоже самое кстати можно сказать про классы и далее двигаяь по дереву абстракций). Мозг нужно задействовать для восприятия общей архитектуры, функции же, как абстаркции 1го уровня, должны читаться "сходу".
E>Это не ответ на мой вопрос. Я про конкретную функцию спросил, если не понятно...
Понимаете ли, еслиб вы смотрели сцылку которую я привел, вы бы заметили что там всего ОДНА функция длиной 160 строчек. Для справки — у нас на проектах принятно ограничение (правда скорее ориентировочное, нежели обязательное) — 40 строчек.

А>>Кстати учтите что для профи for_each например воспринимается проще, нежели for(;), реализующй функционал foreach.

E>IMHO? tckb xedак пишет на С++ и испытывает затруднения с чтением конструкции for(;), то он кто угодно, но не профи
for(;) в отличии от for_each требует понимания того что это именно проход по некоей последовательности. Дело не в заструднении понимания, а в очевидности и декларативности поведения написанного кода. Это не столько уменьшает время для понимания кода, сколько уменьшает вероятность совершения ошибки при его модификации.
Re[21]: boost - вон из профессии
От: Erop Россия  
Дата: 15.06.08 22:15
Оценка: -2
Здравствуйте, Аноним, Вы писали:

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
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: boost - вон из профессии
От: landerhigh Пират  
Дата: 15.06.08 23:05
Оценка:
Здравствуйте, Erop, Вы писали:

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


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

Это не говоря о кошмарном форматировании и диковато выглядящей сигнатуре функции.
www.blinnov.com
Re: boost - вон из профессии
От: landerhigh Пират  
Дата: 15.06.08 23:10
Оценка:
Здравствуйте, Kluev, Вы писали:

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


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

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


P.S. 2 Kluev — твой код банально не прошел бы code review во всех конторах, где я работал.
www.blinnov.com
Re[19]: boost - вон из профессии
От: Erop Россия  
Дата: 15.06.08 23:23
Оценка: +1
Здравствуйте, 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 как-то не так, советую почитать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: boost - вон из профессии
От: Erop Россия  
Дата: 15.06.08 23:25
Оценка:
Здравствуйте, landerhigh, Вы писали:

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

Это, кстати, правда. Так писать сейчас не принято. Но не ясно почему этот код низкого качества.
Лично у меня к нему есть две существенные претензии
1) Мало комментариев
2) Мало (вернее нет) assert'ов.

Но и то, обе претензии, IMHO, обсуждаемы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: boost - вон из профессии
От: landerhigh Пират  
Дата: 16.06.08 00:31
Оценка:
Здравствуйте, Erop, Вы писали:

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


L>>1. Абсолютно неочевидно, асилит ли код шестнадцатиричные числа.

E>IMHO понятно, что выдаст ошибку. При этом не ясно зачем бы float point numbers шестнадцатиричными числами записывать? Это кто-то вообще делает?
Видимо, нет. Но код возврата функции навевает на мысли, что парсим целое число. И лишь внимательное рассмотрение сигнатуры показывает, что это не так.
L>>2. Неясно, что будет, если разделитель — запятая.
E>Ошибка формата будет. Тоже вроде как ясно...
А если надо пофискить?
L>>4. Зачем goto? Можно ли без?
E>Наверное можно. В чём неясность я не понял.
L>>5. Что за сравнение с 'E' и 'D' в середине?
E>Экспоненциальная запись числа, вестимо (что-то типа 1.17e-8)
Если юзер вдруг пробел между e и -8 ввел, что будет? Из кода совершенно не понятно.
L>>6. А вдруг юникод?
E>А вдруг суахили?
Вопрос в том, скольких усилий будет стоить адаптация функции?
L>>Это не говоря о кошмарном форматировании и диковато выглядящей сигнатуре функции.
E>Просто C-style. Если думаешь, что в crt как-то не так, советую почитать
CRT вместе с C-style трудно назвать образцами юзабилити и читаемости.
www.blinnov.com
Re[11]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 16.06.08 00:56
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

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


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

J>>Ты чего сказать хотел-то?

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


Интересно, как можно использовать строки не по назначению?

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

Я так не умею, я профайлером пользуюсь.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 16.06.08 01:08
Оценка:
Здравствуйте, Kluev, Вы писали:

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


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

K>имхо, лучше сразу использовать полноценные вещи.


серебряной пули нет.

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

K>ага, из std::string удобство так и прет

Для 90% моих задач (сохранил и забыл) — действительно, так и прет.
А если у меня задача — строкодробилка, я использую специализированные средства, в зависимости от конкретной задачи.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[21]: boost - вон из профессии
От: Erop Россия  
Дата: 16.06.08 07:33
Оценка: +1
Здравствуйте, 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 трудно назвать образцами юзабилити и читаемости.
Мы вроде о КАЧЕСТВЕ кода говорили, а не о юзабилити?

В чём проблемы с читабельностью, что в известных мне рантаймах, что в этом коде я так и не понял. И в рантаймах и в этой функции я легко разобрался. Чего не скажешь о многих известных мне образцах "качественного" кода
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.06.08 07:43
Оценка: 1 (1) +3 -1
Здравствуйте, minorlogic, Вы писали:

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


Я не знаю принципиальных причин, по которым специализированные парсеры не могут использовать вещи типа std::string или std::vector<char> в своей реализации. Более того, применение средств STL может быть более удобным и эффективным, чем ручное управление динамической памятью через new/delete.

По этим же соображениям написанные вручную "самописные велосипеды", заточенные под конкретную задачу, могут быть не менее эфективными, чем специализированные парсеры на основе бизона или спирита. Даже с использованием std:string внутри.

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

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

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

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


По теме топика вы высказали одну очень неоднозначную вещь:

"boost::lexical_cast" даже по названию может прити в голову что это не инструмент конвертирования строки в дабл а некий универсальный преобразователь типов.

Почему "универсальный преобразователь типов" не является "инструментом конвертирования строки" в дабл?

Я совершенно не согласен с топикстартером в его категоричности и тем более с заголовком топика, тем более что речь идет всего об одной экзотической вещи -- lexical_cast. Но две вещи заставляют меня возражать опонентам Kluev-а:

1. Если C++ сейчас выживает в области высокоскоросных и малоресурсоемких приложений, то очень странным выглядит наличие lexical_cast, который (по крайней мере в первых версиях) очень небрежно относится как к ресурсам, так и к скорости (создание stringstream-ов на каждое обращение к lexical_cast). Над lexical_cast-ом нужно большими буквами писать предупреждение: "Жрет ресурсы!". И чем больше будет таких предупреждений, тем лучше. Поэтому критика Kluev-а по поводу скорости lexical_cast-а в одной конкретной операции -- это хорошо. Гораздо хуже, если бы кто-то решился по незнанию использовать lexical_cast, например, при парсинге csv-файлов, а потом удивлялся, почему Ruby на этой же операции рвет C++.

2. Возражения Kluev-у носят характер "Ты сам дурак" или "Попробуй написать универсальный инструмент лучше, а потом вякай". Сюда же идут и утверждения о том, что char* в современном C++ не место и то, что кто-то не встречался на практике с тормозами STL в каких-то специфических случаях. Имхо, подобные аргументы вовсе не защищают lexical_cast и не демонстрируют правильных сценариев использования lexical_cast.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: boost - вон из профессии
От: landerhigh Пират  
Дата: 16.06.08 07:53
Оценка:
Здравствуйте, 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(), например?
www.blinnov.com
Re[23]: boost - вон из профессии
От: Kluev  
Дата: 16.06.08 08:45
Оценка: -2
Здравствуйте, landerhigh, Вы писали:

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


L>>>>>2. Неясно, что будет, если разделитель — запятая.

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

L>Этот код non-maintainable. Очень страшная реализация конечного автомата. Это я еще к форматированию придираться не начал

ORLY? Этот код понимается за 30 секунд и правится за такое же время. non-maintainable — разные математические и специализированные вещи в которых ты и десять строк не поймешь без специального образования:

void KnotVector::basis_funs_calc(double N[], double u, int i) const
{
    double L[p_max + 1];
    double R[p_max + 1];
    double sv, tmp;
    N[0] = 1.0;
    for ( int j = 1; j <= m_p; j++ )
    {
        L[j] = u - m_vals[i+1-j];
        R[j] = m_vals[i+j] - u;
        sv   = 0.0;
        for ( int r = 0; r < j; r++ )
        {
            tmp  = N[r]/(R[r+1]+L[j-r]);
            N[r] = sv + R[r+1] * tmp;
            sv   = L[j-r]*tmp;
        }
        N[j] = sv;
    }
}


L>Копи-пейст, стало быть? Ну-ну.

Про шаблон читай выше

L>Мы уже вроде договорились, что качество кода тут, мягко говоря, не на высоте.

качество кода это субьективный критерий. обективный критерий — это, например, производительность и по этому критерию моя функция в 45 лучше.

L>Это не говоря о том, что все это выглядит как попытка сделать ядреную пушку, чтобы по комарам стрелять.

L>Что толку от офигенно быстрого парсера, если 99% времени программа висит на select(), например?

А у меня наооборот, представляешь, ни одного селекта, зато на входе текстовые файлы с данными размером по 10-30Мб.
Так можно вообще до абсурда дойти. Одну функцию используем с селоктом, а другую с файлами.
Решение должно быть одно. Качественное и максимально быстрое. А буст не проходит по этим элементарным критериям.
Буст вообще не библиотека, а сплошной цирк. Один xml парзер на spirit чего стоит.
Re[23]: boost - вон из профессии
От: Erop Россия  
Дата: 16.06.08 08:47
Оценка: +1
Здравствуйте, landerhigh, Вы писали:

L>>>А если надо пофискить?

E>>А в какой форме ты бы хотел фиксить? Это таки аналог рантаймовской функции...
L>Как в какой? Пусть правильно обрабатывает как запятую, так и точку.
Ну лично мне кажется, что запятая там -- это ошибка. Но если тебе кажется иначе, то поправить как раз легко.
При этом хорошо бы понять, вадина ли запись ",75", AFAIK невалидна.
В общем находишь в коде строки
  else if ( '.' == c )
и
  if ( '.' != c )

Ну и в одном или в обоих местах ( в зависимости от того, допустимо ли ",75" или "0,75" ) пишешь ещё и
 || ',' == c
и роде как всё...

L>>>Если юзер вдруг пробел между e и -8 ввел, что будет? Из кода совершенно не понятно.

E>>Странно. Мне понятно.
L>Что, прям так сразу и с наскока? Мне этого вот так сразу и не видно. Если, конечно, есть юнит-тест, то можно и не смотреть, с другой стороны.
А что тебе не понятно?
Ищешь строчку
  if ( 'E' == c || 'D' == c || 'e' == c || 'd' == c )
и смотришь что там делают, если один из этих символов нашёлся. Видно что делают -- ждут '-' и цифры, а пробел не ждут. Если встретили что-то нежданное, то делают goto на err_eof или на err_syntax...

L>Этот код non-maintainable. Очень страшная реализация конечного автомата. Это я еще к форматированию придираться не начал

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

L>>>Вопрос в том, скольких усилий будет стоить адаптация функции?

E>>Ну дык ты пока что не пояснил что значит "адаптация". Написать аналог на wchar_t? -- Нисколько не будет стоить. Пишешь копию, где вместо char* используешь wcahr_t*, а перед всеми символьными литералами приписываешь L и всё...
L>Копи-пейст, стало быть? Ну-ну.
1) Поясни, пожалуйста, что ты понимаешь под "адаптация".
2) Как должна происходить "адаптация" кода такой вот функции:
int my_strlen( const char* str_start )
{
    const char cur = str_start;
    for( ; *cur != 0; cur++ ) {
    }
    return cur - str_start;
}


E>>Мы вроде о КАЧЕСТВЕ кода говорили, а не о юзабилити?

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

L>Это не говоря о том, что все это выглядит как попытка сделать ядреную пушку, чтобы по комарам стрелять.

L>Что толку от офигенно быстрого парсера, если 99% времени программа висит на select(), например?
IMHO, это тут офтоп. Если тебе не важна скорость твоей программы, то тебе пофиг на реализацирю таких вещей. Правда, скорее всего, тебе и С++ тогда действительно, в этой задаче, нафиг не упёрся...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: boost - вон из профессии
От: Sergey Россия  
Дата: 16.06.08 10:28
Оценка: 22 (3)
Kluev пишет:

> А у меня наооборот, представляешь, ни одного селекта, зато на входе

> текстовые файлы с данными размером по 10-30Мб.
> Так можно вообще до абсурда дойти. Одну функцию используем с селоктом, а
> другую с файлами.
> Решение должно быть одно. Качественное и максимально быстрое. А буст не
> проходит по этим элементарным критериям.
> Буст вообще не библиотека, а сплошной цирк. Один xml парзер на spirit
> чего стоит.

Скока можно повторять, что буст не библиотека, а куча библиотек. И если
у serialization автор — <beep>, то это не означает что shared_ptr нельзя
использовать.
Posted via RSDN NNTP Server 2.1 beta
запикано слово — Кодт
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[18]: boost - вон из профессии
От: remark Россия http://www.1024cores.net/
Дата: 16.06.08 10:31
Оценка: +1
Здравствуйте, Erop, Вы писали:

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


K>>>Код, между прочим, элементарный. Та всего три простых цикла — это и понимать нечего.

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

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


Ради интереса скомпилировал код MSVC9 c включенным анализатором кода и сделал анализ метрик кода. Результат:

Project: test37547
Type: parse
Member: num_parse(double*, const char**, const char*, const char*) : int
Maintainability Index: 31
Cyclomatic Complexity: 28

Lines of Code: 89


Говорит:

warning: CA1502 : Microsoft.Maintainability : 'parse::num_parse(double*, const char**, const char*, const char*)' has a cyclomatic complexity of 28. Rewrite or refactor the method to reduce complexity to 25.


А так же:

warning C6001: Using uninitialized memory 'val'

на кусок кода:
fp_eof:
  *stop = p;
  tmp = pow( 10., digs );
  *num = neg ? -(tmp * val) : tmp * val;


warning C4701: potentially uninitialized local variable 'val' used

на кусок кода:
    if ( ct & char_t::digit )
      val = val * 10 + (c-'0');
    else
      goto ip_ok;




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[25]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.06.08 10:42
Оценка: +1
Здравствуйте, Sergey, Вы писали:

S>Скока можно повторять, что буст не библиотека, а куча библиотек.


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

И перестать воспринимать его таковым можно будет после того, как буст превратиться во что-нибудь типа CPAN, RubyGems или Maven2 систем дистрибуции библиотек.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: boost - вон из профессии
От: Cyberax Марс  
Дата: 16.06.08 10:48
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>И перестать воспринимать его таковым можно будет после того, как буст превратиться во что-нибудь типа CPAN, RubyGems или Maven2 систем дистрибуции библиотек.

Кстати, это вполне возможно. Boost.Build v2 как раз для такого сценария идеально подходит.
Sapienti sat!
Re[26]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 16.06.08 10:49
Оценка:
Здравствуйте, eao197, Вы писали:

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


S>>Скока можно повторять, что буст не библиотека, а куча библиотек.


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


E>И перестать воспринимать его таковым можно будет после того, как буст превратиться во что-нибудь типа CPAN, RubyGems или Maven2 систем дистрибуции библиотек.


имхо, из этого только релизы имеют отношение к делу.
только вот это будет такой зоопарк, что ты повесишься, потому что глупо делать библиотеки абсолютно независимыми, а возиться с конкретными зависимостями одной версии одной библиотеки от другой версии другой, при том что третья библиотека требует четвертую версию второй библиотеки — нафиг, лучше я буду брать оттестированный релиз, в котором точно все версии всех библиотек совместимы и оттестированы.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[19]: boost - вон из профессии
От: Kluev  
Дата: 16.06.08 11:00
Оценка:
Здравствуйте, remark, Вы писали:

R>Ради интереса скомпилировал код MSVC9 c включенным анализатором кода и сделал анализ метрик кода. Результат:

Интересная вещица, нужно будет попробовать на досуге.

R>

R>warning C6001: Using uninitialized memory 'val'

R>на кусок кода:
R>
R>fp_eof:
R>  *stop = p;
R>  tmp = pow( 10., digs );
R>  *num = neg ? -(tmp * val) : tmp * val;
R>

спасибо, исправил.
Re[26]: boost - вон из профессии
От: Sergey Россия  
Дата: 16.06.08 11:03
Оценка:
eao197 пишет:

> S>Скока можно повторять, что буст не библиотека, а куча библиотек.

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

Т.е., вы считаете, что люди не понимают разницу между одной большой
библиотекой и кучей разных библиотек, распространяемых вместе ("free
peer-reviewed portable C++ source libraries")? Может быть...


> И перестать воспринимать его таковым можно будет после того, как буст

> превратиться во что-нибудь типа CPAN, RubyGems или Maven2 систем
> дистрибуции библиотек.

Было бы неплохо, но боюсь бустоводы этого не потянут.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[27]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.06.08 11:05
Оценка:
Здравствуйте, jazzer, Вы писали:

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


Чтобы проверить твои опасения, хорошо было бы иметь такую возможность. А ее нет. И Boost в своем существующем виде к этому вообще не стремиться.

Между тем, Cyberax рассказывал, что в Java с Maven2 проблем больших нет.
В Ruby с RubyGems так же проблем нет, поскольку везде можно указывать в зависимостях конкретные версии нужных подпроектов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 16.06.08 11:14
Оценка:
Здравствуйте, eao197, Вы писали:

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


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


E>Чтобы проверить твои опасения, хорошо было бы иметь такую возможность. А ее нет. И Boost в своем существующем виде к этому вообще не стремиться.


Сорри, как ты вообще себе представляешь это в рамках С++?
Вот у тебя есть класс А из какой-то библиотеки Х, в Х.1 размер А 8 байт, а в Х.2 — 16 байт.
Теперь подключи библиотеки В и С, которые требуют Х.1 и Х.2 соответственно, и поставь себя на место разработчика/компилятора/линкера.

Через пространсва имен, которые будут включать в себя версию, так, что ли (c соответствующими преобразованиями)?
типа boost_1_34_1::shared_ptr<>(boost_1_35_0::shared_ptr<>)

E>Между тем, Cyberax рассказывал, что в Java с Maven2 проблем больших нет.

E>В Ruby с RubyGems так же проблем нет, поскольку везде можно указывать в зависимостях конкретные версии нужных подпроектов.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[29]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.06.08 11:26
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Сорри, как ты вообще себе представляешь это в рамках С++?


Только через распространение библиотек в исходниках (в виде tar.bz2/gz, через SVN/CVS). С более-менее унифицированной дисциплиной объединения подпроектов в одном проекте.

J>Вот у тебя есть класс А из какой-то библиотеки Х, в Х.1 размер А 8 байт, а в Х.2 — 16 байт.


Сейчас в C++ это можно получить даже для одной и той же версии библиотеки -- достаточно поуправлять размером выравнивания...

J>Теперь подключи библиотеки В и С, которые требуют Х.1 и Х.2 соответственно, и поставь себя на место разработчика/компилятора/линкера.


А это, в принципе, уже и не должно разрешаться. Если X.2 не обеспечивает совместимости по исходникам с X.1, то вряд ли здесь можно найти какое-нибудь универсальное решение. А вот если X.2 обеспечивает совместимость с X.1, то и B, и C в рамках моего проекта D будут работать с X.2.

В конце-концов, сейчас приходится переходить с pcre 7.6 на pcre 7.7, с otl 4.0.169 на 4.0.171, с ace 5.5.10 на 5.6.5 и ничего -- работает.

J>Через пространсва имен, которые будут включать в себя версию, так, что ли (c соответствующими преобразованиями)?

J>типа boost_1_34_1::shared_ptr<>(boost_1_35_0::shared_ptr<>)

Номера версий в пространствах имен -- не самая плохая идея. Если ее не доводить до абсурда в виде boost_1_31_1. Достаточно, например, boost::serialization_1 или boost::lexical_cast_3.

Сам давно пользуюсь системой, в которой в имя самого верхнего пространства имен входит самый старший номер версии (например, oess_1, mbapi_3, mbsms_2). Что позволяет использовать в проектах подпроекты разных поколений (например, сейчас я переводил на новые версии подпроектов проект, в котором одновременно используются mbsms_1 и mbsms_2).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
offtop, parse double
От: minorlogic Украина  
Дата: 16.06.08 11:55
Оценка:
Напомню что использование стандартных потоков не обязывает динамически распределять память.

template<typename parsed_t>
void fromString(const std::string& str, parsed_t& val)
{
   std::stringstream ss(str, ios_base::in);
   ss >> val;
   if (ss.fail( ))
   {
       throw std::runtime_error("\"" + str +"\" can't parse to type: " + typeid(parsed_t).name());
   }
}



template<typename parsed_t>
void fromString(char* str, size_t size, parsed_t& val)
{
    std::strstream ss(str, (std::streamsize)size, ios_base::in);
    ss >> val;
    if (ss.fail( ))
    {
        throw std::runtime_error(std::string("\"") + str +"\" can't parse to type: " + typeid(parsed_t).name());
    }
}


using namespace std;

int main(int argc, char* argv[])
{
    try {
        double d;
        fromString("123", d);
        cout << d << endl;

        char num[] = "65536";
        fromString(num, sizeof(num), d);
        cout << d << endl;


        fromString("bad num", d);
        cout << d << endl;
    }
    catch (exception& e) {
        cerr << e.what() << endl;
    }

    return 0;
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: offtop, parse double
От: Kluev  
Дата: 16.06.08 12:28
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Напомню что использование стандартных потоков не обязывает динамически распределять память.


M>
M>template<typename parsed_t>
M>void fromString(const std::string& str, parsed_t& val)
M>{
M>   std::stringstream ss(str, ios_base::in);
M>   ss >> val;
M>   if (ss.fail( ))
M>   {
M>       throw std::runtime_error("\"" + str +"\" can't parse to type: " + typeid(parsed_t).name());
M>   }
M>}



M>template<typename parsed_t>
M>void fromString(char* str, size_t size, parsed_t& val)
M>{
M>    std::strstream ss(str, (std::streamsize)size, ios_base::in);
M>    ss >> val;
M>    if (ss.fail( ))
M>    {
M>        throw std::runtime_error(std::string("\"") + str +"\" can't parse to type: " + typeid(parsed_t).name());
M>    }
M>}

M>


места где выделяется память выделены.
Re: offtop, parse double
От: minorlogic Украина  
Дата: 16.06.08 12:36
Оценка:
на всякий случай запустил твой тест на 2003 студии 7.1, boost boost_1_33_1, Release
/O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc /ML /GS /Yu"stdafx.h" /Fp"Release/test2.pch" /Fo"Release/" /Fd"Release/vc70.pdb" /W3 /nologo /c /Wp64 /Zi /TP


boost: 3.1415e+006: 3.188
crt: 3.1415e+006: 1.041
stringstream: 3.1415e+006: 2.803
boost: 3.1415e+006: 3.134
crt: 3.1415e+006: 1.041
stringstream: 3.1415e+006: 2.793
boost: 3.1415e+006: 3.158
crt: 3.1415e+006: 1.042
stringstream: 3.1415e+006: 2.791


Довольно странные результаты.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.06.08 12:38
Оценка:
Здравствуйте, Kluev, Вы писали:

K>места где выделяется память выделены.


Не все, есть еще:
template<typename parsed_t>
void fromString(const std::string& str, parsed_t& val)
{ ... }

int main(int argc, char* argv[])
{
    try {
        double d;
        fromString("123", d);

При достаточно большой длине аргумента str в fromString не спасет даже small string optimization, которая имеется в некоторых реализациях STL. Но даже в случаях, когда срабатывает small string optimization происходит копирование литерала (в данном случае "123") во внутренний буфер std::string. Хотя и без этого копирования можно обойтись.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: boost - вон из профессии
От: Кодт Россия  
Дата: 16.06.08 12:50
Оценка: +4
Здравствуйте, eao197, Вы писали:

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


Приводилось wstring. (Двукратный оверхед — UCS-4 там, где был заведомо UCS-2, плюс дерготня менеджера кучи).

Но это не отменяет моих взглядов на лозунг в сабже.

В конце концов, стандартные библиотеки — это хорошее средство прототипирования. Они отлажены и работают по спецификации, возможно, ценой провала скорости и памяти.
Заменить в конкретном месте стандартное решение нестандартным после профилирования — всегда успеешь. (Впрочем, при некотором навыке макаронокодирования можно так крепко завязаться на стандартное, что и не успеешь...) А рожать нестандартное сразу — ну, если дар предвидения хорошо развит.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[19]: boost - вон из профессии
От: FR  
Дата: 16.06.08 13:15
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>3. Куда goto?

L>4. Зачем goto? Можно ли без?

Конечно можно, хотя здесь goto применен вполне культурно. Такую штуку при желании вообще можно переписать без goto без циклов, без изменяемых переменных, полностью в функциональном стиле , притом эффективность не потеряется сейчас только самые ленивые компиляторописатели хвостовую рекурсию не оптимизят, ну и код при этом станет проще и понятнее, правда не для всех
Re[29]: boost - вон из профессии
От: Cyberax Марс  
Дата: 16.06.08 13:19
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Сорри, как ты вообще себе представляешь это в рамках С++?

J>Вот у тебя есть класс А из какой-то библиотеки Х, в Х.1 размер А 8 байт, а в Х.2 — 16 байт.
J>Теперь подключи библиотеки В и С, которые требуют Х.1 и Х.2 соответственно, и поставь себя на место разработчика/компилятора/линкера.
Это уже работает в Boost.Build v2. Там есть такое понятие — варианты билда.

Т.е. делаем так:
# Build IDE core
install install 
    :
        flex-app//flex-app # Подключение подпроектов
        flex-core//flex-core # Другой подпроект
    :
        <threading>multi
        <toolset>msvc:<cxxflags>"/wd4267 /wd4251 /wd4312 /wd4311"

При подключении подпроектов требование <threading>multi автоматически распространится на них, и на их детей.

Возможна и такая ситуация:
install install 
    :
        flex-app//flex-app # Подключение подпроектов
        flex-core//flex-core # Другой подпроект
    :
        <threading>multi
        <toolset>msvc:<cxxflags>"/wd4267 /wd4251 /wd4312 /wd4311"

install install-single 
    :
        flex-app//flex-app # Подключение подпроектов
        flex-core//flex-core # Другой подпроект
    :
        <threading>single

При этом зависимости будут построены в двух вариантах — для multi- и single-threading'а.

Зависимости работают и в обратном направлении. То есть, библиотека может указать в usage-requirements, что она требует multithreaded-билда.

Естественно, там такие вариантные билды поддерживаются и для других параметров (типа "built-in wchar_t", тип runtime-библиотеки и т.п.).
Sapienti sat!
Re[30]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 16.06.08 13:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

J>>Вот у тебя есть класс А из какой-то библиотеки Х, в Х.1 размер А 8 байт, а в Х.2 — 16 байт.

J>>Теперь подключи библиотеки В и С, которые требуют Х.1 и Х.2 соответственно, и поставь себя на место разработчика/компилятора/линкера.
C>Это уже работает в Boost.Build v2. Там есть такое понятие — варианты билда.

но не для разных же версий библиотек (я не имею в виду multi- и single-threading, я имею в виду одну и ту же библиотеку, но из разных версий буста)?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[31]: boost - вон из профессии
От: Cyberax Марс  
Дата: 16.06.08 14:08
Оценка:
Здравствуйте, jazzer, Вы писали:

C>>Это уже работает в Boost.Build v2. Там есть такое понятие — варианты билда.

J>но не для разных же версий библиотек (я не имею в виду multi- и single-threading, я имею в виду одну и ту же библиотеку, но из разных версий буста)?
А какие проблемы? С системы постройки тут можно только спрашивать совместимость. Т.е. если в проекте потребуется две разных версии библиотеки — система билда должна об этом громко завопить. А дальше уже дело программиста как коллизии решать.
Sapienti sat!
Re[30]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.06.08 14:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


J>>Сорри, как ты вообще себе представляешь это в рамках С++?

J>>Вот у тебя есть класс А из какой-то библиотеки Х, в Х.1 размер А 8 байт, а в Х.2 — 16 байт.
J>>Теперь подключи библиотеки В и С, которые требуют Х.1 и Х.2 соответственно, и поставь себя на место разработчика/компилятора/линкера.
C>Это уже работает в Boost.Build v2. Там есть такое понятие — варианты билда.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: boost - вон из профессии
От: Кодт Россия  
Дата: 16.06.08 14:52
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Вообще, для полного счастья достаточно было-бы иметь пару функций для парзинга чисел. Одна должна работать с парой итераторов Begin,End

K>вторая с одним итератором и нулем в качестве терминатора.

Достаточно иметь функцию над полуинтервалом [begin,end), а сделать адаптер итератора с универсальным нулём — не проблема.
template<class It>
struct zero_iterator // не более чем forward
{
    It it_;
    zero_iterator(It it = It()) : it_(it) {}
    
    bool is_end() const { return it_==It() || *it_==0; }
    bool operator==(It const& other) const
    {
        return is_end() ? other.is_end() : !other.is_end() && it_ == other.it_;
    }
    bool operator<(It const& other) const
    {
        return !is_end() && (other.is_end() || it_ < other.it_; }
    }
    
    // а дальше - всё, что положено итераторам
};


Либо наоборот, иметь функцию над лучом [begin,+oo) с предикатом остановки — которым является или it==end, или *it==0. (Или, может быть, остановка на символе-разделителе, или ещё что-нибудь такое...)
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[2]: offtop, parse double
От: minorlogic Украина  
Дата: 16.06.08 19:05
Оценка:
Здравствуйте, Kluev, Вы писали:


В конструкторе stringstream и strstream может вызываться динамическое создание обектов , но это уже на совести разработчиков STL имплементации.

Если ты не хочешь использовать динамическую алокацию даже в орбработке ошибок , кто мешает вернуть флаг ? Думаю увалификация позволит самому переписать примеры.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: offtop, parse double
От: minorlogic Украина  
Дата: 16.06.08 19:05
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>При достаточно большой длине аргумента str в fromString не спасет даже small string optimization, которая имеется в некоторых реализациях STL. Но даже в случаях, когда срабатывает small string optimization происходит копирование литерала (в данном случае "123") во внутренний буфер std::string. Хотя и без этого копирования можно обойтись.


Для ОСОБО внимательных я привел 2 имплементации одна принимает std::string другая указатель на строку и ее длина char* size.
Если знаешь как передать std::string без его создания , поделись плз.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: offtop, parse double
От: Kluev  
Дата: 16.06.08 20:26
Оценка: +1 -1
Здравствуйте, minorlogic, Вы писали:

M>Для ОСОБО внимательных я привел 2 имплементации одна принимает std::string другая указатель на строку и ее длина char* size.

"123" ты передаешь как раз в функцию со string. но это мелочи.

M>Если знаешь как передать std::string без его создания , поделись плз.

не надо его передавать. почти все реализации std::string больше не использую подсчет ссылок (из-за фейлдизайна в интерфейсе string) и поэтому любая передача char* будет приводить к выделению динамической памяти. char* + strlen будет работать быстрее и такой интерфейс универсальнее. можно еще сделать тонкую обертку вокруг char* или использовать нормальный класс строк с подсчетом ссылок.
Re[3]: offtop, parse double
От: Kluev  
Дата: 16.06.08 20:29
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

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


M>В конструкторе stringstream и strstream может вызываться динамическое создание обектов , но это уже на совести разработчиков STL имплементации.


ну вот, опять мальчик виноват. и как прикажете програмисту работать с библиотекой с непредсказуемой реализацией?
Re[24]: boost - вон из профессии
От: landerhigh Пират  
Дата: 16.06.08 23:57
Оценка: 2 (1) +1
Здравствуйте, Kluev, Вы писали:

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

Нет трудностей тебе. Сферический девелопер в вакууме на твой код будет втыкать долго.
K>дургое дело, что фиксить как раз не надо, т.к. ипользовать запятую как разделитель — идиотизм.
Это ты юзерам расскажи, а мы посмеемся.
L>>Этот код non-maintainable. Очень страшная реализация конечного автомата. Это я еще к форматированию придираться не начал
K>ORLY? Этот код понимается за 30 секунд и правится за такое же время. non-maintainable — разные математические и специализированные вещи в которых ты и десять строк не поймешь без специального образования:
Я тебе могу примеров кода накидать с 10-этажными шаблонами. Понимаются за 3 секунды. Только почему-то не всеми
В твоем коде любое изменение другим программером с вероятностью процентов 70 приведет к багу, скорее всего.
K>
K>

К поскипанному коду полагается комментарий с ссылкой на описание алгоритма, мимо кассы.
L>>Мы уже вроде договорились, что качество кода тут, мягко говоря, не на высоте.
K>качество кода это субьективный критерий. обективный критерий — это, например, производительность и по этому критерию моя функция в 45 лучше.
Производительность — дело десятое. Программы нынче пишутся не для компьютеров, а для программистов, не слышал? Твой код в большинстве контор не пройдет ревью, по крайней мере в качестве универсального решения, и по этому критерию он в бесконечное число раз хуже.
L>>Это не говоря о том, что все это выглядит как попытка сделать ядреную пушку, чтобы по комарам стрелять.
L>>Что толку от офигенно быстрого парсера, если 99% времени программа висит на select(), например?
K>А у меня наооборот, представляешь, ни одного селекта, зато на входе текстовые файлы с данными размером по 10-30Мб.
А у меня, представляешь, сетевой сервис. В котором парсить нужно всего две строчки из конфига, и то в момент старта. Есть ли смысл в изобретении велосипеда, притом что выгоды в производительности не будет вообще, а формат строчек в конфиге может измениться в ходе разработки, что будет означать переписывание велосипеда?
K>Так можно вообще до абсурда дойти. Одну функцию используем с селоктом, а другую с файлами.
K>Решение должно быть одно. Качественное и максимально быстрое. А буст не проходит по этим элементарным критериям.
Твое решение на качественное, извини, не тянет — оно подходит для твоего конкретного случая в вакууме и совершенно не расширяется ни на что другое. Буст или stringstream проходят по универсальности. Если становятся узким местом — пишем специализированный парсер, то есть делаем то, за что нам деньги платят, но не вопим на RSDN о том, какое буст дерьмо. Или можно предложить свой вариант в буст.
Сделал велосипед для своего конкретного случая, устраивает по производительности — молодец. Только это не значит, что другой, более универсальный микроскоп плох только потому, что не подошел для твоих конкретных гвоздей.
K>Буст вообще не библиотека, а сплошной цирк. Один xml парзер на spirit чего стоит.
И поэтому, к примеру, boost::bind — ацтой?
Буст, кстати, не библиотека.
www.blinnov.com
Re[24]: boost - вон из профессии
От: landerhigh Пират  
Дата: 17.06.08 00:01
Оценка: 1 (1)
Здравствуйте, Erop, Вы писали:

L>>Что толку от офигенно быстрого парсера, если 99% времени программа висит на select(), например?

E>IMHO, это тут офтоп. Если тебе не важна скорость твоей программы, то тебе пофиг на реализацирю таких вещей. Правда, скорее всего, тебе и С++ тогда действительно, в этой задаче, нафиг не упёрся...
Скажем так, в моей задаче скорость извлечения чисел с плавающей точкой из текстовых строк на производительность программы не влияет. Именно поэтому я возьму первое попавшееся удобное универсальное решение.
А вот теперь расскажи слушателям, каким образом ты получил выводы про "пофиг на реализацию таких вещей" и про то, какой ЯП в моей задаче не уперся.
www.blinnov.com
Re[24]: boost - вон из профессии
От: skeptik_  
Дата: 17.06.08 03:55
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Буст вообще не библиотека, а сплошной цирк. Один xml парзер на spirit чего стоит.

А чем собственно не устраивает XML parser на Spirit?
Re[32]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 05:19
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Это уже работает в Boost.Build v2. Там есть такое понятие — варианты билда.

J>>но не для разных же версий библиотек (я не имею в виду multi- и single-threading, я имею в виду одну и ту же библиотеку, но из разных версий буста)?
C>А какие проблемы? С системы постройки тут можно только спрашивать совместимость. Т.е. если в проекте потребуется две разных версии библиотеки — система билда должна об этом громко завопить. А дальше уже дело программиста как коллизии решать.

Да это понятно, что с системы постройки много не спросишь.
Я вообще о сомнительной ценности выкатывания библиотек по-одиночке, если они связаны между собой.
Гораздо удобнее, если кто-то берет все последние версии, тестирует их на совместимость и корректность, и выкладывает единым пакетом.

Иначе будет как с Линуксом (безотносительно C++), когда разные программы требуют разные версии одной и той же библиотеки, и если ты случайно установишь такую библиотеку (в моем случае это libc.6, не какая-нибудь экзотика) в общую local/lib, то у тебя вдруг половина программ начинает молча падать, и если не знать заранее, в чем дело, можно очень долго просидеть и провтыкать.

Посмотри на pkgsrc, например — у них релизы раз в квартал, и гарантировано, что все, что в составе идет, соберется и будет работать вместе без проблем. Вот это — правильное решение проблемы, имхо, и буст, кстати, тоже стремится сделать ежеквартальные релизы (правда, пока не получается — рук не хватает).

А репозитории типа CPAN — они хороши для стабильных библиотек, которые уже и не меняются особо (типа Regex.Common)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 05:32
Оценка:
Здравствуйте, Kluev, Вы писали:

K>почти все реализации std::string больше не использую подсчет ссылок (из-за фейлдизайна в интерфейсе string) и поэтому любая передача char* будет приводить к выделению динамической памяти.


Правда? Это какой же такой волшебный "фейлдизайн" не дал апачу сделать строки с подсчетом ссылок?

http://stdcxx.apache.org/

* Thread-safe implementation of strings, iostreams, and locales
* Reference counted basic_string implementation using atomic locking with the ability to switch to a non-reference counted implementation


У меня складывается впечатление, что слово "фелдизайн" в твоих устах эквивалентно "мне не нравится, и все тут".
Давай ты это слово заменишь на что-нибудь более осмысленное, типа там "хранение по значению" или что-нибудь в этом роде?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[25]: Читай что пишешь, что ли...
От: Erop Россия  
Дата: 17.06.08 06:07
Оценка: :)
Здравствуйте, landerhigh, Вы писали:

L>>>Что толку от офигенно быстрого парсера, если 99% времени программа висит на select(), например?

E>>IMHO, это тут офтоп. Если тебе не важна скорость твоей программы, то тебе пофиг на реализацирю таких вещей. Правда, скорее всего, тебе и С++ тогда действительно, в этой задаче, нафиг не упёрся...
L>А вот теперь расскажи слушателям, каким образом ты получил выводы про "пофиг на реализацию таких вещей" и про то, какой ЯП в моей задаче не уперся.
Если тебе это правда интересно, то я поясню. Хотя мне и кажется, что ты мог бы и сам догадаться...

Такой вывод я сделал из твоих же слов, которые я выделил полужирным шрифтом...
IMHO, если твоя прога занимается тем, что ждёт, пока основную работу сделает БД, то С++ тебе нафиг не упёрся. Для таких задач есть намного более эффективные средства разработки...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: offtop, parse double
От: Erop Россия  
Дата: 17.06.08 06:10
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Правда? Это какой же такой волшебный "фейлдизайн" не дал апачу сделать строки с подсчетом ссылок?


Например то, что неконстантный operator[] позволяет модифицировать строку...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[25]: boost - вон из профессии
От: Kluev  
Дата: 17.06.08 06:21
Оценка: +1 -1
Здравствуйте, landerhigh, Вы писали:

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


K>>качество кода это субьективный критерий. обективный критерий — это, например, производительность и по этому критерию моя функция в 45 лучше.

L>Производительность — дело десятое. Программы нынче пишутся не для компьютеров, а для программистов, не слышал? Твой код в большинстве контор не пройдет ревью, по крайней мере в качестве универсального решения, и по этому критерию он в бесконечное число раз хуже.

Это не универсальное решение, а низкоуровневое. Более абстрактные вещи высокого уровня должны опиратся на эффективные низкоуровневые решения. А не как в бусте, реализация из первого попавшегося под руку барахла. С непредсказуемым поведением между прочим.
т.к. в одной реализации iostream память выделяется а в другой нет.

L>А у меня, представляешь, сетевой сервис. В котором парсить нужно всего две строчки из конфига, и то в момент старта. Есть ли смысл в изобретении велосипеда, притом что выгоды в производительности не будет вообще, а формат строчек в конфиге может измениться в ходе разработки, что будет означать переписывание велосипеда?


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

K>>Так можно вообще до абсурда дойти. Одну функцию используем с селоктом, а другую с файлами.

K>>Решение должно быть одно. Качественное и максимально быстрое. А буст не проходит по этим элементарным критериям.
L>Твое решение на качественное, извини, не тянет — оно подходит для твоего конкретного случая в вакууме и совершенно не расширяется ни на что другое. Буст или stringstream проходят по универсальности.
iostream — это вообще ошибка природы. он работает несиметрично (запихни в него строку "vasya pupkin" и попробуй потом прочесть, на входе одна строка на выходе две) и годится только для примитивного кода в стиле "все равно как написано"

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


Мне гораздо важнее качество реализации, чем универсальность интерфейса. Т.к. нет вообще никаких проблем чтобы сделать интерфейсную обертку по своим нуждам.
Re[26]: Читай что пишешь, что ли...
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 06:23
Оценка:
Здравствуйте, Erop, Вы писали:

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


L>>>>Что толку от офигенно быстрого парсера, если 99% времени программа висит на select(), например?

E>Такой вывод я сделал из твоих же слов, которые я выделил полужирным шрифтом...
E>IMHO, если твоя прога занимается тем, что ждёт, пока основную работу сделает БД, то С++ тебе нафиг не упёрся. Для таких задач есть намного более эффективные средства разработки...

а если программа должна на этот select() как можно быстрее реагировать? Откуда сведения про базу данных?

маршрутизатор, например, 99% времени сидит и ждет, пока его кто-то не торкнет.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[27]: Читай что пишешь, что ли...
От: Erop Россия  
Дата: 17.06.08 06:44
Оценка: 6 (1) +1
Здравствуйте, jazzer, Вы писали:

J>маршрутизатор, например, 99% времени сидит и ждет, пока его кто-то не торкнет.

Тогда ему должно быть не пофиг на качество реализации, однако. Я не согласен с Клюевым, что boost -- это абсолютное зло, которое должно быть предано забвению. Но согласем что во многих тамошних библиотеках плохой дизайн. Всё слишком переусложненно, и через "универсальный интерфейм реализации" сделано.
В частности, я согласен, что преобразование между текстом и числами надо делать не так, как в бусте сделано, а как-то так, как Клюев пишет.
То есть должны быть какие-то быстрые и эффекивные парсеры/распечатчики, с универсальным интерфейсом, и должен быть удобный интерфейс к этому низкому уровню. А не такой левой ногой, через правое ухо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[28]: Читай что пишешь, что ли...
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 06:55
Оценка: 1 (1) +1
Здравствуйте, Erop, Вы писали:

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


J>>маршрутизатор, например, 99% времени сидит и ждет, пока его кто-то не торкнет.

E>Тогда ему должно быть не пофиг на качество реализации, однако.
Ну так ты вспомни, что он писал и с чем ты споришь.
Он говорил, что ему в его задаче пофиг на качество и скорость парсинга, потмоу что он этим занимается парсингом толкьо при старте при чтении из конфига.
Но из этого не следует, ему пофиг на скорость всего остального, и тем более из этого не следует, что С++ не для его задач, как говоришь ты.

К слову, у меня точно такая же ситуация, ибо сервера.
И в основном цикле работа идет на низком уровне, потому что счет идет на микросекунды.
А вот при парсинге конфигов при старте boost::spirit и boost::lexical_cast работают со свистом, только в путь, и код крайне простой и читабельный.
И если я там начну выжимать микросекунды самописными велосипедами — начальство меня не поймет.

E>Я не согласен с Клюевым, что boost -- это абсолютное зло, которое должно быть предано забвению. Но согласем что во многих тамошних библиотеках плохой дизайн. Всё слишком переусложненно, и через "универсальный интерфейм реализации" сделано.

E>В частности, я согласен, что преобразование между текстом и числами надо делать не так, как в бусте сделано, а как-то так, как Клюев пишет.
И кто тебе (или Клюеву) мешает сделать порох непромокаемым?
Буст, вообще-то — опенсорсная библиотека.
Нашел багу — закинь патч, и все будут довольны.
Гораздо конструктивнее и полезнее для сообщества, чем тупо материться на форуме.

E>То есть должны быть какие-то быстрые и эффекивные парсеры/распечатчики, с универсальным интерфейсом, и должен быть удобный интерфейс к этому низкому уровню. А не такой левой ногой, через правое ухо...


см. выше.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[29]: Читай что пишешь, что ли...
От: Erop Россия  
Дата: 17.06.08 07:03
Оценка: +2
Здравствуйте, jazzer, Вы писали:

J>И кто тебе (или Клюеву) мешает сделать порох непромокаемым?

Идеология... В смысле и я и Клюев и много кто ещё давным-давно пользуются непромокаемым порохом, а вовсе и не бустом. А когда высказывают фи, то в ответ ругань

J>Буст, вообще-то — опенсорсная библиотека.

J>Нашел багу — закинь патч, и все будут довольны.
J>Гораздо конструктивнее и полезнее для сообщества, чем тупо материться на форуме.
Ну вот Клюев опубликовал сорцы парсера. И что мы видим? Пишут про ревью и goto...
Как будто код из буста ревью пройдёт

E>>То есть должны быть какие-то быстрые и эффекивные парсеры/распечатчики, с универсальным интерфейсом, и должен быть удобный интерфейс к этому низкому уровню. А не такой левой ногой, через правое ухо...

J>см. выше.
см. там же.
Всё уже написано давно и опубликовано даже. Другое дело, что буст это не хорошая библиотека, а красивая и прикольная. А что прикольного в решении Клюева большинству народа не понять, IMHO. Кроме того, в таком решении ещё и нет ничего нового. Только и всего.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Вообще не понимаю, о чем разговор...
От: degor Россия  
Дата: 17.06.08 09:15
Оценка: 6 (1) :)
как можно всерьез обсуждать кусок кода, который даже собрать без геморроя нельзя? тем более такой кусок, который жрет числа вида -.A и не давится?
Re[2]: Вообще не понимаю, о чем разговор...
От: Kluev  
Дата: 17.06.08 09:34
Оценка:
Здравствуйте, degor, Вы писали:

D>как можно всерьез обсуждать кусок кода, который даже собрать без геморроя нельзя? тем более такой кусок, который жрет числа вида -.A и не давится?


Вполне можно. Ты же сам понимаешь, что велосипеды доделываются согласно потребностям, а этот код без проблем отпарзил гигабайты данных за несколько лет
и оттестирован на всех возможных use case в реальных условиях.
Re[33]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 09:51
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Я вообще о сомнительной ценности выкатывания библиотек по-одиночке, если они связаны между собой.

J>Гораздо удобнее, если кто-то берет все последние версии, тестирует их на совместимость и корректность, и выкладывает единым пакетом.

J>Иначе будет как с Линуксом (безотносительно C++), когда разные программы требуют разные версии одной и той же библиотеки, и если ты случайно установишь такую библиотеку (в моем случае это libc.6, не какая-нибудь экзотика) в общую local/lib, то у тебя вдруг половина программ начинает молча падать, и если не знать заранее, в чем дело, можно очень долго просидеть и провтыкать.


J>Посмотри на pkgsrc, например — у них релизы раз в квартал, и гарантировано, что все, что в составе идет, соберется и будет работать вместе без проблем. Вот это — правильное решение проблемы, имхо, и буст, кстати, тоже стремится сделать ежеквартальные релизы (правда, пока не получается — рук не хватает).


J>А репозитории типа CPAN — они хороши для стабильных библиотек, которые уже и не меняются особо (типа Regex.Common)


Ну смотри, есть два сценария работы:

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

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

Теперь смотрим на эти два сценария. Первый позволяет создавать единые сборки, подвергающиеся тчательному централизованному тестированию -- да. Ничего не мешает организовать где-нибудь зеркало, на котором лежат конкретные версии конкретных проектов и известно, что они протестированы совместно. Кому нужен именно такой сервис -- может спокойно брать подобный дистрибутив и нет проблем. Это напоминает Linux-овые дистрибутивы с какой-нибудь системой пакетов (вроде RPM): выходит очередная Fedora с некоторыми версиями пакетов. Но, при желании, какой-нибудь пакет можно будет заменить на более новую версию, не дожидаясь выхода очередной Fedora.

Так же первый сценарий позволяет распространять свой проект только со ссылками на другие подпроекты. Например, нужны моему проекту pcre, botan и boost::shared_ptr -- я прописываю о себя ссылки на них. Пользователь может скачать только то, что ему нужно.

А вот во втором сценарии, как мне распространять boost::shared_ptr со своей библиотекой? Либо заставлять пользователя самому качать boost (сколько там сейчас десятков мегабайт?), либо я с помощью bcp выдераю shared_ptr со товарищи из моей версии boost-а и архивирую выдернутые исходники вместе со своей библиотекой. А потом выходит новый boost и что мне делать? Выдергивать оттуда shared_ptr опять? Или вообще ничего не делать?

Манифесты подобные ситуации разруливают гораздо проще. Если моей библиотеке нужен boost::shared_ptr, то я могу прописать в манифесте:
project 'my_super_puper_lib' do |prj|
  prj.version '2.0.6', :compatible_with => '2.0'
  prj.subproject 'boost::shared_ptr', :version => '>= 1.33'
  ...
end

Если какая-нибудь очередная версия Boost-а поддерживает для shared_ptr из Boost 1.33, то там будет в свойствах проекта прописано:
project 'boost::shared_ptr' do |prj|
  prj.version '1.35', :compatible_with => '1.33'
  ...

Получается, что пользователь сможет использовать мою my_super_puper_lib как с Boost 1.33, так и с Boost 1.35. Причем я ничего со своей библиотекой не распространяю и не навязываю пользователю конкретную версию Boost-а. Не хочет человек по каким-то причинам использовать Boost 1.35 -- пусть работает с Boost 1.33 (или наоборот).

А если выходит какой-нибудь Boost 1.37, в котором shared_ptr совместим только с Boost 1.35:
project 'boost::shared_ptr' do |prj|
  prj.version '1.37', :compatible_with => '1.35'
  ...

то тут все -- my_super_puper_lib не сможет с таким Boost-ом работать и инструмент для разруливания зависимостей об этом ругнется. Тут пользователь моей библиотеки может меня пнуть и сказать: "Какого этого самого, мил человек, ты ждешь? Boost 1.37 уже на дворе, а ты все еще за 1.33 цепляешься". Только тогда я вспомню о том, что Boost как-то развивается, качну себе новую версию, портирую под нее свою библиотеку и пропишу в ней:
project 'my_super_puper_lib' do |prj|
  prj.version '2.0.7', :compatible_with => '2.0'
  prj.subproject 'boost::shared_ptr', :version => '>= 1.35'
  ...
end


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

С помощью такой системы, странные велосипеды вроде библиотек egg или fsm, которые проходили peer review в Boost-е и набирали всего лишь около десятка отзывов, смогут спокойно жить и развиваться, бользуясь единой системой дистрибуции. Только вот в общем хранилище Boost-а их не будет, как не прошедших review, соответственно не будет для них централизованного тестирования.

Так какой сценарий тебе больше нравится?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 10:10
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Для ОСОБО внимательных я привел 2 имплементации одна принимает std::string другая указатель на строку и ее длина char* size.


Но при этом имея две реализации, вы передали строковый литерал туда, где ожидается std::string.
Если есть API, который принимает const std::string &, а при использовании ему подсовывают const char * (в виде таких вот литералов), то расходы на конструирование и уничтожение std::string-ов могут принимать очень серьезные размеры.

M>Если знаешь как передать std::string без его создания , поделись плз.


А во многих случаях не нужен std::string. Я подсмотрел хорошее решение в библиотеке PCRE -- там есть класс StringPiece, разработанный для C++ной обертки PCRE в Google. Я сделал из него для себя вариант. Он не такой функциональный, как Google-овский, зато у него есть шаблонные конструкторы специально для строковых литералов.

В некоторых случаях у меня замена const std::string & на const string_piece_t & ускоряло код в два раза.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Вообще не понимаю, о чем разговор...
От: degor Россия  
Дата: 17.06.08 10:24
Оценка: 10 (2)
Здравствуйте, Kluev, Вы писали:

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


D>>как можно всерьез обсуждать кусок кода, который даже собрать без геморроя нельзя? тем более такой кусок, который жрет числа вида -.A и не давится?


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

K>и оттестирован на всех возможных use case в реальных условиях.

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

вот тебе use case: "-.A". мегавелосипед возвращает num_parse_ok,а должен возвращать num_parse_syntax.

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

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

и о методике. возьми чиселки подлиннее, например, символов из 30, и увидишь, что преимущество велосипеда над crt уже не столь велико.
Re[7]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 10:28
Оценка:
Здравствуйте, Erop, Вы писали:

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


J>>Правда? Это какой же такой волшебный "фейлдизайн" не дал апачу сделать строки с подсчетом ссылок?


E>Например то, что неконстантный operator[] позволяет модифицировать строку...

и что, поэтому в апачевской либе его нет?
или его нет в каких-то еще строковых либах?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: offtop, parse double
От: Sergey Россия  
Дата: 17.06.08 11:06
Оценка:
eao197 пишет:

> M>Для ОСОБО внимательных я привел 2 имплементации одна принимает

> std::string другая указатель на строку и ее длина char* size.
>
> Но при этом имея две реализации, вы передали строковый литерал туда, где
> ожидается std::string.
> Если есть API, который принимает const std::string &, а при
> использовании ему подсовывают const char * (в виде таких вот литералов),
> то расходы на конструирование и уничтожение std::string-ов могут
> принимать очень серьезные размеры.
>
> M>Если знаешь как передать std::string без его создания , поделись плз.
>
> А во многих случаях не нужен std::string. Я подсмотрел хорошее решение в
> библиотеке PCRE <http://www.pcre.org> -- там есть класс StringPiece,
> разработанный для C++ной обертки PCRE в Google. Я сделал из него для
> себя вариант <http://files.rsdn.ru/31476/string_piece.hpp.html&gt;. Он не
> такой функциональный, как Google-овский, зато у него есть шаблонные
> конструкторы специально для строковых литералов.
>
> В некоторых случаях у меня замена const std::string & на const
> string_piece_t & ускоряло код в два раза.

О, а у меня почти такой же есть, из тех же соображений Только я на
паре указателей сделал, а не на указатель + длина.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[6]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 11:07
Оценка: +2 :)
Здравствуйте, Sergey, Вы писали:

>> В некоторых случаях у меня замена const std::string & на const

>> string_piece_t & ускоряло код в два раза.

S>О, а у меня почти такой же есть, из тех же соображений Только я на

S>паре указателей сделал, а не на указатель + длина.

я думаю, у каждого такой же есть.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 11:18
Оценка: +2
Здравствуйте, jazzer, Вы писали:

>>> В некоторых случаях у меня замена const std::string & на const

>>> string_piece_t & ускоряло код в два раза.

S>>О, а у меня почти такой же есть, из тех же соображений Только я на

S>>паре указателей сделал, а не на указатель + длина.

J>я думаю, у каждого такой же есть.


Возникает вопрос: почему же его нет ни в стандартной библиотеке, ни в tr1, ни в boost-е? Или где-нибудь есть?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: offtop, parse double
От: Sergey Россия  
Дата: 17.06.08 11:24
Оценка:
jazzer пишет:

>> > В некоторых случаях у меня замена const std::string & на const

>> > string_piece_t & ускоряло код в два раза.
>
> S>О, а у меня почти такой же есть, из тех же соображений Только я на
> S>паре указателей сделал, а не на указатель + длина.
>
> я думаю, у каждого такой же есть.

Возникает вопрос — а чего ж его до сих пор нет в стандарте? Ну и еще
несколько вопросов —
а) где брать шаблонные реализации strtol сотоварищи
б) какого черта до сих пор никто не умеет export template. Для таких
простейших случаев — пригождалось бы идеально.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[8]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 11:25
Оценка:
Здравствуйте, eao197, Вы писали:

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


>>>> В некоторых случаях у меня замена const std::string & на const

>>>> string_piece_t & ускоряло код в два раза.

S>>>О, а у меня почти такой же есть, из тех же соображений Только я на

S>>>паре указателей сделал, а не на указатель + длина.

J>>я думаю, у каждого такой же есть.


E>Возникает вопрос: почему же его нет ни в стандартной библиотеке, ни в tr1, ни в boost-е? Или где-нибудь есть?


ну, для начала, есть std::pair<const char*, const char*> и std::pair<const char*, std::size_t>, по вкусу.

а вот что еще должно быть (в сымсле, какие методы) — это вопрос открытый, потому что всем нужно разное.
У меня в разных проектах соответствующий класс имел разный набор методов, просто потому что нужно разное.

Еще есть boost::range, который выглядит как последовательность, и принимает пару итераторов. (напоминаю, что указатели сами по себе являются итераторами).
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 11:32
Оценка: +1
Здравствуйте, jazzer, Вы писали:

E>>Возникает вопрос: почему же его нет ни в стандартной библиотеке, ни в tr1, ни в boost-е? Или где-нибудь есть?


J>ну, для начала, есть std::pair<const char*, const char*> и std::pair<const char*, std::size_t>, по вкусу.


J>а вот что еще должно быть (в сымсле, какие методы) — это вопрос открытый, потому что всем нужно разное.

J>У меня в разных проектах соответствующий класс имел разный набор методов, просто потому что нужно разное.

Вообще-то std::pair<const char*, const char*> -- это вовсе не аналог string_piece. Так как в случае string_piece прокатывают вот такие вещи:
void some_function( const string_piece_t & str ) { ... }

const char * s1 = "bla-bla-bla";
const std::string s2 = "bla-bla-bla";

some_function( s1 );
some_function( s2 );
some_function( "bla-bla-bla" );

Если заставить some_function получать std::pair, то все аргументы для some_function придется передавать ручками.

Соответственно, нужно иметь в string_piece какое-то подмножество методов из std::string (хотя бы итераторы). Ну и чтобы другие вещи в std понимали string_piece (например, конструкторы fstream, operator<< для iostreams).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Вообще не понимаю, о чем разговор...
От: Kluev  
Дата: 17.06.08 11:52
Оценка:
Здравствуйте, degor, Вы писали:

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


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


D>вот тебе use case: "-.A". мегавелосипед возвращает num_parse_ok,а должен возвращать num_parse_syntax.

этот use case не встречается там где он используется, хотя я не отрицаю, что это ошибка.

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


D>и о методике. возьми чиселки подлиннее, например, символов из 30, и увидишь, что преимущество велосипеда над crt уже не столь велико.

к скорости strtod у меня нет претензий. неюзабельной ее делает strlen из-за которого невозможно парзить текст большими кусками.
так же я померял на больших строках разница в 2.5 раза получается.

вот обновленный универсальный велосипед для ascii-unicode-iterator и работающий как с диапазонами строк так и с сишными строками.
errcode = parse_real(value, str_begin, RangeTerm<const char*>(str_end));
errcode = parse_real(value, str, ZeroTerm());



#pragma once

#include <float.h>

//==================================================================
template <class T>
    class NumberTraits;

//==================================================================
template <>
    class NumberTraits<double>
{
public:
    static int
        is_finite(double v)
    {
        return _finite(v);
    }
};

//==================================================================
template <class Iter>
struct RangeTerm
{
    Iter    end;

    RangeTerm(Iter e)
        : end (e)
    {
    }

    bool operator ()(Iter it)
    {
        return it == end;
    }
};

struct ZeroTerm
{
    template <class Iter>
        bool operator ()(Iter it)
    {
        return 0 == *it;
    }
};

enum
{
    NUM_PARSE_OK = 0,
    NUM_PARSE_EOF,
    NUM_PARSE_SYNTAX,
    NUM_PARSE_OVERFLOW,
};

template <class V, class Iter, class Term> int
    parse_real(V &res, Iter &p, Term eof)
{
    typedef NumberTraits<V> NT;

    V val       = 0;
    V sign      = 1;
    int esign   = 1;
    V ep;
    int    fdigits = 0;        
    bool has_ip = false;
    bool has_fp = false;

// skip space chars
    while (!eof(p))
    {
        if (' ' == *p || (*p > 0x8 && *p < 0xE))
            ++p;
        else
            goto space_ok;
    }
// eof here
    return NUM_PARSE_EOF;

space_ok: // +-.digit
    if (*p >= '0' && *p <= '9')
        goto ip_parse;

    if ('-' == *p)
        { sign = -1; goto sign_ok; }
    if ('+' == *p)
        goto sign_ok;

    if ('.' == *p)
        goto dot_ok;

    return NUM_PARSE_SYNTAX;

sign_ok: // .digit
    if (eof(++p))
        return NUM_PARSE_EOF;

    if (*p >= '0' && *p <= '9')
        goto ip_parse;

    if ('.' == *p)
        goto dot_ok;

    return NUM_PARSE_SYNTAX;

ip_parse:
    has_ip = true;
    val    = *p - '0';
    ++p;
    while(!eof(p))
    {
        if (*p >= '0' && *p <= '9')
        {
            val = val*10 + *p - '0';
            ++p;
        }
        else
            goto ip_ok;
    }
// eof here
    res = val*sign;
    return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;

ip_ok: //.eEdD
    if ('.' == *p)
        goto dot_ok;

    if ('e' == *p || 'E' == *p || 'd' == *p || 'D' == *p)
        goto ep_ok;

    if (!has_ip)
        return NUM_PARSE_SYNTAX;
    res = val*sign;
    return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;

dot_ok: // digit or eEdD
    if (eof(++p))
    {
        if (!has_ip)
            return NUM_PARSE_SYNTAX;
        res = val*sign;
        return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;
    }

    if (*p >= '0' && *p <= '9')
        goto fp_parse;

    if ('e' == *p || 'E' == *p || 'd' == *p || 'D' == *p)
        goto ep_ok;

    if (!has_ip)
        return NUM_PARSE_SYNTAX;
    res = val*sign;
    return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;

fp_parse:
    val     = val*10 + *p - '0';
    fdigits = 1;
    has_fp  = true;
    ++p;

    while(!eof(p))
    {
        if (*p >= '0' && *p <= '9')
        {
            val = val*10 + *p - '0';
            ++fdigits;
            ++p;
        }
        else
            goto fp_ok;
    }
// eof here
    res = sign*val*pow(10.,-fdigits);
    return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;

fp_ok: // eEdD
    if ('e' == *p || 'E' == *p || 'd' == *p || 'D' == *p)
        goto ep_ok;

    if (!(has_ip || has_fp))
        return NUM_PARSE_SYNTAX;
    res = sign*val*pow(10.,-fdigits);
    return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;

ep_ok: //+-digit
    if (eof(++p))
    {
        if (!(has_ip || has_fp))
            return NUM_PARSE_SYNTAX;
        res = sign*val*pow(10.,-fdigits);
        return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;
    }

    if (*p >= '0' && *p <= '9')
        goto ep_parse;

    if ('-' == *p)
        { esign = -1; goto esign_ok; }

    if ('+' == *p)
        goto esign_ok;

    return NUM_PARSE_SYNTAX;

esign_ok:
    if (eof(++p))
        return NUM_PARSE_SYNTAX;

    if (*p >= '0' && *p <= '9')
        goto ep_parse;

    return NUM_PARSE_SYNTAX;

ep_parse:
    ep = *p - '0';
    ++p;
    while (!eof(p))
    {
        if (*p >= '0' && *p <= '9')
        {
            ep = ep*10 + *p - '0';
            ++p;
        }
        else
            break;
    }

    if (ep > 1e6)
    {
        ep *= esign;
        ep -= fdigits;
        res = sign*val*pow(10., ep);
    }
    else
    {
        int iep = esign*int(ep)-fdigits;
        res = sign*val*pow(10., iep);
    }

    return NT::is_finite(res) ? NUM_PARSE_OK : NUM_PARSE_OVERFLOW;
}
Re[5]: offtop, parse double
От: night beast СССР  
Дата: 17.06.08 11:53
Оценка: 59 (2)
Здравствуйте, eao197, Вы писали:

E>А во многих случаях не нужен std::string. Я подсмотрел хорошее решение в библиотеке PCRE -- там есть класс StringPiece, разработанный для C++ной обертки PCRE в Google. Я сделал из него для себя вариант. Он не такой функциональный, как Google-овский, зато у него есть шаблонные конструкторы специально для строковых литералов.


не сочти за придирку, но строковые литералы с С++ передаются по ссылке:
      template< size_t LEN >
      string_piece_t( const char (&ptr)[ LEN ] )

хотя в данном случае сработает не-шаблонный конструктор...
Re[26]: Читай что пишешь, что ли...
От: landerhigh Пират  
Дата: 17.06.08 12:02
Оценка:
Здравствуйте, Erop, Вы писали:

E>IMHO, если твоя прога занимается тем, что ждёт, пока основную работу сделает БД, то С++ тебе нафиг не упёрся. Для таких задач есть намного более эффективные средства разработки...

Вот именно что "читай что пишешь".
Откуда теперь даза банных взялась? И почему опять C++ не уперся?
www.blinnov.com
Re[10]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 12:02
Оценка: 5 (1) +4 :)
Здравствуйте, eao197, Вы писали:

E>Вообще-то std::pair<const char*, const char*> -- это вовсе не аналог string_piece. Так как в случае string_piece прокатывают вот такие вещи:


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

Ну еще, конечно, можно предоставить begin/end/size и тайпдефы. Все. (А можно и их не предоставлять, если пользуешься boost::range — надо будет просто написать соответствующие специализации)

Но самая главная проблема этого класса — его взаимоотношения с хозяином и возможность того, что он его переживет и будет смотреть в никуда (а если строка с счетчиком, то ведь надо его тоже апдейтить...).

и, раз уж на то пошло, где твое предложение в комитет по стандартизации по включению соответствующей байды в стандартную библиотеку?
Я, на всякий случай, напомню, что народ в комитете не за деньги напрягается, там такие же люди, как и вы.
Вон, посмотрите на немерлистов: нету чего-то в языке или библиотеке — пишут и отправляют разработчикам языка, и в результате имеют тот язык, который хотят, с теми библиотеками, которые хотят.
А в С++ только сидят и ноют, что ж, мол, такие плохие все в комитете, палец о палец не ударят.
А не было бы Степанова — так вообще никакой библиотеки стандартной не было бы, так бы и сидели в зоопарке.
Вон товарищи из буста работают — вот их контейнеры и появляются в стандарте.
А Александреску, скажем, повозмущался, что, мол, как это так, почему мой супер-смарт-поинтер не включили в стандарт, а у него так вежливо поинтересовались: "А где предложение-то, с номерами параграфов, где чего и как менять, и т.д? Или ты ждешь, что его кто-то за тебя напишет?" (На самом деле, конечно, было не совсем так, просто как иллюстрация)

Хочешь, чтобы что-то было в С++, и не видишь соответствующего предложения на их сайте?
Так напиши сам, потрать время и силы, предложи, убеди всех, что это действительно позарез нужно — и все будет, и все тебе спасибо скажут.
А так я могу тебе твою же претензию и развернуть: "Имярек, а почему это до сих пор этого нет в Стандарте?! Что за лень и халатность? Ты что, совсем не думаешь о простых разработчиках, которые страдают без этой фичи?"

Сорри за эмоциональность, накипело.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[30]: Читай что пишешь, что ли...
От: landerhigh Пират  
Дата: 17.06.08 12:04
Оценка: 6 (1)
Здравствуйте, Erop, Вы писали:

J>>Гораздо конструктивнее и полезнее для сообщества, чем тупо материться на форуме.

E>Ну вот Клюев опубликовал сорцы парсера. И что мы видим? Пишут про ревью и goto...
Там уже пару багов нашли. Я бы искать не стал, ибо оно того не стоит.
www.blinnov.com
Re[11]: offtop, parse double
От: Kluev  
Дата: 17.06.08 12:12
Оценка: -5
Здравствуйте, jazzer, Вы писали:

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



J>А в С++ только сидят и ноют, что ж, мол, такие плохие все в комитете, палец о палец не ударят.

J>А не было бы Степанова — так вообще никакой библиотеки стандартной не было бы, так бы и сидели в зоопарке.

Лучше старый добрый зоопарк зоопарк чем степановский цирк и бустовское шоу нарциссо.
Re[12]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 12:43
Оценка: +1
Здравствуйте, Kluev, Вы писали:

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


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



J>>А в С++ только сидят и ноют, что ж, мол, такие плохие все в комитете, палец о палец не ударят.

J>>А не было бы Степанова — так вообще никакой библиотеки стандартной не было бы, так бы и сидели в зоопарке.

K>Лучше старый добрый зоопарк зоопарк чем степановский цирк и бустовское шоу нарциссо.


да ты мастер ярлыки клеить

ну либо тебе не приходилось проходить через ад сопряжения двух разных библиотек с несовместимыми интерфейсами, занимающихся одним и тем же — ну что ж, могу только позавидовать.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 12:44
Оценка: +1
Здравствуйте, jazzer, Вы писали:

E>>Вообще-то std::pair<const char*, const char*> -- это вовсе не аналог string_piece. Так как в случае string_piece прокатывают вот такие вещи:


J>и что? или кроме этих вот вещей, ничего не нужно больше? или, если не нужно, проблема написать функцию типа make_string_piece, или написать ровно три конструктора, один оператор вывода в поток и один оператор преобразования в std::string?


Ровно три конструктора в каком классе нужно написать?

J>Но самая главная проблема этого класса — его взаимоотношения с хозяином и возможность того, что он его переживет и будет смотреть в никуда (а если строка с счетчиком, то ведь надо его тоже апдейтить...).


Поскольку этот класс всего-лишь обертка над char *, то и гарантии он дает точно такие же, как char *.

J>Сорри за эмоциональность, накипело.


Я просто спросил, почему, если аналоги string_piece есть у многих разработчиков, самого string_piece нет. Может этот вопрос уже широко обсуждался где-нибудь, а я, как обычно, не знаю

Что до развития C++... У меня нет желания развивать сам язык или его стандартную библиотеку. Делать что-нибудь на C++ -- это да, это можно (хотя и желания гораздо меньше, чем было раньше). Вот этим и занимаюсь по мере сил, это мне интересно. А языком пусть занимаются те, кому это интересно. Таких и без меня не мало.

Только вот сама тенденция концентрировать усилия вокруг комитета или буста -- это, имхо, не правильно.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 14:52
Оценка: 6 (1)
Здравствуйте, eao197, Вы писали:

E>Ровно три конструктора в каком классе нужно написать?

в string_piece, вестимо

J>>Но самая главная проблема этого класса — его взаимоотношения с хозяином и возможность того, что он его переживет и будет смотреть в никуда (а если строка с счетчиком, то ведь надо его тоже апдейтить...).


E>Поскольку этот класс всего-лишь обертка над char *, то и гарантии он дает точно такие же, как char *.


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

J>>Сорри за эмоциональность, накипело.


E>Я просто спросил, почему, если аналоги string_piece есть у многих разработчиков, самого string_piece нет. Может этот вопрос уже широко обсуждался где-нибудь, а я, как обычно, не знаю


Ну если просто спросил...

E>Только вот сама тенденция концентрировать усилия вокруг комитета или буста -- это, имхо, не правильно.


Ну а вот вокруг чего надо концентрировать усилия по изменению С++, если не вокруг комитета С++?
А насчет библиотек — ну вокруг чего-то ведь надо концентрировать усилия, иначе ведь зоопарк будет.
Посмотри сам — ведь каждая библиотека считает своим долгом предоставить свои строки, контейнеры и прочая.
Слава богу, что появился STL с его стандартизированным интерфейсом для контейнеров/итераторов/алгоритмов: теперь достаточно всем этим контейнерам предоставить begin/end, чтобы все заработало (а с boost::range ты и сам можешь написать соответствующие специализации, и все автоматом заработает). А ведь раньше — это просто ад был, я прошел через это пару раз, больше не хочу ну просто вот совсем.
Так что стандарт на интерфейс и жесткое код ревью на следование этим интерфейсам — это я оцениваю очень высоко, и только буст этим всерьез занимается (еще adobe, но он в результате сабмитит все в тот же boost).
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: offtop, parse double
От: Erop Россия  
Дата: 17.06.08 15:03
Оценка:
Здравствуйте, jazzer, Вы писали:

E>>Например то, что неконстантный operator[] позволяет модифицировать строку...

J>и что, поэтому в апачевской либе его нет?
Приходится извращаться
Да и работает не очень.

J>или его нет в каких-то еще строковых либах?

J>
Ну, например, посмори на CString...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 15:17
Оценка: +1
Здравствуйте, jazzer, Вы писали:

E>>Поскольку этот класс всего-лишь обертка над char *, то и гарантии он дает точно такие же, как char *.


J>Ага, скажи это индусам, которые будут твой код саппортить.

J>Для них если класс — значит, можно безопасно использовать как угодно.
J>Столько раз уже сталкивался

Ну против лома нет приема.
С другой стороны, не все пишут код, который потом индусы будут саппортить

J>>>Сорри за эмоциональность, накипело.


E>>Я просто спросил, почему, если аналоги string_piece есть у многих разработчиков, самого string_piece нет. Может этот вопрос уже широко обсуждался где-нибудь, а я, как обычно, не знаю


J>Ну если просто спросил...


Просто спросил

J>А насчет библиотек — ну вокруг чего-то ведь надо концентрировать усилия, иначе ведь зоопарк будет.

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

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

Происходит же сейчас то же самое в области IPC -- есть ACE, есть Poco, есть boost::asio. Криптография -- OpenSSL, Crypto++, CryptLib, Botan. XML -- то же самое.

Конечно, есть базовые вещи, вроде basic_string или контейнеры. Но их не так уж и много. Пусть они хоть комитетом разрабатывается, хоть еще кем-то, тем же boost-ом.

Гораздо хуже, когда какая-то одна библиотека пытается стать пупом земли и центром мира. Вот есть у меня сомнения в том, что в стандартной библиотеки должны быть вещи типа boost::spirit или boost::program_option. Это просто собирательство в одну корзину всего, что кто-то счел достаточно хорошим для публикации.

Более качественный подход, на мой взгляд -- это дать библиотеке самостоятельно жить до тех пор, пока она не станет достаточно распространенной сама по себе. А уже потом принимать решение о ее "иконизации" (как это было в Java с Log4J).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 17.06.08 15:22
Оценка:
Здравствуйте, Erop, Вы писали:

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


E>>>Например то, что неконстантный operator[] позволяет модифицировать строку...

J>>и что, поэтому в апачевской либе его нет?
E>Приходится извращаться
не сомневаюсь
E>Да и работает не очень.
Апачевская либа работает не очень?
Что не так?

J>>или его нет в каких-то еще строковых либах?

J>>
E>Ну, например, посмори на CString...
Ну, у меня его под рукой нет, как ты понимаешь, но я помню, что там можно было строки изменять, в том числе и конкретные символы.
Но поскольку ты под винду пишешь — так и быть, верю, хоть и странно
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: offtop, parse double
От: minorlogic Украина  
Дата: 17.06.08 19:05
Оценка:
Здравствуйте, Kluev, Вы писали:

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


M>>Для ОСОБО внимательных я привел 2 имплементации одна принимает std::string другая указатель на строку и ее длина char* size.

K>"123" ты передаешь как раз в функцию со string. но это мелочи.

Я не буду давать экскурс в С++ но кратко , стринг создается перед выполнением функции.


M>>Если знаешь как передать std::string без его создания , поделись плз.

поскипанны рассуждения не по теме.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: offtop, parse double
От: minorlogic Украина  
Дата: 17.06.08 19:05
Оценка:
Здравствуйте, eao197, Вы писали:

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


M>>Для ОСОБО внимательных я привел 2 имплементации одна принимает std::string другая указатель на строку и ее длина char* size.


E>Но при этом имея две реализации, вы передали строковый литерал туда, где ожидается std::string.

E>Если есть API, который принимает const std::string &, а при использовании ему подсовывают const char * (в виде таких вот литералов), то расходы на конструирование и уничтожение std::string-ов могут принимать очень серьезные размеры.

Ок , поменяй пример на std::string s("123"); и передавай s в качестве параметра, стало легче?


M>>Если знаешь как передать std::string без его создания , поделись плз.


E>А во многих случаях не нужен std::string. Я подсмотрел хорошее решение в библиотеке PCRE -- там есть класс StringPiece, разработанный для C++ной обертки PCRE в Google. Я сделал из него для себя вариант. Он не такой функциональный, как Google-овский, зато у него есть шаблонные конструкторы специально для строковых литералов.


Передавай ты что хочешь , какое это отношение к моему примеру имеет?


E>В некоторых случаях у меня замена const std::string & на const string_piece_t & ускоряло код в два раза.


Это достаточно ОЧЕВИДНАЯ техническая деталь , что при парсинге большого ква данных , токенайзер возвращает пару итераторов или итератор или размер , мы счас будем обсуждать технологии парсинга ? Там давно ми без меня много написанно , и поверь , никто там не копирует подстроку для обработки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: offtop, parse double
От: minorlogic Украина  
Дата: 17.06.08 19:06
Оценка: 1 (1)
Здравствуйте, Kluev, Вы писали:

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


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


M>>В конструкторе stringstream и strstream может вызываться динамическое создание обектов , но это уже на совести разработчиков STL имплементации.


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


Даю гениальную рекомендацию, попробуйте не работать с STL и Boost? или вас ктонить принуждает ? тогда это вопрос не этого форума.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Вообще не понимаю, о чем разговор...
От: minorlogic Украина  
Дата: 17.06.08 19:08
Оценка:
Здравствуйте, Kluev, Вы писали:

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


D>>как можно всерьез обсуждать кусок кода, который даже собрать без геморроя нельзя? тем более такой кусок, который жрет числа вида -.A и не давится?


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

K>и оттестирован на всех возможных use case в реальных условиях.

Ты просто не понимаешь разницу между велосипедом и индустриальной библиотекой. Многие другие , достаточно серьезно относятся к качеству используемых библиотек.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 19:44
Оценка:
Здравствуйте, minorlogic, Вы писали:

E>>Если есть API, который принимает const std::string &, а при использовании ему подсовывают const char * (в виде таких вот литералов), то расходы на конструирование и уничтожение std::string-ов могут принимать очень серьезные размеры.


M>Ок , поменяй пример на std::string s("123"); и передавай s в качестве параметра, стало легче?


А что, так лишнее выделение памяти внутри std::string куда-то исчезло?

M>Это достаточно ОЧЕВИДНАЯ техническая деталь , что при парсинге большого ква данных , токенайзер возвращает пару итераторов или итератор или размер , мы счас будем обсуждать технологии парсинга ? Там давно ми без меня много написанно , и поверь , никто там не копирует подстроку для обработки.


В идеальном мире идеальные программисты пишут идеальные программы. Остается только позавидовать тому, что вы находитесь в том идеальном мире, а я -- нет.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: offtop, parse double
От: minorlogic Украина  
Дата: 17.06.08 20:28
Оценка: :))
Здравствуйте, eao197, Вы писали:

E>А что, так лишнее выделение памяти внутри std::string куда-то исчезло?


Егор , учи матчасть. Объект передается по ссылке. икаких копирований нет .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[8]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.06.08 20:42
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

E>>А что, так лишнее выделение памяти внутри std::string куда-то исчезло?


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


Это не Егор, это Евгений
Чтобы передать объект по ссылке, его сначала нужно создать. Вот при создании new и вызовется.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: offtop, parse double
От: minorlogic Украина  
Дата: 17.06.08 21:10
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


E>>>А что, так лишнее выделение памяти внутри std::string куда-то исчезло?


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


E>Это не Егор, это Евгений

E>Чтобы передать объект по ссылке, его сначала нужно создать. Вот при создании new и вызовется.

Прошу прощения.

Объект создается вне функции парсинга строки. Я декларировал только парсинг. Очевидно что объект необходимо создать и он алоцирует динамически память под строку(by design).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[17]: boost - вон из профессии
От: johny5 Новая Зеландия
Дата: 17.06.08 23:44
Оценка:
K>Это все хорошо пока снаружи нет ссылок на person. а если они потребуются, то указатели использовать, нельзя индексы тоже могуть "уплыть". Единственый гарантированный способ достучатся до person — уникальный id и поиск по всему вектору при каждом обращении.
K>Имхо такая схема настолько неудобна, что не стоит того выигрыша в производительности который она даст (если этот выигрыш кончано find не сожрет).

* list, vector в данной ситуации имеют общую проблему, но даже в этом случае список всё равно будет работать медленнее из-за непоследовательного чтения памяти (кэш процессора).
* нужен быстрый поиск по id? используйте map<id, ...> для больших массивов
Re[11]: offtop, parse double
От: Erop Россия  
Дата: 18.06.08 05:20
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Хочешь, чтобы что-то было в С++, и не видишь соответствующего предложения на их сайте?

J>Так напиши сам, потрать время и силы, предложи, убеди всех, что это действительно позарез нужно — и все будет, и все тебе спасибо скажут.
Я не верю, что идея string_piece не обсуждалась.

J>А так я могу тебе твою же претензию и развернуть: "Имярек, а почему это до сих пор этого нет в Стандарте?! Что за лень и халатность? Ты что, совсем не думаешь о простых разработчиках, которые страдают без этой фичи?"

IMHO стандарт С++ давно уже перестал быть поддерживаем. А STL утратил цельность при попадании в стандарт. Соответсвенно что делать -- не понятно. Если кто-то умеет править стандарт, то он может попробовать написать предложение по непротиворечивому внесению string_piece.
Я, например, не возьмусь...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: offtop, parse double
От: lollipop  
Дата: 18.06.08 05:23
Оценка:
Здравствуйте, minorlogic, Вы писали:

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


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


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


M>>>В конструкторе stringstream и strstream может вызываться динамическое создание обектов , но это уже на совести разработчиков STL имплементации.


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


M>Даю гениальную рекомендацию, попробуйте не работать с STL и Boost? или вас ктонить принуждает ? тогда это вопрос не этого форума.


Дык варианты то остались — платные проприетарные библиотеки. Всегда легче погнать на опен сорс — что там что то реализовано "криво" и нетак. Чем купить — это насчёт буста.
Насчёт STL — чем стандарт С++ неугодил ? Никто не сомневается в проффесионализме (чесно не ехидничаю), но вот я как то больше склонен со Страуструпом согласиться.

А вобще раз boost это напрочь кривая штука , а STL мракобесье может посоветуете Free Open Source библиотеку чтоб портировалась на Win\All Unix ? с удовольствием буду её юзать.
Re[6]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.06.08 06:45
Оценка:
Здравствуйте, night beast, Вы писали:

E>>А во многих случаях не нужен std::string. Я подсмотрел хорошее решение в библиотеке PCRE -- там есть класс StringPiece, разработанный для C++ной обертки PCRE в Google. Я сделал из него для себя вариант. Он не такой функциональный, как Google-овский, зато у него есть шаблонные конструкторы специально для строковых литералов.


NB>не сочти за придирку, но строковые литералы с С++ передаются по ссылке:

NB>
NB>      template< size_t LEN >
NB>      string_piece_t( const char (&ptr)[ LEN ] )
NB>

NB>хотя в данном случае сработает не-шаблонный конструктор...

Большое спасибо!

Постарался исправить и залил новую версию.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: offtop, parse double
От: night beast СССР  
Дата: 18.06.08 07:17
Оценка:
Здравствуйте, eao197, Вы писали:

NB>>не сочти за придирку, но строковые литералы с С++ передаются по ссылке:

NB>>
NB>>      template< size_t LEN >
NB>>      string_piece_t( const char (&ptr)[ LEN ] )
NB>>

NB>>хотя в данном случае сработает не-шаблонный конструктор...

E>Большое спасибо!


ну это не ошибка была.

E>Постарался исправить и залил новую версию.


ну еще тебя потерраризирую
попробуй код
string_piece_t x (0);


и еще вопрос, почему бы не сделать
      static const int no_type = 0;
      static const int string_literal = 1;
      static const int null_terminated = 2;
      static const int std_basic_string = 3;
      static const int array_fragment = 4;

enum'ом?
Re[10]: offtop, parse double
От: Erop Россия  
Дата: 18.06.08 07:50
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Апачевская либа работает не очень?

J>Что не так?
Копеировать тело можно и пореже.

E>>Ну, например, посмори на CString...

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

Есть специальные методы для модификации.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Учи буквы!
От: Erop Россия  
Дата: 18.06.08 07:58
Оценка:
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, eao197, Вы писали:
M>Егор , учи матчасть. Объект передается по ссылке. икаких копирований нет .
Я тебе уже снюсь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.06.08 08:07
Оценка:
Здравствуйте, night beast, Вы писали:

E>>Большое спасибо!


NB> ну это не ошибка была.


Как по мне, так это была большая ошибка. Т.к. шаблонные конструкторы не отрабатывали там, где должны были.

E>>Постарался исправить и залил новую версию.


NB>ну еще тебя потерраризирую

NB>попробуй код
NB>
NB>string_piece_t x (0);
NB>


Пока нечего не приходит в голову, как это обойти.
В принципе, такое поведение можно считать by design, так же, как это происходит в std::string.
Тем более, что вот в таком случае:
const char * p = 0;
string_piece_t x( p );

отрабатывает нормально.

Разве что добавить private конструктор string_piece_t(int).

NB>и еще вопрос, почему бы не сделать

NB>
NB>      static const int no_type = 0;
NB>      static const int string_literal = 1;
NB>      static const int null_terminated = 2;
NB>      static const int std_basic_string = 3;
NB>      static const int array_fragment = 4;
NB>

NB>enum'ом?

А разницы все равно большой нет. Тем более, что это все используется только в unit-тесте проверки string_piece_t.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: offtop, parse double
От: night beast СССР  
Дата: 18.06.08 08:38
Оценка: 4 (1)
Здравствуйте, eao197, Вы писали:

NB>>ну еще тебя потерраризирую

NB>>попробуй код
NB>>string_piece_t x (0);


E>Пока нечего не приходит в голову, как это обойти.


"есть одно средство..." (с)
struct string_piece_t {
private:
   struct ptv_inner;
public:
   string_piece_t( ptv_inner * );
};

не знаю только, стоит ли овчинка выделки.

NB>>и еще вопрос, почему бы не сделать

NB>>      static const int no_type = 0;
NB>>      static const int string_literal = 1;
NB>>      static const int null_terminated = 2;
NB>>      static const int std_basic_string = 3;
NB>>      static const int array_fragment = 4;

NB>>enum'ом?

E>А разницы все равно большой нет. Тем более, что это все используется только в unit-тесте проверки string_piece_t.


так бы в одну строчку влезло да и тип свой был бы...
ну а что до юнит тестов, то есть ли большая разница, пишешь ты юнит-тест или прикладную программу?
Re[10]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.06.08 09:04
Оценка:
Здравствуйте, night beast, Вы писали:

NB>"есть одно средство..." (с)

NB>
NB>struct string_piece_t {
NB>private:
NB>   struct ptv_inner;
NB>public:
NB>   string_piece_t( ptv_inner * );
NB>};
NB>

NB>не знаю только, стоит ли овчинка выделки.

Имхо, это то же самое, что и:
class string_piece_t {
  private :
    string_piece_t(int);
  public : ...
};


Посольку этот конструктор будет задействоваться только для случая string_piece_t(0). А литерал 0, если не ошибаюсь, имеет тип int по умолчанию.

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

Disclaimer: все это я излагаю в предположении, что конструкция string_piece_t(0) является ошибочной по определению, и компилятор сразу должен указывать разработчику на это.

NB>>>и еще вопрос, почему бы не сделать

NB>
NB>>>      static const int no_type = 0;
NB>>>      static const int string_literal = 1;
NB>>>      static const int null_terminated = 2;
NB>>>      static const int std_basic_string = 3;
NB>>>      static const int array_fragment = 4;
NB>

NB>>>enum'ом?

E>>А разницы все равно большой нет. Тем более, что это все используется только в unit-тесте проверки string_piece_t.


NB>так бы в одну строчку влезло да и тип свой был бы...


Да я просто не большой любитель enum-ов в C++.

NB>ну а что до юнит тестов, то есть ли большая разница, пишешь ты юнит-тест или прикладную программу?


К unit-тестам я предъявляю гораздо более низкие требования, чем к прикладной программе. Так что разница, наверное, есть.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: offtop, parse double
От: night beast СССР  
Дата: 18.06.08 09:16
Оценка:
Здравствуйте, eao197, Вы писали:

E>Посольку этот конструктор будет задействоваться только для случая string_piece_t(0). А литерал 0, если не ошибаюсь, имеет тип int по умолчанию.


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


E>Disclaimer: все это я излагаю в предположении, что конструкция string_piece_t(0) является ошибочной по определению, и компилятор сразу должен указывать разработчику на это.


я писал исходя из обратного предположения
у тебя же
char * x = 0;
string_piece_t y(x);

нормально работает? почему тогда string_piece_t (0) не должен работать?
можно было сделать его дефолтным конструктором.
Re[12]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.06.08 09:27
Оценка:
Здравствуйте, night beast, Вы писали:

E>>Disclaimer: все это я излагаю в предположении, что конструкция string_piece_t(0) является ошибочной по определению, и компилятор сразу должен указывать разработчику на это.


NB>я писал исходя из обратного предположения

NB>у тебя же
NB>
NB>char * x = 0;
NB>string_piece_t y(x);
NB>

NB>нормально работает? почему тогда string_piece_t (0) не должен работать?

Потому что в коде может быть так:
const char * make_some_name() { ... return ...; }
void f( const string_piece_t & sp ) { ... }
...
f( make_some_name() );

Из-за какой-то ошибки make_some_name может возвратить нулевой указатель, на этапе компиляции это отследить невозможно. Но string_piece_t при вызове f() не должен ломаться из-за этого. И эта ситуация сейчас в string_piece_t обрабатывается.

А вот когда разработчик в коде пишет явно string_piece_t(0), то здесь вообще не понятно, зачем это ему нужно, скорее всего это следствие ошибки разработчика. Пустой string_piece_t можно получить и существующим конструктором по умолчанию -- это будет явно выглядеть в коде как создание пустой строки. Поэтому и хочется поставить конструкцию string_piece_t(0) вне закона. А то сейчас можно написать std::string(0), но ничего хорошего из этого не получается.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: boost - вон из профессии
От: Stepkh  
Дата: 18.06.08 13:23
Оценка:
Здравствуйте, Kluev, Вы писали:

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


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


L>>>>>>2. Неясно, что будет, если разделитель — запятая.

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

Это кто сказал? В России если мне не изменяет память стандартный разделитель — это запятая. Кстати, знаю одну очень страшную историю из жизни когда одну очень очень дорогую (а может даже не очень) но шибко навороченную биллинговую систему продали в Испанию. А там — представьте себе — законный разделитель это запятая. Даже в текстовых файлов. Как пришлось попотеть разработчикам...

П.С.
А это знаменитый баг в Accesse — когда надо было ставить системный разделитель точку поскольку Access не умел обрабатывать друнгие разделители в своем SQL...
Re: boost - вон из профессии
От: COFF  
Дата: 18.06.08 14:46
Оценка: +3
Меня это обсуждение заставило задуматься. До этого я неявно воспринимал буст как набор качественного и оптимизированного кода, который некие неведомые высококлассные программисты делают для всеобщего пользования. Неявно — потому что я просто не задумывался над этим, просто вот было такое убеждение и все. Да и не так много чего из буста я использую — только указатели. Хотя казалось бы именно опыт с указателями был весьма наглядным. Я впервые посмотрел их лет пять назад и их реализация тогда меня несколько удивила — в многопоточной версии на каждый указатель создавалась своя критическая секция, мне это показалось подозрительным, я отложил это дело и продолжал пользоваться хорошо знакомым велосипедом. В итоге проблему решили, но ведь действительно, получается, что буст — это просто свалка разнородного кода, который находится в разной степени зрелости :) Какие-то вещи доведены до ума, потому что они важны и нужны, какие-то доводятся, а какие-то так и остаются в зачаточном состоянии. Что-то вылизано, а что-то лежит, просто потому что это положили :) Т.е. нельзя что-то просто взять и пользоваться, нет уверенности в качестве — любую нужную функциональность надо тщательно смотреть изнутри. Вот об этом я как-то раньше не думал и спасибо автору исходного сообщения за то, что поднял эту тему :)
Re[14]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 18.06.08 15:26
Оценка:
Здравствуйте, eao197, Вы писали:

E>С другой стороны, не все пишут код, который потом индусы будут саппортить

Пишут-то, может, и не все, а вот не будут ли его потом саппортить индусы...

J>>А насчет библиотек — ну вокруг чего-то ведь надо концентрировать усилия, иначе ведь зоопарк будет.

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

E>А собственно, почему бы и нет? Пусть развиваются как хотят -- хорошие библиотеки, предоставляющие удобные интерфейсы и качественные реализации будут выживать.


Интерфейсы должны быть совместимыми (или должен быть простой путь их совмещения, типа специализации boost::range). А так — конечно, пусть что угодно будет.

E>Более качественный подход, на мой взгляд -- это дать библиотеке самостоятельно жить до тех пор, пока она не станет достаточно распространенной сама по себе. А уже потом принимать решение о ее "иконизации" (как это было в Java с Log4J).


Ты, возможно, этого не ожидал, но ты чуть ли не цитируешь основополагающий документ Буста (http://www.boost.org/users/proposal.pdf, 1998 год, его стоит целиком прочитать):

(из FAQ)
Will the libraries become part of the next C++ Standard? No. But to the extent a library becomes
“existing practice”,
the likelihood increases that someone might propose it for future standardization.

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[15]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.06.08 15:42
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>Ты, возможно, этого не ожидал, но ты чуть ли не цитируешь основополагающий документ Буста (http://www.boost.org/users/proposal.pdf, 1998 год, его стоит целиком прочитать):

J>

J>(из FAQ)
J>Will the libraries become part of the next C++ Standard? No. But to the extent a library becomes
J>“existing practice”,
the likelihood increases that someone might propose it for future standardization.


Ну если глянуть на ряд библиотек, которые были приняты в Boost 1.34 и 1.35, то многие из них стали широко распространенными и достаточно взрослыми до включения в Boost? Или часть из них специально писалась под Boost?

Asio, Circular Buffer, Foreach, Fusion, GIL, Interprocess, Intrusive, MPI, Math/Special Functions, Math/Statistical Distributions, Statechart, System, Typeof, Xpressive


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: offtop, parse double
От: jazzer Россия Skype: enerjazzer
Дата: 18.06.08 16:33
Оценка:
Здравствуйте, eao197, Вы писали:

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


J>>Ты, возможно, этого не ожидал, но ты чуть ли не цитируешь основополагающий документ Буста (http://www.boost.org/users/proposal.pdf, 1998 год, его стоит целиком прочитать):

J>>

J>>(из FAQ)
J>>Will the libraries become part of the next C++ Standard? No. But to the extent a library becomes
J>>“existing practice”, the likelihood increases that someone might propose it for future standardization.


E>Ну если глянуть на ряд библиотек, которые были приняты в Boost 1.34 и 1.35, то многие из них стали широко распространенными и достаточно взрослыми до включения в Boost? Или часть из них специально писалась под Boost?


Причем тут включение в Буст, когда мы говорим о включении в Стандарт? Давай не перескакивать с одного на другое. А чтобы попасть в стандарт, библиотека должна стать распространенной, независимо от того, в бусте она или нет — вот что написано в приведенной цитате.

Буст предложен просто как центральный репозиторий библиотек, оформленных в едином стиле (дабы облегчить будущую стандартизацию, если таковая запланируется), отревьюенных живыми действующими программистами (это не закрытый клуб, любой (и ты!) может написать свое ревью на любую предложенную библиотеку, и его голос, за или против, будет зачтен), а не левыми теоретиками, как тут некоторые любят говорить про буст.
Просто возьмите и почитайте наугад несколько обсуждений предложенных библиотек — и сами в этом убедитесь.
Например, очень часто появляются ревью в стиле "очень хорошо, что предложена такая библиотека, потмоу что у нас на раобте есть точно такая же велосипедная, так вот она лучше потому-то и потому-то", и дальше начинается бурное обсуждение, с бенчмарками и прочим. И так просто абы что ты не в буст не просунешь. И по результатам ревью (независимо от того, положительное оно или отрицательное) обычно выкатывается длиннющий список претензий, которые надо пофиксить перед коммитом или повторным предложением (например, библиотека для логирования прошла уже два ревью и до сих пор не принята: http://thread.gmane.org/gmane.comp.lib.boost.announce/182).

E>Asio, Circular Buffer, Foreach, Fusion, GIL, Interprocess, Intrusive, MPI, Math/Special Functions, Math/Statistical Distributions, Statechart, System, Typeof, Xpressive


Смотри в раздел History соответствующих библиотек. Я не историк буста. Из того ,чтоя знаю — GIL писалась адобом для себя, MPI уже тыщу лет как есть, Foreach — это вообще велосипед, который почти у каждого есть, MultiIndex была популярной библиотекой, но придя в boost, проапгрейдилась настолько, что концов уже и не видно (и, к слову сказать, достойных альтернатив не видно).
Xpressive, Fusion писались сразу для boost, как устранение проблем и расширение Spirit и MPL соответственно.
В любом случае, отношения к стандартизации это не имеет.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: Вообще не понимаю, о чем разговор...
От: Kluev  
Дата: 19.06.08 08:00
Оценка: +1 -1
Здравствуйте, minorlogic, Вы писали:

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


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


D>>>как можно всерьез обсуждать кусок кода, который даже собрать без геморроя нельзя? тем более такой кусок, который жрет числа вида -.A и не давится?


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

K>>и оттестирован на всех возможных use case в реальных условиях.

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


индустриальной я бы назвал zlib и аналогичные библиотеки хорошо сделанные и внутри и снаружи. пользоватся такими одно удовольствие. а буст — сборище велосипедов сомнительного качества.
Re[17]: offtop, parse double
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.06.08 08:09
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Причем тут включение в Буст, когда мы говорим о включении в Стандарт? Давай не перескакивать с одного на другое. А чтобы попасть в стандарт, библиотека должна стать распространенной, независимо от того, в бусте она или нет — вот что написано в приведенной цитате.


Упс... Значит boost -- это такая песочница для библиотек, которые могут со временем войти в стандарт C++. И цель этого мероприятия -- собрать некую сборную солянку, в которой библиотеки будут развиваться до тех пор, пока не станут настолько продвинутыми и, не побоюсь этого слова, пропиареными, чтобы войти в очередной TRn и далее распространяться вместе с компиляторами C++. Т.е. конечная цель того, что какая-то библиотека предлагается в boost -- это включение данной библиотеки в Стандарт.

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

J>В любом случае, отношения к стандартизации это не имеет.


Да действительно.

Обидно другое. Вот, например, есть Ruby community. Люди в нем как-то не сильно обеспокоены тем, будет включена их библиотека в стандартную библиотеку Ruby или нет. Вместо этого они просто пишут библиотеки и приложения, создают Интернет-каталоги Ruby-проектов (RubyForge и RAA). Более того, создали удобную систему дистрибуции библиотек RubyGems. В результате для какой-нибудь предметной области можно найти несколько альтернативных библиотек, оценить их и легко подключить ту, что больше понравилась.

В Java, насколько я понимаю, тоже самое происходит после появления Maven2.

А вот в C++ -- наша цель Стандарт! При этом сейчас получается, что к какой-нибудь самописной библиотеке, у которой архив исходников на 100K, нужны еще несколько мегабайт OpenSSL, десяток(!) мегабайт ACE и еще двадцать(!) мегабайт Boost-а (ради boost::regex и boost::multi_index). Красотища-то кака!

Ладно, к boost-у все это не имеет отношения. Ведь C++ не выживет без Xpressive в одном из следующих стандартов!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Вообще не понимаю, о чем разговор...
От: minorlogic Украина  
Дата: 19.06.08 09:06
Оценка:
Здравствуйте, Kluev, Вы писали:

K>индустриальной я бы назвал zlib и аналогичные библиотеки хорошо сделанные и внутри и снаружи. пользоватся такими одно удовольствие. а буст — сборище велосипедов сомнительного качества.


Ну постыдился бы говорить о качестве. После того как выложил свой код , в котором при БЕГЛОМ анализе (даже без тестов) обнаружены баги парсинга.

P.S. От того что ты большее число раз будешь опускать буст, его качество от этого не изменится.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Вообще не понимаю, о чем разговор...
От: NikeByNike Россия  
Дата: 19.06.08 09:10
Оценка:
Здравствуйте, Kluev, Вы писали:

K>индустриальной я бы назвал zlib и аналогичные библиотеки хорошо сделанные и внутри и снаружи. пользоватся такими одно удовольствие. а буст — сборище велосипедов сомнительного качества.

А мне всегда казалось, что zlib и похожие библиотеки насилуют мне мозг... Если бы они были написаны на С++ — были бы лучше и даже наверно эффективнее.
Нужно разобрать угил.
Re[6]: Вообще не понимаю, о чем разговор...
От: Erop Россия  
Дата: 19.06.08 09:19
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

M>Ну постыдился бы говорить о качестве. После того как выложил свой код , в котором при БЕГЛОМ анализе (даже без тестов) обнаружены баги парсинга.

IMHO, эти вопросы не связаны, но если таки связь пытаться найти, то твой аргумент имеет обраьную силу.
ДАЖЕ АВТОР ТАКОГО ОТСТОЙНОГО КОДА ВИДИТ УБОГОСТЬ КАЧЕСТВА БУСТа

M>P.S. От того что ты большее число раз будешь опускать буст, его качество от этого не изменится.

Увы, с ним вообще что не делай, не поможет. Насколько я понимаю нет никакого человека или института, который бы обеспечивал высокое качество включённых в буст библиотек...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Вообще не понимаю, о чем разговор...
От: minorlogic Украина  
Дата: 19.06.08 10:16
Оценка:
Мне кажется у тебя технические вопросы переходят в разрад религиозных.

"противники" STL, boost, и итераторов звучит как противники ложек и вилок или китайских палочек.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[7]: Вообще не понимаю, о чем разговор...
От: jazzer Россия Skype: enerjazzer
Дата: 19.06.08 10:54
Оценка:
Здравствуйте, Erop, Вы писали:

E>IMHO, эти вопросы не связаны, но если таки связь пытаться найти, то твой аргумент имеет обраьную силу.

E>ДАЖЕ АВТОР ТАКОГО ОТСТОЙНОГО КОДА ВИДИТ УБОГОСТЬ КАЧЕСТВА БУСТа
Или наоборот — автор такого отстойного кода берется оценивать качество буста
но это все офтопик
На всякий случай извиняюсь перед Клюевым, ему наверняка неприятна эта тема
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: Вообще не понимаю, о чем разговор...
От: Erop Россия  
Дата: 19.06.08 11:04
Оценка:
Здравствуйте, minorlogic, Вы писали:

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

M>"противники" STL, boost, и итераторов звучит как противники ложек и вилок или китайских палочек.
У тебя -- да
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Вообще не понимаю, о чем разговор...
От: Kluev  
Дата: 23.06.08 09:25
Оценка: +1
Здравствуйте, jazzer, Вы писали:

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


E>>IMHO, эти вопросы не связаны, но если таки связь пытаться найти, то твой аргумент имеет обраьную силу.

E>>ДАЖЕ АВТОР ТАКОГО ОТСТОЙНОГО КОДА ВИДИТ УБОГОСТЬ КАЧЕСТВА БУСТа
J>Или наоборот — автор такого отстойного кода берется оценивать качество буста
J>но это все офтопик

это все не обьективные критерии. в сухом остатке мы имеем:

велосипед:
+ эффективная реализация
— тестировался не во всех use case, в некоторых случая работает неправильно.

boost:
— неэфективная реализация
+ тестирован во всех use case

велосипед при этом вполне можно довести до ума дополнительным теститрованием и незначительными изменениями.
код из boost можно только переписать с нуля, т.к. это не код даже, а обертка вокруг iostream.
Re[9]: Вообще не понимаю, о чем разговор...
От: jazzer Россия Skype: enerjazzer
Дата: 23.06.08 09:58
Оценка: +2
Здравствуйте, Kluev, Вы писали:

K>это все не обьективные критерии. в сухом остатке мы имеем:


K>велосипед:

K>+ эффективная реализация
K>- тестировался не во всех use case, в некоторых случая работает неправильно.

K>boost:

K>- неэфективная реализация
K>+ тестирован во всех use case

K>велосипед при этом вполне можно довести до ума дополнительным теститрованием и незначительными изменениями.

K>код из boost можно только переписать с нуля, т.к. это не код даже, а обертка вокруг iostream.

и? какой вывод? boost::lexical_cast не для мест, где важна скорость? Так это и так было всем известно.
И в таких местах оттестированность, простота и ясность кода важнее.
А для тех мест, где критична производительность, все равно все будут писать свои велосипеды, потому что в каждом случае нужно будет что-то свое, всегда будут какие-то особенности (которые можно (и нужно!) использовать в целях оптимизации). И эти велосипеды, как в твоем случае, будут оттестированы только в тех конкретных случаях, для которых они написаны.

Вроде, очевидные вещи говорю, и сомневаюсь, что ты сам это все не можешь сказать.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 23.06.08 10:03
Оценка:
Кстати, раз уж здесь пошла критика Boost-а, то вот еще один камешек в их огород. Теперь уже от разработчика библиотеки OTL:

Another aspect was that OTL is still a one-man project. I was hoping that by now (it's 2008!) the C++ standardization committee would have come up with a decent standard for a C++ database access library (hopefully something stream based), and I'd have joined a larger team of architects and developers working on that task. The C++ standardization effort is represented by the "boost(.org) crowd" for the most part. The boost people, instead of making any progress, just bitch and moan that "database people" don't know enough about how C++ is supposed to be used, at least OTL is not up to their high standards, it's just a hack.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 23.06.08 10:38
Оценка:
Здравствуйте, eao197, Вы писали:

E>Кстати, раз уж здесь пошла критика Boost-а, то вот еще один камешек в их огород. Теперь уже от разработчика библиотеки OTL:

E>

E>Another aspect was that OTL is still a one-man project. I was hoping that by now (it's 2008!) the C++ standardization committee would have come up with a decent standard for a C++ database access library (hopefully something stream based), and I'd have joined a larger team of architects and developers working on that task. The C++ standardization effort is represented by the "boost(.org) crowd" for the most part. The boost people, instead of making any progress, just bitch and moan that "database people" don't know enough about how C++ is supposed to be used, at least OTL is not up to their high standards, it's just a hack.


Этому "камешку" определенно не хватает ссылок на соответствующие высказывания "boost people".
Быстрый поиск "OTL" по мейл-листу ничего подобного не показал (я намеренно выбрал только сообщения от людей, которые имеют вес в бусте (и нашел только одного — Джеффа Гарланда, одного из модераторов мейл-листа), хотя, напоминаю, буст — это open source, так что предлагать библиотеки и писать отзывы может каждый, и таких отзывов там очень много):
http://article.gmane.org/gmane.comp.lib.boost.devel/80291/match=otl
http://article.gmane.org/gmane.comp.lib.boost.devel/111888/match=otl

I'd really like to somehow see the authors of DTL, OTL, etc come together and work on a boost proposal. Each of these libraries in my view brings something to the table -- including baggage. If we could get all the experts pulling together I'm sure they would produce something great for the larger C++ community in fairly short order.

несколько противоречит высказыванию Сергея, не находишь?

Вот ссылка на бустовкую вики: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Database_Access_Library

Ждем ссылку, которая подтвердит слова Сергея.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 23.06.08 11:12
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ждем ссылку, которая подтвердит слова Сергея.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 23.06.08 13:54
Оценка:
Здравствуйте, eao197, Вы писали:

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


J>>Ждем ссылку, которая подтвердит слова Сергея.


E>Этой ссылки может не быть, если подобная оценка была получена Сергеем в частной переписке или личной беседе.


т.е. ты считаешь, что в бусте такие вот страшные двуличные интриганы сидят, которые во всеуслышание заявляют, что OTL — хорошая библиотека и было бы клево, если бы ее автор с другими сделал "золотой стандарт", а в частной переписке его гнобят?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 23.06.08 14:12
Оценка:
Здравствуйте, jazzer, Вы писали:

E>>Этой ссылки может не быть, если подобная оценка была получена Сергеем в частной переписке или личной беседе.


J>т.е. ты считаешь, что в бусте такие вот страшные двуличные интриганы сидят, которые во всеуслышание заявляют, что OTL — хорошая библиотека и было бы клево, если бы ее автор с другими сделал "золотой стандарт", а в частной переписке его гнобят?


Я думаю, что было как-то так: кто-то из boost-оводов в личной беседе с Кучиным высказался в том духе, что было бы хорошо иметь стандартную библиотеку для C++. С идеями, в том числе, из OTL. Но сама OTL не потянет на роль такой библиотеке, т.к. представляет из себя набор хаков, и не соответствует требованиям, предъявляемым boost-ом к своим библиотекам.

И я не вижу здесь противоречий: boost-оводы хотят, чтобы Кучин занялся разработкой стандартной библиотеки для C++, но им не нравится реализация OTL (о последнем и говорит Кучин).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 23.06.08 18:01
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>>>Этой ссылки может не быть, если подобная оценка была получена Сергеем в частной переписке или личной беседе.


J>>т.е. ты считаешь, что в бусте такие вот страшные двуличные интриганы сидят, которые во всеуслышание заявляют, что OTL — хорошая библиотека и было бы клево, если бы ее автор с другими сделал "золотой стандарт", а в частной переписке его гнобят?


E>Я думаю, что было как-то так: кто-то из boost-оводов в личной беседе с Кучиным высказался в том духе, что было бы хорошо иметь стандартную библиотеку для C++. С идеями, в том числе, из OTL. Но сама OTL не потянет на роль такой библиотеке, т.к. представляет из себя набор хаков, и не соответствует требованиям, предъявляемым boost-ом к своим библиотекам.


Если у тебя есть контакт с Сергеем, можешь спросить его об этом? А то что мы гадаем на кофейной гуще...

E>И я не вижу здесь противоречий: boost-оводы хотят, чтобы Кучин занялся разработкой стандартной библиотеки для C++, но им не нравится реализация OTL (о последнем и говорит Кучин).


не Кучин, а Кучин сотоварищи, т.е. разработчики других библиотек.
Так как, очевидно, они на этом собаку съели (Кучин сотоварищи, а не бустоводы).
Поэтому бустоводы хотят, чтобы они все "сели за стол переговоров" (в общем мейллисте), обсудили честно все достоинства и недостатки каждой из библиотек (а их там полтора десятка), вместе сформулировали бы требования и вместе написали бы библиотеку, которая утрет нос всяким LINQ и станет стандартом де-факто для общения на C++ с любыми базами данных, заслужив себе всемирный почет и уважуху. Никто лучше авторов заслуженных библиотек (включая OTL) этого не сделает.

Имхо, Гарланд сказал ровно эти слова, и про качество конкретно OTL он ничего отрицательного не говорил (по крайней мере, цитаты не видно).
Но, естественно, прежде чем включить ее в буст, нужно сначала доказать, что она лучше всех остальных (т.е. по крайней мере умеет все то, что умеет остальные, либо делает оправданный выбор, если удовлетворить всем целям одновременно невозможно) и, естественно, нужно ее привести в соответствие с бустовскими стандартами (которые совсем не драконовские, см. здесь: http://www.boost.org/development/requirements.html).
И, ксатти, насчет доказательства лучшести — тут совсем не будут играть роли личные пристрастия бустоводов, просто как только библиотека будет выложена на ревью, люди, пользующие другие библиотеки (которые им, понятное дело, нравятся), скажут, что они голосуют против, пока предложенная библиотека не будет уметь все то же, что умеет та, которой они сейчас пользуются (вполне логичное требование, иначе зачем переходить, правильно?)

Ну и, естественно, это будет совсем нелегко, но Сергей почему-то не говорит о том, что у него просто нет времени и сил на прохождение полномасштабного ревью (что совершенно понятно и, к сожалению, является причиной стагнации многих библиотек), как о причине того, что OTL не предложена в буст, а говорит о том, что его обидели.
Но без ревью нельзя, иначе это будет не boost (a collection of peer-reviewed libraries), а просто очередной зоопарк типа sourceforge — так у нас sourceforge уже есть, зачем их одинаковые плодить...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.06.08 09:11
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>Если у тебя есть контакт с Сергеем, можешь спросить его об этом? А то что мы гадаем на кофейной гуще...


Я ему написал на gmail, но ответа пока нет. Может google мои письма в спам заносит, такое временами случается с буржуинскими почтовиками -- письма из .ru домена в спам автоматом направляют

J>Поэтому бустоводы хотят, чтобы они все "сели за стол переговоров" (в общем мейллисте), обсудили честно все достоинства и недостатки каждой из библиотек (а их там полтора десятка), вместе сформулировали бы требования и вместе написали бы библиотеку, которая утрет нос всяким LINQ и станет стандартом де-факто для общения на C++ с любыми базами данных, заслужив себе всемирный почет и уважуху. Никто лучше авторов заслуженных библиотек (включая OTL) этого не сделает.


Я не верю с то, что коллегиально можно делать такие вещи. Самые хорошие разработки (тот же STL) начинаются с идей конкретных людей и желания их воплотить. Ты сам можешь увидеть это на примере ряда бустовских библиотек, в частности, Boost.Regex.

Но тут проблема в том, что разработчики двух действительно живущих и развивающихся библиотек для работы с РСУБД из C++ (SOCI и OTL) уже воплотили свое видение того, как нужно работать с БД. И у них совершенно разные подходы. Я не верю в то, что дизайнеры SOCI и OTL смогут совместно родить какой-нибудь жизнеспособный стандарт для C++. Тем более сделать это дистанционно общаясь друг с другом через mailing-list.

Так что, когда речь заходит о более-менее прикладных областях, у Boost-а небольшой выбор: либо ждать, пока кто-нибудь решиться родить библиотеку специально для Boost-а (как это было с Boost.Asio), либо адаптировать одну из существующих библиотек, а их не так уж и много.

J>Но без ревью нельзя, иначе это будет не boost (a collection of peer-reviewed libraries), а просто очередной зоопарк типа sourceforge — так у нас sourceforge уже есть, зачем их одинаковые плодить...


Теперь я еще лучше стал понимать, что мне не нравится в Boost-е: они замахнулись на создание "единственно-правильного" зоопарка. Мол мы сейчас отберем библиотеки, они войдут в стандарт языка и будет всем счастье.

Это еще может прокатывать для универсальных вещей, вроде Boost.Bind и Boost.Regex. Но когда речь заходит о более серьезных предметных областях (таких как Asio, доступ к БД, XML, SOAP и пр.) не правильно, имхо, вообще пытаться создавать стандарты. Поскольку:

— стандарт должен быть статичен. А это значит, что стандартная библиотека не будет успевать за изменениями окружающего мира. Например, сделают версию Boost.DB -- а из нее стандартную в каком-нибудь tr2. А потом выяснится, что РСУБД поумнели, пологовно стали объектно-реляционными, добавили специализированные (может быть даже стандартизированные на таком же уровне как SQL) средства для работы с географическими и/или историческими данными. Стандартная библиотека в принципе не сможет меняться с необходимой скоростью. Тогда как независимо существующие библиотеки смогут делать это все;

— стандарт оставляет место для откровенно провальных реализаций. Тот же STL из каробки в VC++ сливает в некоторых случаях STL из gcc. Получается, что если хочешь иметь эффективный STL везде, то таскай с собой STLPort. А раз так, то не суть важно, что STLPort реализует стандартный STL, все равно программа зависит от конкретной библиотеки (особенно, если еще и задействовать hash_map-ы, которых нет в STL вообще). Точно так же можно иметь быструю программу, использующую std::tr2::db под Unix-ом, которая начнет тормозить под VC++ из-за того, что у VC++ своя реализация std::tr2::db.

— стандарт будет душить конкуренцию. Сейчас есть ряд библиотек, конкурирующих между собой (для IPC это, например, ACE, Poco, Boost). И это хорошо, так как происходит не только взаимное проникновение идей, но и предложение каждой из них каких-то своих уникальных идей. Например, у ACE есть Procator-ы и TimerQueue, которых нет у конкурентов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 25.06.08 17:07
Оценка: +1
Здравствуйте, eao197, Вы писали:

J>>Если у тебя есть контакт с Сергеем, можешь спросить его об этом? А то что мы гадаем на кофейной гуще...


E>Я ему написал на gmail, но ответа пока нет. Может google мои письма в спам заносит, такое временами случается с буржуинскими почтовиками -- письма из .ru домена в спам автоматом направляют


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

E>Я не верю с то, что коллегиально можно делать такие вещи. Самые хорошие разработки (тот же STL) начинаются с идей конкретных людей и желания их воплотить. Ты сам можешь увидеть это на примере ряда бустовских библиотек, в частности, Boost.Regex.

E>Но тут проблема в том, что разработчики двух действительно живущих и развивающихся библиотек для работы с РСУБД из C++ (SOCI и OTL) уже воплотили свое видение того, как нужно работать с БД. И у них совершенно разные подходы. Я не верю в то, что дизайнеры SOCI и OTL смогут совместно родить какой-нибудь жизнеспособный стандарт для C++. Тем более сделать это дистанционно общаясь друг с другом через mailing-list.

На примере буста — Boost.Fusion, Boost.MPL делали несколько человек, и обсуждение было именно в мейл-листах. Так что нет ничего невозможного.
Наверняка есть и другие "многоавторные" библиотеки, нет времени смотреть сейчас.

E>Так что, когда речь заходит о более-менее прикладных областях, у Boost-а небольшой выбор: либо ждать, пока кто-нибудь решиться родить библиотеку специально для Boost-а (как это было с Boost.Asio), либо адаптировать одну из существующих библиотек, а их не так уж и много.


и? у кого-то больший выбор?

J>>Но без ревью нельзя, иначе это будет не boost (a collection of peer-reviewed libraries), а просто очередной зоопарк типа sourceforge — так у нас sourceforge уже есть, зачем их одинаковые плодить...


E>Теперь я еще лучше стал понимать, что мне не нравится в Boost-е: они замахнулись на создание "единственно-правильного" зоопарка. Мол мы сейчас отберем библиотеки, они войдут в стандарт языка и будет всем счастье.


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


E>— стандарт должен быть статичен.

Версии стандата никуда не делись. И deprecation тоже никуда не делась, можешь посмотреть в текущем драфте, сколько уехало туда.

E>— стандарт оставляет место для откровенно провальных реализаций.

И что?
Он и для откровенно провальных реализаций компиляторов оставляет место, вспомни борландовские и сановские компиляторы. Это вообще не в компетенции стандарта. И не зависит от стандарта вообще, скажем, в мире дофига отстойных читалок и нечитабельных файлов XML — так что, в этом стандарт XML виноват? Или там дофига отстойных COM-объектов. Или там дофига браузеров — так что, в качестве плохих браузеров виноват стандарт HTML, который описывает, как страничка должна рендериться? Стандарт С++ — это то же, что и стандарт HTML: описан интерфейс и обязательные правила (в случае стандартной библиотеки — асимптотическая сложность алгоритмов), а в их рамках — вертись как хочешь.

E>— стандарт будет душить конкуренцию.

Почему-то наличие в стандарте std::auto_ptr не задушило Boost.SmartPtr, std::map — Boost.MultiIndex, std::list — Boost.Intrusive, std::string — Boost.StringAlgo, std::iostream — Boost.Iostream, а std::bind1st сотоварищи — Boost.Bind и Boost.Lambda (список можно дальше продолжать). Более того, Boost.Bind теперь в стандарте, а std::bind1st — deprecated. А Boost.Lambda — не в стандарте, и опять же не видно, чтоб Boost.Bind и Boost.Lambda сильно между собой дрались, наоборот, они взаимно обогащаются, например, Boost.Bind с версии 1.33 стал поддерживать операторы (то, что изначально было в Boost.Lambda), так что можно в простых случаях обойтись простым байндом (который поддерживается практически всеми существующими компиляторами) там, где раньше нельзя было и приходилось юзать тяжелую лямбду или писать свой функтор.
А еще ближе пример — Клюев и Егор, которых существующий уже 10 лет STL не душит никак — они сидят себе на своих библиотеках (конкурирующих с STL) и дальше будут сидеть.
Да и в Java, например, был стандартный JDBC — и ничего, Hibernate не задушился от этого, вполне себе цветет и пахнет.

Так что не надо сгущать краски и наделять стандарт сверхъестественными полицейскими способностями.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.06.08 17:36
Оценка: +1
Здравствуйте, jazzer, Вы писали:

E>>Так что, когда речь заходит о более-менее прикладных областях, у Boost-а небольшой выбор: либо ждать, пока кто-нибудь решиться родить библиотеку специально для Boost-а (как это было с Boost.Asio), либо адаптировать одну из существующих библиотек, а их не так уж и много.


J>и? у кого-то больший выбор?


Имхо, это вообще не правильный подход -- делать что-то для Boost-а для того, чтобы затем это попало в стандарт. Но, см. ниже.

J>Ну то есть ты в принципе против стандартной библиотеки как таковой, независимо от того, кем и как она делается


К стандартам у меня настороженное отношение. В особенности, из-за ODMG-93. Да и сейчас SQL хорошим примером является

J>Я тебе этот вопрос уже задавал в прошлой нашей дискуссии, но ты на него тогда не ответил, сейчас, похоже, наконец отвечаешь


Я так отвечу: после стольких лет существования откровенно маленькой стандартной библиотеки C++ делать попытку создать большую новую стандартную библиотеку для C++ не разумно. На мой взгляд, более разумный путь в том что-бы:

— обновлять стандартную библиотеку некоторыми общеупотребительными компонентами (вроде того, как это сделано в std::tr1, разве что без regex). Делать это нужно периодически с относительно малым периодом (1.5-2 года);

— строить и развивать систему, позволяющуюю подключать в C++ проекты разные библиотеки. Для того, чтобы не было таких монстров, как 10-мегабайтный ACE, 20-мегабайтный Boost, 10-мегабайтный ICU и т.д. Скажем, если мне нужен boost::move и boost::string_algo, я должен подключить именно их (+необходимые им зависимости). Для того, чтобы подобная система работала нужны какие-то унифицированные системы сборки и системы управления пакетами, средства адаптации под особенности платформы (то бишь autoconf must die! ).

Такая организация мне больше нравится, чем концентрация усилий части C++ников вокруг Boost-а. При том, что есть часть C++ников, которая не может использовать существующий Boost по ряду объективных и субъективных причин.

Надеюсь, что я ответил на твой вопрос. Если нет -- то спрашивай еще, я с удовольствием отвечу.

Алаверды, я прошу тебя ответить вот на это сообщение (боюсь, что ты его пропустил): http://www.rsdn.ru/forum/message/2989807.1.aspx
Автор: eao197
Дата: 17.06.08


E>>— стандарт должен быть статичен.

J>Версии стандата никуда не делись. И deprecation тоже никуда не делась, можешь посмотреть в текущем драфте, сколько уехало туда.

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

E>>— стандарт оставляет место для откровенно провальных реализаций.

J>И что?
J>Он и для откровенно провальных реализаций компиляторов оставляет место, вспомни борландовские и сановские компиляторы. Это вообще не в компетенции стандарта.

Тем не менее, смотри что получается: сейчас люди создают работающие библиотеки, которые тестируются в составе Boost-а. У них нормальная реализация, которая постоянно шлифуется. Затем она попадает в стандарт. Какой-нибудь MS делает ее свою реализацию. В чем смысл создания других реализаций?

А если все используют одни и те же исходники, то в чем смысл стандартизации вообще?

E>>— стандарт будет душить конкуренцию.

J>Почему-то наличие в стандарте std::auto_ptr не задушило Boost.SmartPtr,

Я, например, про Boost.SmartPtr не знал. Или под этим shared_ptr скрывается?

J> std::map — Boost.MultiIndex, std::list — Boost.Intrusive, std::string — Boost.StringAlgo


Имхо, это вообще не конкуренты. Конкурент std::map-а -- это, например, ACE_Map_Manager.

J>А еще ближе пример — Клюев и Егор, которых существующий уже 10 лет STL не душит никак — они сидят себе на своих библиотеках (конкурирующих с STL) и дальше будут сидеть.


STL вообще достаточно специфичен -- та его часть, которая касается контейнеров, вообще не имеет себе равных, имхо. Это именно то, что нужно было для C++. Но, с другой стороны, std::string и iostream далеко не самые удачные примеры. И более удобный класс строк, например, не помешал бы. Да только где он?

J>Да и в Java, например, был стандартный JDBC — и ничего, Hibernate не задушился от этого, вполне себе цветет и пахнет.


Имхо, JDBC и Hibernate на разных полюсах находятся.

J>Так что не надо сгущать краски и наделять стандарт сверхъестественными полицейскими способностями.


Я всего лишь выражаю свои опасения, что для ряда предметных областей наличие стандарта не даст ничего хорошего. К БД это в частности и относится.

Ну не будет у C++ таких средств, чтобы сделать конкурента JDBC, не говоря уж о LINQ. А делать для стандарта что-нибудь лишь бы для стандарта так же не очень правильно.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: boost - вон из профессии
От: Mamut Швеция http://dmitriid.com
Дата: 26.06.08 06:54
Оценка: +2
E>- строить и развивать систему, позволяющуюю подключать в C++ проекты разные библиотеки. Для того, чтобы не было таких монстров, как 10-мегабайтный ACE, 20-мегабайтный Boost, 10-мегабайтный ICU и т.д. Скажем, если мне нужен boost::move и boost::string_algo, я должен подключить именно их (+необходимые им зависимости). Для того, чтобы подобная система работала нужны какие-то унифицированные системы сборки и системы управления пакетами, средства адаптации под особенности платформы (то бишь autoconf must die! ).

Perl CPAN/Ruby Gems но для С++? Было бы здорово
... << RSDN@Home 1.2.0 alpha 4 rev. 1091>>


dmitriid.comGitHubLinkedIn
Re[11]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 26.06.08 07:12
Оценка:
Здравствуйте, Mamut, Вы писали:

E>>- строить и развивать систему, позволяющуюю подключать в C++ проекты разные библиотеки. Для того, чтобы не было таких монстров, как 10-мегабайтный ACE, 20-мегабайтный Boost, 10-мегабайтный ICU и т.д. Скажем, если мне нужен boost::move и boost::string_algo, я должен подключить именно их (+необходимые им зависимости). Для того, чтобы подобная система работала нужны какие-то унифицированные системы сборки и системы управления пакетами, средства адаптации под особенности платформы (то бишь autoconf must die! ).


M>Perl CPAN/Ruby Gems но для С++?


Именно!

M>Было бы здорово


Ну вот, а я уж начал думать, что никому кроме меня это не нужно


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: boost - вон из профессии
От: Mamut Швеция http://dmitriid.com
Дата: 26.06.08 07:25
Оценка:
M>>Было бы здорово

E>Ну вот, а я уж начал думать, что никому кроме меня это не нужно


Многие просто не знают/не догадываются, что это такое и насколько это удобно. Интересно, что даже PHP Обзавелся таким механизмом Установка нового расширения в РНР выполняется так:
pecl install package_name
pear install package_name


... << RSDN@Home 1.2.0 alpha 4 rev. 1091>>


dmitriid.comGitHubLinkedIn
Re[13]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 26.06.08 07:42
Оценка: 1 (1)
Здравствуйте, Mamut, Вы писали:

E>>Ну вот, а я уж начал думать, что никому кроме меня это не нужно


M>Многие просто не знают/не догадываются, что это такое и насколько это удобно.


Мне кажется, что здесь не все так просто. Дело в том, что как я смог понять, далеко не все программисты заняты разработкой кроссплатформенных проектов. Многим просто не нужно выходить за рамки VC++ или Linux/BSD. Поэтому те, кто сидят под VC++ хотят иметь в сторонних библиотеках sln-файлы и все. А unix-оиды хотят пользоваться своими родными системами управления пакетами (apt, rpm, portage, pkgsrc и пр.)

Я пробовал прозондировать на этот счет почву: http://www.rsdn.ru/forum/message/2716413.aspx
Автор: eao197
Дата: 02.11.07

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: boost - вон из профессии
От: jazzer Россия Skype: enerjazzer
Дата: 27.06.08 13:13
Оценка:
Здравствуйте, eao197, Вы писали:

Начал отвечать с конца, а уже вечер пятницы, так что отправляю то, что есть, на первую половину отвечу позже


E>Тем не менее, смотри что получается: сейчас люди создают работающие библиотеки, которые тестируются в составе Boost-а. У них нормальная реализация, которая постоянно шлифуется. Затем она попадает в стандарт. Какой-нибудь MS делает ее свою реализацию. В чем смысл создания других реализаций?


E>А если все используют одни и те же исходники, то в чем смысл стандартизации вообще?


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

E>>>— стандарт будет душить конкуренцию.


J>>Почему-то наличие в стандарте std::auto_ptr не задушило Boost.SmartPtr,

E>Я, например, про Boost.SmartPtr не знал. Или под этим shared_ptr скрывается?

И shared_ptr, и unique_ptr, и intrusive_ptr — это коллекция умных указателей. И наверняка она продолжит развиваться, добавится какой-нть linked_ptr...

J>> std::map — Boost.MultiIndex, std::list — Boost.Intrusive, std::string — Boost.StringAlgo

E>Имхо, это вообще не конкуренты. Конкурент std::map-а -- это, например, ACE_Map_Manager.

Ну почему же не конкуренты. Мульти-индекс вполне можно сделать на нескольких мапах, геморно, правда, но можно.
А мульти-индекс с одним уникальным упорядоченным индексом — это std::map и есть (только лучше)

J>>А еще ближе пример — Клюев и Егор, которых существующий уже 10 лет STL не душит никак — они сидят себе на своих библиотеках (конкурирующих с STL) и дальше будут сидеть.


E>STL вообще достаточно специфичен -- та его часть, которая касается контейнеров, вообще не имеет себе равных, имхо. Это именно то, что нужно было для C++. Но, с другой стороны, std::string и iostream далеко не самые удачные примеры. И более удобный класс строк, например, не помешал бы. Да только где он?


Так может, он и не нужен?
Та эволюция, которую я наблюдаю, сводится к тому, чтобы предоставить 1) разнообразные контейнеры для разных вариантов использования, и 2) разнообразные алгоритмы для работы с этими контейнерами. Т.е. контейнер, параметризованный char/wchar_t, и представляет собой строку, а алгоритмы, соответственно, будут осуществлять необходимые операции, типа поиска по регэкспам, выделение подстрок и т.п.
А один класс, который бы включал в себя все на свете, не особо и нужен получается.

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

J>>Так что не надо сгущать краски и наделять стандарт сверхъестественными полицейскими способностями.


E>Я всего лишь выражаю свои опасения, что для ряда предметных областей наличие стандарта не даст ничего хорошего. К БД это в частности и относится.

E>Ну не будет у C++ таких средств, чтобы сделать конкурента JDBC, не говоря уж о LINQ. А делать для стандарта что-нибудь лишь бы для стандарта так же не очень правильно.

Почему же не даст? Вот есть стандарт SQL, который поддерживают все существующие СУБД. Что может быть плохого в том, чтобы иметь библиотеку, которая подерживает этот стандарт? Чтобы ты мог писать код, который не зависит от того, к какой СУБД ты подключился, пока тебе не понадобится специфика конкретной СУБД?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.06.08 13:25
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>Почему же не даст? Вот есть стандарт SQL, который поддерживают все существующие СУБД. Что может быть плохого в том, чтобы иметь библиотеку, которая подерживает этот стандарт? Чтобы ты мог писать код, который не зависит от того, к какой СУБД ты подключился, пока тебе не понадобится специфика конкретной СУБД?


Мне редко приходится работать с SQL, но когда приходится, то выясняется, что такой вещи, как "стандартный SQL" нет. Для эффективной работы с конкретной СУБД требуется использовать конкретные диалекты конкретной СУБД. Например, сейчас мне приходится поддерживать код для MSSQL и Oracle, так там разные SQL-и для всего: и для схемы данных (определение полей автоинкремента и индексов), и для select-ов, и для delete.

Возвращаясь к OTL -- как раз ее достоинство в том, что она не прячет деталей работы с конкретными СУБД.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: boost - вон из профессии
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.06.08 14:58
Оценка:
Здравствуйте, jazzer, Вы писали:

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

J>Суть в том, что, взяв любую реализацию STL (если в ней нет багов, естественно), ты получишь все гарантии, которые есть в стандарте, и твоя программа, написанная по правилам стандарта, будет работать без проблем. Но если ты берешь конкретную реализацию, ты в дополнение к требованиям стандарта получаешь еще и обещания этой конкретной реализации (типа многопоточности, или распараллеливания, или строки со счетчиками ссылок).

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

Если же нужно что-то не стандартное, то приложение завязывается на конкретную реализацию STL (будь то STLPort или Apache) и все -- стандарт нафиг.

При этом STLPort будет крутить STL в свою сторону, а Apache в свою.

Я еще могу понять, что когда STL появился и писался стандарт, еще не было такой широкой практики OpenSource проектов. Поэтому возникло несколько реализаций STL от разных производителей. Но сейчас то в чем смысл стандартизации части Boost-а?

Ну вот есть, скажем, Boost.Regex. Какой смысл делать несколько его реализаций под эгидой стандарта? Не лучше ли развивать Boost.Regex дальше. Что бы не было одного де-юре стандарта и нескольких де-факто реализаций со своими тараканами. Была бы одна реализация, которая и явилась бы де-юре и де-факто стандартом Boost.Regex.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: boost - вон из профессии
От: Kluev  
Дата: 28.06.08 09:31
Оценка: -2
Здравствуйте, jazzer, Вы писали:

E>>STL вообще достаточно специфичен -- та его часть, которая касается контейнеров, вообще не имеет себе равных, имхо. Это именно то, что нужно было для C++. Но, с другой стороны, std::string и iostream далеко не самые удачные примеры. И более удобный класс строк, например, не помешал бы. Да только где он?


J>Так может, он и не нужен?

J>Та эволюция, которую я наблюдаю, сводится к тому, чтобы предоставить 1) разнообразные контейнеры для разных вариантов использования, и 2) разнообразные алгоритмы для работы с этими контейнерами. Т.е. контейнер, параметризованный char/wchar_t, и представляет собой строку, а алгоритмы, соответственно, будут осуществлять необходимые операции, типа поиска по регэкспам, выделение подстрок и т.п.
J>А один класс, который бы включал в себя все на свете, не особо и нужен получается.

Классы которые включают в себя всё не нужны. Нужны просто нормальные классы.
Те что мы имеем в стандартной библиотеке нормальными назвать никак нельзя.
Например iostream. Ежу понятно, что если есть ввод и вывод, то класс должен уметь работать в симметричном режиме:
string a = "one two three";
double b = 3.14;
int c = 1;

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

Глянув в исходники обнаруживаем, что такой возможности нет в принципе. Спрашивается какие вообще алгоритмы можно построить вокруг этого "класса"? Имхо, такие вещи нужно просто выкидывать из стандартной библиотеки и менять на нормальные вменяемые классы.
Да и вообще, стандартная библиотека С++ неудачный проект с самого рождения, не вызывающий ни одной положительной эмоции.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.