David Abrahams wrote:
Yeah, it looks like vc-7.0 is still eliminating some of the startup code. My biggest problem is that I don't understand what you're registering and where, and I can't understand the error messages I see. So for example, when I get an "unregistered class" exception, what does that mean? It isn't at all obvious what constitutes registration of a class.
Basically it means that it an attempt to retrieve an instance from the global table of extended_type_info entries was not successful. The main function of export.hpp is to be sure that all that there is an extended_type_info entry for each exported type. This could fail due to compiler bug, bug in export.hpp or the user might have failed to use BOOST_EXPORT for that type.
I was able to clean up a *lot* of messy code.
Would you like me to:
0. Check my code in on the trunk
Without having looked at anything, I'm assuming that export.hpp has been pretty much replaced and I would be fine with seeing it just checked into the trunk.
I wasn't aware that there was a *lot* of messy code (except perhaps workarounds for compiler quirks).
Yes, a great deal of the mess was workarounds (sometimes workarounds that were not effective), but lots was just functionality implemented in ways that were needlessly convoluted.
Maybe we have a different criteria for "messy". If this confined to a few modules, maybe the most practical would be to email them to me so I might have a look at them. If its a lot of modules, I would like to consider it some more. Note that the trunk is undergoing some flux as the adjustments to array serialization are being integrated - this might affect the course of action here.
The large changes are confined to a few modules. There are lots of smaller changes.
Just tell me what you want me to do.
might as well just check 'em in to the trunk Robert Ramey