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

[Martin Schulze <martin-ml hippogriff de>]

Am 26.07.2004 09:46:32 schrieb(en) 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+.

gtk+ has a config header (gdkconfig.h) and provides a platform specific  
variant (gdkconfig.h.win32). However, they have no dependencies on the  
compiler platform, only the window manager (-> win32) is important.
In libsigc++-1.2 we used to predefine the macros in our config header  
for those platforms that cannot run configure (surrounded by #ifdefs).

However, I think I'd prefer to supply a pre-generated copy in the  
MSVC_Net2003 directory so that the platform specific things are kept  
where they belong ...
Probably, also the project file would have to be modified for this?!  
James, could you provide a patch, please?

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

I guess, this bug also lies in the project file?!
-> A patch would happily be applied!

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

I agree with Murray - please point out the places, where you expect  
problems!

Regards,

 Martin