Did you open the output stream with the flag ios::binary?
Probably not, now that you mention it. I'll have to check next week when I get back to the office.
I've run into a situation where I'm triggering an assertion at
basic_binary_oprimitive::save_binary(). This is on
basic_binary_oprimitive.hpp, line 115 in version 1.32. This assertion seems to
be claiming that an output stream will always be in a "good" state after a
call to write(). On it's face, I think there's no way to safely make that
claim, especially about a stream whose type is a template parameter. In fact,
as I understand it, good()'s whole purpose is to let you know that the stream
is busted.
I think its the opposite.
IIRC,
Stroustrup's explanation of good() is something equivalent to "if
os.good() is false, the next operation to the stream is certain to
fail; if it's true, then the next operation might work". It's the
equivalent of checking all of the individual error flags.
Am I misunderstanding something, or should that assert be
changed to an exception?
Wit this problem you'll get an exception later in
any case but its more obvious to trap it here
when you're debugging.
I'm
not entirely clear why I should necessarily expect an exception after a
stream goes bad. From what I understand, the stream itself will not
throw; rather, it will silently ignore i/o calls. It looks like the
serialization code itself is likely to throw after the stream goes bad,
but it also looks like there might be some edge cases where it won't.
My expectation was that I would get an exception in the case
of a bad stream. Assertions seem mostly useful as checks for
invariates, not potentially recoverable/ignorable runtime errors. In
this case, perhaps my stream is unwritable because of file permissions.
An exception in this case is far preferrable to an assertion because,
in many cases, a program can keep going just fine without writing some
particular file.
Perhaps most importantly, an assertion in this situation actually seems
to make my debugging time less fruitful. That is, I'm guaranteed to
never exercise some of my exception handling code in debug mode because
the assertion will always be tripped. As you say, the assertion is
certainly obvious, but I think it's also counterproductive in this case.
Austin Bingham