Здравствуйте Павел Кузнецов, Вы писали:

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

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

Да-да, я об этом подумал и не раз. Просто пока не придумал как это сделать правильно без лишней сложности. Действительно, не хотелось бы в istream упасть

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

Подумаю...

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

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

Да, наверное, буду думать.

ПК><...> Точно так же мог бы быть и seg fault.
Это понятно, я думал о границах, но пока безрезультатно. Там еще вопросы будут с потоками, хотелось бы для потоков тоже сделать вариант. Буду ждать завтрашней реакции и думать