[boost] Re: [serialization] The problems with CW...

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-29 17:13:58

Thanks for looking into this.  This more or less ratifies my suspicions as
to the origin of ths problem.

"Rene Rivera" <grafik.list_at_[hidden]> wrote in message
news:4182A275.1010105_at_redshift-software.com...
> I took some time to take a closer look at what the current test failures
> could be about on the cw-8.3 compiler... before I go on vacation.
> Specifically I looked at the test_exported errors as those seemed to be
> common to both the 9 and 8 versions of CW. My findings...
>
> I managed to get the export tests to *pass* by modifying the test itself
> (see attached). The problems boils down to the behavior of CW to only
> instantiate templates when they are used. This not just applies to class
> templates, but to template methods.

Agreed

> a) The serialize template method of non-directly referenced derived
> classes. Specifically for test_exported:
>      polymorphic_derived1::serialize<test_oarchive>,
>      polymorphic_derived1::serialize<test_iarchive>,
>      polymorphic_derived2::serialize<test_oarchive>,
>      and polymorphic_derived2::serialize<test_iarchive>.
>
> Forcing those to be instantiated generates all the rest of the self
> registration code for the derived classes. This still leaves:
>
> b) The archive serialization instance for the needed specializations is
> also not generated as they are not directly reference. Only the ones for
> the base class, polymorphic_base, are generated as that's the class used
> in the actual de/serialize calls.
>
> I'm not sure anything can be done about fixing this for the release

Agreed.

>as the only solutions I can come up with would involve changing the
> serialization interfaces.

The original verision ofthe library didn't have ths problem.  It required
"pre-registration" of types to be serialized via polymorphic pointers.
Strenous objection was raised in some quarters due to the believe that this
placed an unreasonable burden on library users and would require that
"upperlevels" know about all the components.  It was also pointed out that
this would make the concept of certain types of "plug-ins' untenable.

So it would be easy to say - If you're using CW, just make sure you
"register" all you're derived pointers.  Unfortunately, even that doesn't
work for CW because instantiating the class doesn't instantiate all the
member functions.

I don't think that CW is incorrect in this.  Its just that this behavior is
not desired in some cases.  Another case where this is a problem is the
implementation of a DLL.  We implement functions but they are not explicitly
called.  we use "_export" keywords to indicate that these functions should
be instantiated and not optimised away even though the functions are not
explicitly called by name.  This method resolved the issue for all other
platforms.  It doesn't conform to any standard that I know of.  I don't
there is a standard conforming way of specifying this behavior.
Unfortunately, CW doesn't seem to respond in this way to the "export"
keyword - even though it accepts it.  It leaves me wondering how one makes a
DLL in CW without losing all the functions in the compiled object.  I
searched high and low for a compiler switch and/or pragma that would fix
this - but was unsuccessful.

This means that for now on CW,  derived pointers cannot be serialized
through their base class.  Other aspects of the serialization library still
work as advertised.

I would guess that we an conjure up some registrtation macros that force
instantiation on CW compilers.  These would expand to no acton for other
compilers.  Maybe that would be the best we can do.

Robert Ramey