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

[murrayc murrayc com]

> Hi,
>
> As you know, we've been experimenting with libsigc++ on Windows.  Here are
> some other issues we've run into:
>
> 1. Inability to run the configure script, which is necessary to generate
> sigc++config.h.  As I've mentioned in bug 147311, I think it might be
> reasonable to supply a pre-generated copy in the MSVC_Net2003 directory.

Maybe, but you should investigate what other libraries do, such as libxml
and GTK+.

> 2. The MSVC project currently generates a statically-linked library.  This
> is
> much less useful than a DLL due to the LGPL requirements.  It's simple to
> change the project settings to output a DLL, but...

Yes, this seems like a bug.

> 3. Functions need to be exported explicitly from the DLL.  This means
> adding
> __declspec(dllexport) to various class declarations.  I've done this by
> adding
>
>   #define SIGC_API __declspec(dllexport)
>
> to sigc++config.h. Obviously for non-MSVC users, it'd be an empty
> definition.
> Would anyone object to this? (These SIGC_API warts would appear once per
> class/struct declaration, not for each individual function.)

Yes, we should do this. We did this in the past, so maybe you should look
at libsigc++ 1.2.

> 4. The MSVC project currently does not include slot_base.cc and lambda.cc.

A patch would be welcome.

> 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.