From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2002-07-18 05:54:30
"Alan Bellingham" <alan_at_[hidden]> wrote in message
> Gennaro Prota <gennaro_prota_at_[hidden]>:
> >On Tue, 16 Jul 2002 12:24:56 -0500, "William E. Kempf"
> ><williamkempf_at_[hidden]> wrote:
> >>Which is an argument against using :: for Win32, since the vast majority
> >>Win32 API calls are macros.
> >Well, many are. I haven't had the impression they are the vast
> >majority though.
> In general, anything that takes a char* argument (or any structure
> containing a char*) exists in two forms - a FunctionA() and a
> FunctionW(), with the latter being the 'unicode' (16-bit wide char)
> version. There is then a macro defined that maps Function onto FunctionA
> or FunctionW as appropriate.
> Since those macros are of the form
> #define Function FunctionA
> then prefixing with :: causes the scope specification to apply to the
> result of the macro, and it doesn't cause a problem.
It also essentially reserves that name for the Windows API --- if you use
that name as a name in one of your headers, then the include order of that
header relative to windows.h matters.
For example you have a nice class SearchPath that doesn't use the windows
API, so windows.h doesn't appear anywhere in its translation unit.
In another translation unit, that #include's windows.h _before_
SearchPath.h, the class is called SearchPathA (or SearchPathW), so the TU
compiles OK, but the extern refences will be wrong.
Also, in a translation unit that includes windows.h _after_ SearchPath.h,
the class is called SearchPath, but every reference is to SearchPathA, so
the definition is never found, and the TU won't compile.
Yuck. This even applies if your class is boost::SearchPath, as macros don't
respect namespaces. Don't we just love the preprocessor?
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.
-- Anthony Williams Software Engineer, Nortel Networks Optical Components Ltd The opinions expressed in this message are not necessarily those of my employer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk