Одной из причин этого может быть то, что реализация lexical_cast
может намеренно попытаться вызвать сбой какого-либо потока, чтобы проверить, что весь входной текст был использован. Например, наивная реализация может выглядеть так:
template <typename Target>
Target lexical_cast(const string& s) {
/* Insert the string into a stringstream to use extraction. */
std::stringstream converter(s);
/* Pull out an object of type Target, failing if we can't. */
Target result;
if (!(converter >> result)) throw bad_lexical_cast();
/* To confirm that we read everything out of the stream, try pulling out a
* single character. If we can do this, then there is something left in the
* stream that wasn't picked up earlier and the input was malformed.
*/
char ch;
if (converter >> ch) throw bad_lexical_cast();
return result;
}
Идея состоит в том, что последняя проверка пытается разорвать поток, чтобы увидеть, осталось ли что-то еще. Если вы включите исключения, это превратит что-то, что должно было быть нормальной ошибкой потока, обнаруживаемой с помощью failbit
, в исключение, чего код не ожидал.
В более общем смысле вы не должны устанавливать параметры потока внутри процедуры извлечения. Это зависит от звонящего. В противном случае, независимо от того, что вы пытаетесь сделать со своим потоком перед вызовом процедуры извлечения, подпрограмма переопределит ваши предпочтения. В конце концов, было бы плохо, если бы я явно отключил исключения, а затем все равно возникали исключения, потому что вы включили их обратно в operator >>
.
Надеюсь, это поможет!