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

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

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

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

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

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

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

Я так не умею, я профайлером пользуюсь.

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 трудно назвать образцами юзабилити и читаемости.
Мы вроде о КАЧЕСТВЕ кода говорили, а не о юзабилити?

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

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

Здравствуйте, 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(), например?

Здравствуйте, 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 чего стоит.

Здравствуйте, 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, это тут офтоп. Если тебе не важна скорость твоей программы, то тебе пофиг на реализацирю таких вещей. Правда, скорее всего, тебе и С++ тогда действительно, в этой задаче, нафиг не упёрся...

Kluev пишет:

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

Скока можно повторять, что буст не библиотека, а куча библиотек. И если
у serialization автор — <beep>, то это не означает что shared_ptr нельзя
использовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

спасибо, исправил.

eao197 пишет:

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

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


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

Было бы неплохо, но боюсь бустоводы этого не потянут.

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

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

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

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

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

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

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

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

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;
}

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

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