Re: [sigc] Making libsigc++ friendlier for MSVC
- From: murrayc murrayc com
- To: "James Lin" <jameslin vmware com>
- Cc: libsigc-list gnome org
- Subject: Re: [sigc] Making libsigc++ friendlier for MSVC
- Date: Mon, 26 Jul 2004 00:46:32 -0700 (PDT)
> 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
> 2. The MSVC project currently generates a statically-linked library. This
> 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
> __declspec(dllexport) to various class declarations. I've done this by
> #define SIGC_API __declspec(dllexport)
> to sigc++config.h. Obviously for non-MSVC users, it'd be an empty
> 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
> (We built a libsigc++ DLL using Microsoft's release runtime libraries, but
> 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
> to build the library with the specific runtimes they use. Another way to
> avoid this would be to provide an internal allocator and deallocator.
> 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
> the ones I've written is:
> 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.
] [Thread Prev