Reece Dunn wrote:
2) The output operator puts spaces after '[', before ']', and after each ','; whereas the input operator expects no spaces at all; if spaces were present, a bad_lexical_cast exception was thrown. I think it is really important that operator>> can deal with an output which was generated by <<; stated in terms of lexical_cast,
lexical_cast<T>( lexical_cast<string>( t ) ) == t
should hold for any T t.
I stripped and skipped the spaces during the read operation to allow for the read operation to accommodate input variations, e.g. [ a, b ]; [a, b] and [ a,b ] would be read by the same formatter, making it easier to interoperate with data generated from other sources. I could make this a configurable option that does not strip the spaces by default.
It's really good question if the >> operator should be prepared to find a stream which has 'skipws' bit unset. Given that streams usually generate human-readable data, skipping whitespace is a common behaviour, and I'd say that 'noskipws' manipulator should be used only for special circumstances. So, in my opinion lexical_cast<T> should not use 'noskipws', and not force other libraries to manually skip whitespace. - Volodya