RE: [sigc] Making libsigc++ friendlier for MSVC

["James Lin" <jameslin vmware com>]

Hi, Martin,

> >> > 4. The MSVC project currently does not include slot_base.cc and
> >> lambda.cc.
> >> 
> >> A patch would be welcome.
> 
> This still seems to be a TODO-item?! James?

I think I meant to say "slot_base.cc" and "signal_base.cc".  Regardless, all
of the .cc files should have been added in the patch already, I just forgot
to mention that change in my summary.


> >> > 5. As a template library, libsigc++ sometimes allocates memory in
> >> the
> >> > template headers and deallocates it in the library binary (or
> >> vice-versa).
> >> > This allows mismatched allocators/deallocators.  I'm not sure if
> >> this is a
> >> > problem on Linux, but it's something we readily can 
> encountered on
> >> > Windows.
> >> > (We built a libsigc++ DLL using Microsoft's release runtime
> >> libraries, but
> >> > we
> >> > unwittingly used that DLL with code we compiled with debug  
> >> runtimes,
> >> > resulting in memory access violations.)
> >> >
> >> > This is more of a nuisance than a problem--users of 
> libsigc++ can  
> >> be
> >> > careful
> >> > to build the library with the specific runtimes they 
> use.  Another
> >> way to
> >> > avoid this would be to provide an internal allocator and
> >> deallocator.
> >> > I've
> >> > made crude ones using a combination of malloc, free, and 
> placement
> >> new.
> >> > Would there be any objections to using macros like SIGC_NEW and
> >> > SIGC_DELETE
> >> > everywhere instead of the standard new and delete operators?  The
> >> syntax
> >> > for
> >> > the ones I've written is:
> >> >
> >> >   SIGC_NEW<type>(args)
> >> >   SIGC_DELETE(ptr, ~dtor)
> >> >
> >> >
> >> > I'd be happy to incorporate all of the above changes to the  
> >> current
> >> CVS
> >> > sources and submit patches, if desired.
> >> 
> >> Yes, I understand this problem. It's a well-known MSVC++ 
> problem -  
> >> you
> >> need to delete stuff in the same library that you new it. Hopefully
> >> this
> >> is only a problem in a few places, and I would prefer only 
> to change
> >> those
> >> places. I  don't like that macro syntax much - I would prefer
> >> something
> >> that looked like a function call.
> > 
> > I agree with Murray - please point out the places, where 
> you expect  
> > problems!
> 
> James, did you make any progress regarding this / are there further  
> investigations necessary?

I think I've narrowed down which allocations/deallocations should be handled
internally.  I'll submit a separate patch for review (hopefully) later this
week after I spend some more time thinking about it (especially about syntax)
and after doing some basic testing.

- James