boost - вон из профессии - Компьютерные священные войны

Здравствуйте, 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);

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

Если вы считаете что качество вашего кода вот тут вот высокое —
http://www.rsdn.ru/forum/message/2986004.1.aspx
Вы очень ошибаетесь. Так вообще давно не пишут.

Здравствуйте, 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 есть на тему преобразований строка — число?

Здравствуйте, 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 там все еще на стадии одобрения и для меня он уже опоздал года на три.

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

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

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

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

А>Если вы считаете что качество вашего кода вот тут вот высокое -
А>http://www.rsdn.ru/forum/message/2986004.1.aspx
А>Вы очень ошибаетесь. Так вообще давно не пишут.

этот код работает быстрее crt и при этом он лишен ее недостатков.
именно для этого он был и написан, а не для того чтобы заслужить одобрение анонимусов в форуме.
если вам нравится эстетически красивый код и плевать на производительность советую присмотрется к другим языкам
типа C#, java, pyton и т.п. и больше не мучатся с уродливым С++.

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

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

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

Здравствуйте, 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(), то вообще никаких перевыделений не будет.

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

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

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

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

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

K>этот код работает быстрее crt и при этом он лишен ее недостатков.
K>именно для этого он был и написан, а не для того чтобы заслужить одобрение анонимусов в форуме.
"Быстрее" это далеко не единственная обязанность кода. Код прежде всего должен быть ЧИТАЕМ человеком. Выгода от бОльшего количества продаж продукта, использующего ваш более быстрый вариант, будет съедена зарплатой 10 поколений индусов, поддерживающих и развивающих потом этот код. Подумайте над этим.

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

K>>этот код работает быстрее crt и при этом он лишен ее недостатков.
K>>именно для этого он был и написан, а не для того чтобы заслужить одобрение анонимусов в форуме.
А>"Быстрее" это далеко не единственная обязанность кода. Код прежде всего должен быть ЧИТАЕМ человеком. Выгода от бОльшего количества продаж продукта, использующего ваш более быстрый вариант, будет съедена зарплатой 10 поколений индусов, поддерживающих и развивающих потом этот код. Подумайте над этим.
Оформление кода как раз не проблема. Переформатировал, переменные/функции переназвал и все.
А вот если алгоритм изначально плохой то тут надо выбрасывать и писать по новой.
Тем более что у автора написано вроде как на plain C

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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>>

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

CC>А вот если алгоритм изначально плохой то тут надо выбрасывать и писать по новой.
CC>Тем более что у автора написано вроде как на plain C
Ну дык на plain C ннче пишут тока драйвера, софт под контроллеры и опенсурс, который гордится своей компилируемостью под всем. Какой вообще смысл в сравнению буста с Сшным кодом?

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

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

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

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

Здравствуйте, 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

здесь функция разбора действительных чисел на чистом C++

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

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

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

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

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

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

Здравствуйте, 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;
};

Здравствуйте, 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 не сожрет).

От:	remark	http://www.1024cores.net/
Дата:	13.06.08 17:24
Оценка:

	От:	Аноним
	Дата:	13.06.08 17:47
	Оценка:

	От:	Roman Odaisky
	Дата:	13.06.08 17:59
	Оценка:

	От:	Kluev
	Дата:	13.06.08 19:41
	Оценка:	+1 -1

От:	remark	http://www.1024cores.net/
Дата:	13.06.08 19:50
Оценка:

	От:	CreatorCray
	Дата:	14.06.08 07:08
	Оценка:

	От:	CreatorCray
	Дата:	14.06.08 07:08
	Оценка:	+1

	От:	Programador
	Дата:	14.06.08 16:42
	Оценка: