Re: [Boost-users] [serialization] Bug in text_oarchive but not inxml_oarchive?

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-04 13:00:17

Bill Lear wrote:

> So, it appears that these larger data sets are just pressing the stack
> quite hard, so boost is apparently not the culprit.  I seem to
> remember, though, seeing tons frames of boost library calls for a
> single serialization output --- seemingly lots of "dispatch" type
> template redirections.  Is there any way to optimize some of this out?
> I suppose not, but just wanted to ask.

Except for calls into the precompiled library, all of these calls can
in theory be optimized away by an optimizing compiler.  Current
compilers generally can't do ALL of them but you'll find that there
is an absolutly HUGE improvement in performance and reduction
in code size when using the optimization switches of one's compiler.
The difference between optimization and debug builds when using
MPL type templated code is large - an the serialization library
is an extreme example of this.

> In the course of this little adventure, I did come across something
> else that I'll try to put into a more thoughtful email later:
> exceptions in the serialization library are sometimes maddeningly
> unhelpful (C++ exceptions in general drive me nuts sometimes).  One
> time, I successfully wrote the entire structure out to disk, and
> after the routine had returned, boost threw a "stream error" --- I
> finally
> tried setting ios::binary on the stream and this seemed to fix it.
>
> But the "stream error" had no context, obviously the code just looks
> for the fail bit being set (also the bad bit, I think), and just
> throws an exception.  But, there is no context to this, no stack
> trace (C++ exception), etc.

> I did notice that in gdb you can put a debugger "catch" on a C++
> throw --- next time I get a stream error, I will try this trick.

The debugger has to be set to trap when an exception is thrown.
All the debuggers I've used permit this as an option.  The source
code where the exception is thrown describes all the information
that is known that might be helpful.  But if the library get's to the
point where it has to throw an exception - its exhausted its facilities
for knowning what to do.  I don't see any way to change this.

> Anyway, thank you again for all of your help.  I am tired, but happy
> that the boost library doesn't have some sort of weird bug and that
> this was all just a case of me racing down the non-obvious path,
> instead of choosing the one (seemingly, always) less-traveled by.

Well, maybe next time you migtht consider titling your message
something other than "Bug in text_oarchive but not inxml_oarchive?"
like perhaps - "[serialization]I can't figure out when I'm doing wrong - 
please Help"
Its really irksome to an author of a library like this which includes
50 tests x 5 archives x 10? compilers (2500 testing scenarios) to
defend the proposition that the library is correct because some
huge an un-understandable program (10 MB of stack space
and thousands of stack frames - good grief!) throws and exception
and the author hasn't even found where the exception is thrown.
Just a heads up - I'm a sensitive guy.

Robert Ramey