From: Robert Ramey [mailto:robertmacleranramey@gmail.com]
Sent: Friday, May 30, 2014 3:43 PM
To: boostusers@googlegroups.com
Cc: robertmacleranramey@gmail.com; boost-users@lists.boost.org; boost-users@lists.boost.org; Hickman, Steve (AdvTech)
Subject: Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called

On Friday, May 30, 2014 2:37:00 PM UTC-7, Hickman, Steve (AdvTech) wrote:

I corrected the problem with the DLL import. That had no discernible effect.

lol - you didn't tell me there was a problem with DLL import. 

The issue here was link warnings due to the fact that I was importing back into the DLL exported interfaces.  I fixed this by changing how my DLL import macros in my header files expand for the library being built. When used in the library, they expand to nothing, otherwise they expand to “__declspec(dllimport)”. The actual function definitions in the .cpp files always expand to “__declspec(dllexport)” when the library is built as  a DLL.

It does not throw an unregistered_cast() exception (which it seems like it should).

Consider filing a trac item for this.

Done

this strongly suggests a problem with EXPORT ing the derived class.  Note that that each DLL contains it's own casting table. Of hand I don't remember which EXPORT s get added to which table.  Certainly the EXPORT IMPLEMENT should be the *cpp file which is part of the DLL.  

It is

One way to test this would be to verify that the static library build/test works.  This always has only one table so such problem wouldn't come up.

Building/linking my library statically does solve the problem. And it works for the application I need to use it for, so I’m going with that approach for now. .

But it still leaves open the question of why we're getting to this point.  There are two approaches to a problem like this:

a) Just "make it work" by adding stuff until it seems to work. This is the approach favored by management. 

Given my current time constraints, using a static library works and will be my approach until I see it break.

b) Get to the bottom of it and fix it once it once an for all - and add notes/comments and/or tests to make sure the bugger stays dead.  This is the approach favored by (unemployed) programmers.

And since I’m trying to avoid unemployment, I’ll have to delay this for now.

The former seems to work - but the problem keeps sucking up time in the future.  The latter is tedious and frustrating - but this keeps one from getting stuck in a dead end job constantly fixing the same problems.

Robert Ramey

---

Steve H.