Re: [boost] [serialization][1.36]ktmapcontainsextended_type_infowith m_key == 0

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2008-03-31 02:28:49

On Sun, Mar 30, 2008 at 5:44 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Felipe Magno de Almeida wrote:
>
> > On Sun, Mar 30, 2008 at 1:59 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>
>
> > A translation file is a preprocessed .cpp file. A DLL can have lots of
>  > source files.
>  >
>  >>  Is the DLL loaded explicitly with "library load"
>  >
>  > Yes.
>  >>> LoadLibrary through boost.extension.
>
>  you should be able to see (with your debugger) the create of one
>  and only one entry in the kt table when the library is loaded.

Ok. I was able to make a reproducible case. Though not *exactly* what I see
in my project. It is attached.
I hadn't noticed before, but in my project I had two
BOOST_CLASS_EXPORT in the DLL project.
That did registered the same extended_type_info<> instance to the ktmap.
When one was to be destroyed, it sets m_key to zero.
In the example I'm sending, the executable breaks in a more mysterious way.
Is more than one BOOST_CLASS_EXPORT, in different translation files,
suppose to work?
Removing the extra one, or not including the archives and export.hpp
also worked in this project.
It did int-defaulted the return type to the BOOST_CLASS_EXPORT(x);
when it was not defined,
that's why I it slip through me.

> You
>  should see the deletion of this one entry when the the library is
>  unloaded. I would make a simple program that just loads
>  and unloads the DLL and verify this behavior.
>
>  This is a spanking new facility so its possible that
>  it has some bugs.  Also, I have to test this "by hand" so
>  its not tested as part of the test system.

Yeah, that's very hard to test with boost.test facilities.

>
>  Robert Ramey

Thanks,
-- 
Felipe Magno de Almeida