Re: deprecated symbol warnings and Windows

[Ken Raeburn <raeburn@raeburn.org>]

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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user