Multiple #defines in WinError.h

I am binding into the Win32 API from another language. I can't link
with the header files, but must make my own definition modules. I'm
using the MSVS.NET\Vc7\PlatformSDK\Include\WinError.h file to obtain
some values for
HRESULT definitions. I see two separate definitions for E_INVALIDARG

line 17213:
#define E_INVALIDARG
_HRESULT_TYPEDEF_(0x80070057L)

and line 17295:
#define E_INVALIDARG
_HRESULT_TYPEDEF_(0x80000003L)

So far as I can see, these both are within bounds of the same #ifdef
section (recheck: yes, they are). My modules use a named constant for
this definition, and it is substituted at compile time. The languages
with which I'm familiar allow only one value for a named constant, so
I'm confused as to which value is operational here.

As I understand the preprocessor it should make the substitutions
sequentially. The token E_INVALIDARG gets replaced in the code by the
first value _HRESULT_TYPEDEF_(0x80070057L). Then the second #define
comes up and any occurance of E_INVALIDARG would get replaced by the
second value _HRESULT_TYPEDEF_(0x80000003L), except that there should
now be no occurances of E_INVALIDARG in the code anymore, they should
have been replaced by the prior #define. So, if my interpretation of
the preprocessor is correct, the second #define has no effect. Why
then are there multiple #define's in the header file? Is this a
programmer mistake? Or is my understanding of the preprocessor not
correct?

Any help is greatly appreciated. I stand humbled in deference to the
superior knowlege of others. Please be gentle if I've used incorrect
terminolgy, but I believe even the dullest individual can see what I
mean.

thanks in advance

--
jondr

.

Relevant Pages

  • Re: about H file parser for standard C
    ... writer / language designer .. ... but these were the two i used to generate an C struct source to source ... complete header files .. ... and also doesn't provide a C preprocessor ... ...
    (microsoft.public.vc.language)
  • Re: A C++ Whishlist
    ... > usability that do not involve modifying the language itself. ... It just adds complexity without functionality to have struct ... As for header files, apparently you don't comple very large applications. ... (No idea what those are, with regards to programming, at least.) ...
    (comp.lang.cpp)
  • Re: A C++ Whishlist
    ... > These are nothing to do with the language or the standard library. ... It just adds complexity without functionality to have struct ... > A struct is just a class that defaults to public instead of private. ... >> will facilitate the automatic synchronization of header files. ...
    (comp.lang.cpp)
  • Re: A C++ Whishlist
    ... >> usability that do not involve modifying the language itself. ... > As for header files, apparently you don't comple very large applications. ... it's libraries without the use of header files. ... > (No idea what those are, with regards to programming, at least.) ...
    (comp.lang.cpp)
  • Re: Do header files really serve a useful purpose?
    ... You have learned Pascal, C and Java. ... C's "header files" synonym is "header ... > there is a good deal of excellent software written in the language. ... The also seem to encourage programmers to avoid using namespaces. ...
    (comp.lang.cpp)