Re: [sigc] test tarball: libsigc++ 2.0.6 (test1)

["Timothy M. Shead" <tshead k-3d com>]

Martin Schulze wrote:

> > Do I understand correctly that allocating an object via new from
> > within
> > a DLL, then destroying it via delete within a different module (EXE  or
> >
> > DLL) is the problem?
>
>
> This is what I have been told. James Lin (jameslin vmware com) brought  
> up the problem.
>
> > One item looks suspicious to me, I see that in sigc++/functors/ slot.h,
> >
> > the template struct typed_slot_rep<> has a static member function
> > "dup()" that is making a call to new, could this be a problem, since
> > it's inline code?
>
>
> Hm, note that 'typed_slot_rep<>::dup()' is only called from  
> 'slot_rep::dup()' (inline) via an indirect function call.  
> 'slot_rep::dup()' is in turn only invoked from non-inline code in  
> slot_base.cc.
> On second thought, this probably means that the code containing the  
> 'new' is in the EXE module (where the template instantiations lie) but  
> invoked from the DLL module!?
> The corresponding 'delete' is in the DLL module  (slot_base::~slot_base).
>
> Does this cause the problems? Then the solution would be to move the  
> 'delete' in the EXE module. Please apply the attached patch (against  
> the test tarball or cvs) and try again.

Applied the patch, it doesn't seem to change the symptoms.

For everyone's reference, here is a discussion of this issue:

http://support.microsoft.com/default.aspx?scid=kb;en-us;122675

They offer four workarounds, it looks to me like their second suggestion 
could be relatively elegant compared to SIGC_NEW_DELETE_IN_LIBRARY_ONLY 
- override operator new and operator delete for the problem classes, and 
call functions in the DLL to allocate/deallocate memory in their 
implementations.  I will poke at this and see what I come up with.

As an aside, I have verified that all tests pass if sigc++ is built as a 
static library.  If a DLL continues to be problematic, would you 
consider adopting a static build so gtkmm-2.4 on MSVC can go forward?

Cheers,
Tim