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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]