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

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

----- Original Message -----
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_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
> news:vvtcju4vl33a0l502ipciu3faocelt2no9_at_4ax.com...
> > 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
> of
> > >>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?

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...

Bill Kempf