Marius, Thank you for your input. It's much appreciated. Please find my replies below. Marius Dobrea wrote

...Have you considered using iterators (or ranges) to specify input? Would that be in the scope of your library?

Well, string-to-type converters already accept and work with ranges. std::string is a range and can be provided as input. More so, "char const*" and "char []" internally converted to a boost::cnv::range and then processed by the same code handling std::string. In fact, I am pretty sure converters support any character-based range, i.e. something that has begin/end and value_type=char/wchar_t.

Also I note that the strtol() function returns the position of the first invalid character (endptr below): long int strtol (const char* str, char** endptr, int base);

Well, the name of cnv::strtol converter is a historical misnomer as it does not use std::strtol().

Could convert() provide the position where the conversion stopped? This would allow single pass parsing of some input data.

The answer is 'yes' and 'no'. :-) IMO you are asking for certain parsing functionality and the current offering provides none of it... as I never looked at "convert" as a parser and I did not personally had such a need. That said, there is nothing stopping you to write your own stateful converter which would store as much parsing info as you need... like the info you asked for. If you think your requirements are sufficiently generic and if you could submit such a converter, we might review it on the list and potentially include it as part of the "convert" family of converters. Does it sound reasonable?

Would a Converter callable with the following signature be useful?

template class Result { public: enum Errc { numeric_overflow, empty_range, invalid_character, ...}; // std::expected like function signatures here private: TypeOut value; int errors; InputIterator pos; };

template void operator()(InputIterator begin, InputIterator end, Result<TypeOut, InputIterator>& result) const; ...

Here, as I said, ranges are already supported so no need to pass in iterators. As for "Result", then I'll have to look at your suggestion later in more detail without hurry... However, my initial reaction on suggesting an alternative/different "return" type is of a doubt. My *first* impression is that it's difficult/impossible to make generic as different people will probably want different content. Secondly, you won't believe how difficult it was to defend returning "optional". Spoiled (IMO) by boost::lexical_cast some expect only TypeOut and no more. My original proposal (some yeas ago) was returning some "return" type... it did not fly. That said, I feel that writing a custom converter (and storing relevant to your requirements information in that converter) might be the way to go in a situation as you describe. Does it make sense? -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Convert-Specify-input-using-iterato... Sent from the Boost - Dev mailing list archive at Nabble.com.