From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-07-18 09:01:15
----- Original Message -----
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
Sent: Thursday, July 18, 2002 5:54 AM
Subject: [boost] Re: Re: Filesystem library updated
> "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
> > >>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
> respect namespaces. Don't we just love the preprocessor?
This is what I was referring to. It makes the prefixed "::" at least a
little misleading, even if useful a good portion of the time.
> 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.
Avoiding names in the Windows API isn't that large of a burden, especially
for Boost development. Simply don't use names that follow the InitCap
style, and since Boost guidelines call for all lowercase names...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk