Re: [Boost-users] [Serialization] assert in void_caster

Subject: Re: [Boost-users] [Serialization] assert in void_caster
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-06-29 13:13:39

> 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