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

O>parse_cast.

Sorry, подробнее сейчас некогда, может, завтра время еще будет...

Имхо, основная проблема с подобным дизайном заключается в том, что интерфейс как бы рассчитан на проход по последовательности (аргумент — итератор), однако функция не возвращает позицию (итератор) символа, следующего после извлеченного значения. Если начать это делать, то, имхо, в конечном итоге, интерфейс превратится в std::istream :-)

Кроме того, принимать один итератор очень необычно: в частности, это означает, что в контейнере придется хранить лишний терминальный элемент, что не совсем естественно для контейнеров, размер которых известен. Да и вообще, понятие zero-terminated последовательности получается достаточно странноватым :-)

Я бы просто разделил два интерфейса: один принимает пару итераторов, а второй — указатель const char*. Для последнего наличие `\0' в конце вполне естественно.

O>Просьба помочь избавиться от: ret_val_adaptor и it_adaptor ( IT — regards ;) )

Проблема с it_adaptor, на мой взгляд, обусловлена выбором интерфейса. parse_cast как бы ожидает итератор, а ты ему подсовываешь std::string... Включать здесь ad hoc неявное преобразование, на мой взгляд, идеологически некорректно.

Если разделить два интерфейса, как описано выше, то, имхо, parse_cast<>(str.c_str()) уже не выглядит таким страшным. Да и при желании можно просто перегрузить parse_cast для std::basic_string безо всяких it_adaptors.

O>

O>    <...>
O>    std::string test2 = "-12";
O>    std::vector<char> vc(test2.begin(), test2.end());
O>    ival = parse_cast<int>(vc.begin());
O>    <...>

В частности, те же проблемы из-за одного итератора на входе: вектор не содержит последнего `\0' из строки. То что parse_cast<int>(vc.begin()) работает — в данном случае, просто совпадение. Точно так же мог бы быть и seg fault.