Re: [boost] Re: Re: Filesystem library updated

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-07-18 10:09:14

----- Original Message -----
From: "Alan Bellingham" <alan_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, July 18, 2002 8:21 AM
Subject: Re: [boost] Re: Re: Filesystem library updated

> "Anthony Williams" <anthony_w.geo_at_[hidden]>:
>
> >The only solution is to #include <windows.h> in the TU that defines the
> >class SearchPath, or to avoid every name in the windows API. Yuck.
>
> The _other_ only solution is to include a file afterwards that #undefs
> all those lovely macros and provides inline forwarding functions
> instead. Once I've finished the house move, I'll be getting a round tuit
> ... around to finishing a first draft of such an include file.
>
> e.g.:
>
>   #if defined(CharLower)
>   #  undef CharLower
>      inline char   * CharLower(char   * Src) { return CharLowerA(Src); }
>      inline wchar_t* CharLower(wchar_t* Src) { return CharLowerW(Src); }
>   #endif

I don't think this is the correct solution.  The macro CharLower doesn't map
to two differing functions like this.  It maps to only one function
depending on whether or not UNICODE is defined.  So the correct solution
would be:

#if defined(CharLower)
#  undef CharLower
#  if defined(UNICODE)
      inline wchar_t* CharLower(wchar_t* Src) { return CharLowerW(Src); }
#  else
      inline char* CharLower(char* Src) { return CharLowerA(Src); }
#  endif
#endif

Otherwise, the following code will now compile when otherwise it would not
have:

#define UNICODE
#include <windows.h>
#include <iostream>

int main(int argc, char* argv[])
{
   std::cout << CharLower("HELLO WORLD");
   return 0;
}

You could argue that "it does the right thing" when it compiles with your
solution, but this is a change in behavior, not a "fix" for the macro misuse
in the Windows API.  I'd support a fix like the one I give above (and hope
that MS does this themselves someday soon, since a user header that does
this is only going to be problematic with regards to inclusion order), but
I'd oppose one like you gave.

Bill Kempf