Daryle Walker wrote:
* when booleans are output, booleans are converted to integers and an assertion is thrown if the resulting value is other than zero or one.
The compiler can only give 0 or 1, it cannot canonically give you another result.
Hmmm - well its doing so in this case - canonically or not?
As I said in another post, trying this on an uninitialized "bool" has already given you undefined behavior, so you don't know if you'll reach your assertion code, let alone trigger it. (Also the 0 or 1 from the conversion doesn't tell you anything from the internal representation.)
Hmmm - suppose I implement the following code: bool tf; int i = tf; assert(0 == i || 1 == i); and the assertion is invoked. Is it not correct to conclude that there is a problem with the code and that it should be somehow altered? Of course a smart compiler will catch this sooner. In other cases a smart runtime system/machine might throw a data exception the instance that i=tf is executed. Great - We've trapped a bug in user code. But suppose that doesn't happen and the exception is invoked. Well, great again - for the same reason. Suppose that the assertion isn't invoked (may the compler "helps us out" by initializing tf. So we're stuck with a bug - same as before. So the assert might not be necessary, it might detect a bug not otherwise detected. The fact it might not on some platforms doesn't mean that it shouldn't be included.
Some kinds of programming errors aren't worth trying to detect. Passing uninitialized data is fundamental brokenness, and looking for it with only in bools is rather silly.
I agree, especially since I think that such detection isn't possible.
same old question - what's the downside with detecting fundamental brokeness - sounds like a good feature to me !!!
Another post in this thread mentioned another thread from a year ago. That thread said that some environments do provide I/O that can save and load NaN (and infinite) values to/from text. Mr. Ramey was concerned with the environments that couldn't. At this point, I'll propose not worrying about such environments, even if they're popular. You can't give tremendous effort to support all the brokenness out there (and I hope that we don't expect you to). Sometimes you have to tell the user that they're out of luck with that particular configuration.
lol - well, you've got my vote. it turns out that this is an artifact of certain (all?) text streams. So it doesn't appear in the binary archives. Perhaps this is why it hasn't come up more often.
And, AFAIK, not even text archives are 100% portable between environments, are they?
they are - or least they are meant to be. Any instance where they are not should be reported as a bug. Having said that, there are going to be some cases where they ar not going to be portable. Suppose the following: a) one serializes a variable of type size_t to a text archive. b) value exceeds 32 significant bits. c) the archive is shipped to another machine which has size_t only 32 bits long. As he archive is read by recieving machine. An error should be detected and an exception thrown when the value is read. So although text archives are portable, one can still only reconstruct C++ data which is in fact representable on the target machine. I don't know if that decreases you 100% number - but its the best we can hope for.
When I said that sometimes you have to give up, I only mean in terms of environments too broken to give you the help you need. You shouldn't (permanently) drop features just to make your "life easier" if they're the right thing to do.
The question is how much effort should be directed working aournd a library bug (if that's what it is) to a case which is so un-important or trivial to address that even those people directly effected by it are dis-inclined to invest any effort in it. Its not that hard to fix if someone really needs it. So if it bothers you and you need to fix it, test it, and send me your changes.
Anyway, do we provide a way for a (user-created) serialization routine to bail if the archive gives bad values (like it's corrupt or from another platform)?
Archive class implementation throw documented exceptions in cases where corrupted data is detected. Serialization functions are totally in hands of the user which implements them and can also throw any of these exceptions - or its own if it prefers. Robert Ramey