RE: [boost] Win32 undefs/redefs [was File operations: Win32 question [was Re: the first version of abstract path...]]

From: Jason Shirk (jasonsh_at_[hidden])
Date: 2002-02-23 23:54:52

We are well aware of the issue and very much want it fixed as you
describe below.

The most pressing reason is the fact that .NET API's have names that
conflict with the SDK macros, like MessageBox for example.

Of course, nothing like this is ever simple, so there is no guarantee
you'll see the changes in official headers anytime soon.  But then
again, you might, we'll see.

Jason Shirk
VC++ Compiler Team

> -----Original Message-----
> From: Alan Bellingham [mailto:alan_at_[hidden]]
> Sent: Saturday, February 23, 2002 11:36 AM
> To: boost_at_[hidden]
> Subject: [boost] Win32 undefs/redefs [was File operations: Win32
question
> [was Re: the first version of abstract path...]]
> 
> "David Abrahams" <david.abrahams_at_[hidden]>:
> 
> >From: "Alan Bellingham" <alan_at_[hidden]>
> >
> >> I dislike header files introducing macros for mixed or lower case
> >> identifiers, because of the preprocessor's disregard for scope, so
I
> >> actually have a 40,000 line header file that undefines all such
macros
> >> introduced by the Win32 API headers and a shorter file that applies
> >> inline overloads as above, on a case by case basis.
> >
> >Any chance you can make this available for general use? It would be a
> great
> >service to the C++ community.
> 
> I have already had a request to write this up for Overload, and I'm
> looking for the suitable round tuit ...
> 
> The 40KLOC undefs.h header is auto-generated using a Perl script (and
is
> somewhat bloated as a result, since multiple definitions occur in the
> headers). _All_ it contains is entries like:
> 
>   #if defined(GetFileAttributes)
>   #   undef GetFileAttributes
>   #endif // defined(GetFileAttributes)
> 
> The redefs.h header then contains:
> 
>   inline DWORD GetFileAttributes(char const* FileName)
>   {
>      return GetFileAttributesA(FileName) ;
>   }
>   inline DWORD GetFileAttributes(wchar_t const* FileName)
>   {
>      return GetFileAttributesW(FileName) ;
>   }
> 
> but only for those functions I currently use, so it's a small subset
of
> the entire possible content - as I encounter a Win32 API function that
> isn't yet in it, I then include it.
> 
> At the moment, the sheer size of the headers is a bit of a pain - it
> works fine with C++ Builder and precompiled headers, but since it
> attempts to 'fix' every header I found, it's unnecessarily messy. It
> works best with all relevant Win32 headers preincluded, which is not a
> terribly good idea, as any Win32 header included afterwards is going
to
> mess it up.
> 
> At the moment, I'm looking at producing a set of headers - an undef
and
> redef pair to shadow each Win32 header - and including those actually
> required.
> 
>   // user's source file
>   #include <winbase.h>
>   #include ...  // all other Win32 headers used
>   #include "undefs.h"
>   #include "redefs.h"
>   #include ... // all other headers required
> 
>   // undefs.h
>   #if defined(INC_WINBASE_H) // or whatever the guard actually is ...
>   #  include "undef_winbase.h"
>   #endif
> 
>   // redefs.h
>   #if defined(INC_WINBASE_H) // or whatever the guard actually is ...
>   #  include "redef_winbase.h"
>   #endif
> 
>   // undef_winbase.h
>   #if defined(GetFileAttributes)
>   #   undef GetFileAttributes
>   #endif // defined(GetFileAttributes)
> 
>   // redef_winbase.h
>   inline DWORD GetFileAttributes(char const* FileName)
>   {
>      return GetFileAttributesA(FileName) ;
>   }
>   inline DWORD GetFileAttributes(wchar_t const* FileName)
>   {
>      return GetFileAttributesW(FileName) ;
>   }
> 
> >In fact, I wonder if Microsoft might pick up something like this;
even
> >putting everything into a namespace? Goes hand-in-hand with serious
> support
> >for C++...
> 
> I wish. If I were in charge of their headers, I think I'd do:
> 
>   WINBASEAPI DWORD WINAPI GetFileAttributesA(IN LPCSTR lpFileName);
>   WINBASEAPI DWORD WINAPI GetFileAttributesW(IN LPCWSTR lpFileName);
> 
>   #if !defined(__cplusplus) || defined(USE_C_MACROS_NOT_INLINE)
>   #   ifdef UNICODE
>   #      define GetFileAttributes  GetFileAttributesW
>   #   else
>   #      define GetFileAttributes  GetFileAttributesA
>   #   endif // !UNICODE
>   #else
>     inline DWORD GetFileAttributes(char const* FileName)
>     {
>       return GetFileAttributesA(FileName) ;
>     }
>     inline DWORD GetFileAttributes(wchar_t const* FileName)
>     {
>       return GetFileAttributesW(FileName) ;
>     }
>   #endif // defined(__cplusplus) && !defined(USE_C_MACROS_NOT_INLINE)
> 
> thereby leaving the C guys as they were, but leaving C++ users with
the
> great advantage of being able to use the inline versions with their
> overloading.
> 
> And yes, namespaces would be cute:
> 
>   #if !defined(__cplusplus) || defined(USE_C_MACROS_NOT_INLINE)
>       WINBASEAPI DWORD WINAPI GetFileAttributesA(IN LPCSTR
lpFileName);
>       WINBASEAPI DWORD WINAPI GetFileAttributesW(IN LPCWSTR
lpFileName);
>   #   ifdef UNICODE
>   #      define GetFileAttributes  GetFileAttributesW
>   #   else
>   #      define GetFileAttributes  GetFileAttributesA
>   #   endif // !UNICODE
>   #else
>   namespace Win32 {
>     inline DWORD GetFileAttributesA(char const* FileName)
>     {
>       extern WINBASEAPI DWORD WINAPI GetFileAttributesA(LPCSTR); //???
>       return ::GetFileAttributesA(FileName) ;
>     }
>     inline DWORD GetFileAttributesW(wchar_t const* FileName)
>     {
>       extern WINBASEAPI DWORD WINAPI GetFileAttributesW(LPCWSTR);
>       return ::GetFileAttributesW(FileName) ;
>     }
>     inline DWORD GetFileAttributes(char const* FileName)
>     {
>       return GetFileAttributesA(FileName) ;
>     }
>     inline DWORD GetFileAttributes(wchar_t const* FileName)
>     {
>       return GetFileAttributesW(FileName) ;
>     }
>   } // namespace Win32 {
>   #endif // defined(__cplusplus) && !defined(USE_C_MACROS_NOT_INLINE)
> 
> which would have the advantage of removing the explicit A/W
identifiers
> from the global namespace while still linking correctly to the
external
> functions (I think - the above is untested - how _do_ you locally
> declare a global namespace function while within a function in an
inner
> namespace?).
> 
> 
> Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-
> unsubscribe_at_[hidden]>
> 
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>