на всякий случай запустил твой тест на 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


Довольно странные результаты.

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

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

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

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

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

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

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

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

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

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

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

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

но не для разных же версий библиотек (я не имею в виду multi- и single-threading, я имею в виду одну и ту же библиотеку, но из разных версий буста)?

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

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

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

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

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

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

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

Здравствуйте, 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. (Или, может быть, остановка на символе-разделителе, или ещё что-нибудь такое...)

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 — ацтой?
Буст, кстати, не библиотека.

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня складывается впечатление, что слово "фелдизайн" в твоих устах эквивалентно "мне не нравится, и все тут".
Давай ты это слово заменишь на что-нибудь более осмысленное, типа там "хранение по значению" или что-нибудь в этом роде?

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

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

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

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

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

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

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