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