Hi! On 03/12/2012 05:53 PM, Alessandro PROFETI wrote:
I wasn't very fast in downloading cln source code and applying the patch. Without the patch, the number in the last incomplete (no \n) line wasn't read by cin >> x. Now the behavior of operator>> is the same, the last number is read and printed in both cases; the next cin>>x results in an exception. This behavior is EXACTLY what I observe when x is a double, if I compile the file profeti.cc with the switch -DEXCEP.
Great. So that is fixed now. I've committed it.
Is there a way for asking cln to behave the same way as c++ when extracting a cl_R, so that the code sum = 0; while (cin >> x) sum = sum + x; would compute the sum of the data, with x double or x in cl_R? This way of coding is much simpler then for (;;) { try { cin >> x; } catch ( ... ) { break; } sum = sum + x; }
Good point. I agree that, ideally, CLN would behave the same as standard C++ when reading numbers from streams. Another issue is reading from an input stream that provides "123ABC". It seems like standard C++ reads 123 and stops there while CLN reads more and later discovers that ABC doesn't match the format.
I tried to peep in cln source code and in the code for libstdc++, but couldn't figure out if there is some place in cln code when one can take in account the value of cin.exceptions() and react to error throwing an exception when the corresponding bit is set or returning a null reference (the default for cin >> x when x is double) when the bit is clear.
I think rather than resetting exceptions after the fact, the functions implemented in cl_*_read_stream.cc should be written to be more specific to the number format. They could then read only what is required. I'll see if I can provide a patch. Bye! -richy. PS: I'm taking this thread to the mailing list. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>