As far as I understand the assert fires because the base derived relationship is registered multiple times. But is this really a problem? We placed the void_cast_register call in a macro that exists in the implementation of every class anyway to be sure the base derived relationship was registered. Now we have to solve this differently because otherwise classes that have a serialize function (most don't) will trigger the assert at startup. Is it save to uncomment the assert? Are there real world scenarios when this assert is helpful?
This assert fires when code with the same signature is found in multiple code modules. Could it be a problem? It could. Is this a problem? I can't say - it would depend.... It's been my philosophy in implementing the library to trap everything that could be a problem. That is, the intention is that the library never silently fail. The cost of finding the source of even one silent failure dwarfs the relatively cost of being forced to explicitly consider a potential problem. In this scenario - code with the same signature exists in different DLLS. But there's no way to guarentee that it is in fact the same code!!!. If one mixed different versions of the DLLs, one could easiliy have an error which is likely impossible to find. Then I get an report on the list which has in the title "serialization library doesn't work". Then I'm stuck in the position of proving that the library works. But to do this I have to help a user track through his code. And of course this is likely a huge project as it's spread accross several DLLS which call each other. You can imagine how much I enjoy that. So I trap the problem. There a couple of places where I do this. I thought I commented it out because a user had a problem. Now I don't remember whether I did this, or whether I just told him to comment it out. If this were to happen to me, I would conclude that my code is not organized optimally. I would re-organize the code so that the asserts can never be called. This would guarentee that the one definition rule is respected and that DLLS will always be consistent. This in turn will mean that I have truely plugable modules. It would also mean that my package of shipping executables will be as small as possible - not code bloat. However, this is not always practical. If serializaition is added to a project which is already done - the code re-organization required to implement the above may just be two much effort. In any event, my future strategy will be: a) leave in the asserts b) provide some sort of setting "no-odr-enforcement" to suppress the enforcement of this rule. The hope is that when one steps into undefined territory, you'll get the assert. He'll complain and then have to explicitly override it and I'll be off the hook. I haven't done this yet as I've been busy - but that's my plan. Robert Ramey