Bruce Gray:
# Having said that, I see that nested "#ifndef __GNUC__", 
# #ifndef __BORLAND", "#ifndef __MARS__", etc will be 
# sub-optimal. The better choice is to only make the pragmas 
# visible to the specific compiler that understands them. Now 
# that I have done more checking, I think that compiler is 
# Microsoft's. If Brent Dax will verify that his original 
# intent was for those pragmas to apply only to Microsoft's C 
# compiler, then an improvement would be to change one line of 

I didn't introduce these.  Looking at the CVS logs, I find that most of
them were added in way back in parrot/platforms/win32.h (the old
location of the file) version 1.5:

        Revision 1.5, Mon Jan 14 20:04:32 2002 UTC (11 months, 1 week
ago) by dan
        Changes since 1.4: +3 -0 lines
        
        This patch cleans up most of the MSVC-warnings when using
warning level 4
        (the highest, one above the default level 3). It turns off two
level-4
        warnings for 'unreferenced formal parameter' and 'named type
definition in
        parentheses', the latter of which was turning up warnings in MS
VC headers.
        Level 4 warnings also helped me find a couple of other lurking
bugs in the
        parrot code.
        
        ...
        
        Courtesy of "Michel Lambert" <[EMAIL PROTECTED]>

So Mike is the guy to ask, not me.

However, those warning numbers are almost certainly VC++ specific, so
they should be confined to VC++.  That way if someone ports a new C
compiler to Windows, we won't have to run around adding new #ifndefs all
over the place.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
    --Ayn Rand, explaining how today's philosophies came to be

Reply via email to