Re: deprecated symbol warnings and Windows

[Ken Raeburn]

On May 14, 2005, at 08:40, Neil Jerram wrote:
> > The warnings can be disabled while building guile (only while 
> > building deprecated.c, I hope) so that -Werror doesn't kill the 
> > build.
> > In the header files, here's how it's taking shape, roughly:
> > #if defined(SCM_DISABLE_DEPRECATION_WARNINGS)
> > # define SCM_DECL_DEPRECATED /* empty */
> > #elif __GNUC__ >= 3
> > # define SCM_DECL_DEPRECATED __attribute__((deprecated))
> > #elif defined _WIN32
>
> Does the __declspec syntax work for all Windows compilers?  If it's 
> actually specific to MSVC (which is the only compiler I'm familiar 
> with), you should use _MSC_VER.  If it's for all Windows compilers, 
> I'm surprised by the underscore - i.e. I'd normally use WIN32; are 
> WIN32 and _WIN32 equivalent?

I've done a bit more investigating, and it appears that 
__declspec(deprecated) is new with Visual Studio 2003, or maybe 2002.  
So there would be no warning with older compilers, probably.  (And the 
older compiler we've been using at work defines _WIN32 but not WIN32.)  
For now, in my code, I'm testing _MSC_VER >= 1310.

In looking at the current headers, I think when I'm changing macros 
into functions, I need to stick "SCM_API" in front where I'd use 
"extern" normally, to get the Windows DLL import/export specs right?  
So this conversion will actually be adding to the exported-symbol list 
of the DLL.  (Has anyone thought about limiting exported symbols on 
UNIX?)  I've just gotten access to the newer compilers, so I should be 
able to run some tests any make sure I've gotten the syntax right for 
multiple declspecs etc.

Oh, and based on the discussions, I'm sticking with the "#define foo 
foo" form for now, rather than renaming symbols.

Ken