Re: [boost] Re: Filesystem library updated

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

----- Original Message -----
From: "Gennaro Prota" <gennaro_prota_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Thursday, July 18, 2002 7:04 AM
Subject: [boost] Re: Filesystem library updated

> On Thu, 18 Jul 2002 09:15:01 +0100, Alan Bellingham <alan_at_[hidden]>
> wrote:
>
> >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.
>
>
> Ooops... there was a misunderstanding. I was thinking of macros that
> don't simply expand to function names, which presumably was what
> William had in mind too (otherwise why raising the problem of the
> scope resolution operator?)

No, I was referring to both types.  I believe the why was illustrated in
another post.  Even something as simple as SearchPath being defined to
SearchPathA and SearchPathW can lead to problems that namespaces can't fix.

> Also (mea culpa), I didn't check whether there are such macros in the
> filesystem library sources.

There's a bunch of them ;).

Bill Kempf