From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-07-18 14:09:29
On Thu, 18 Jul 2002 09:06:17 -0500, "William E. Kempf"
>> >Gennaro Prota wrote:
>> 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.
I still think there's some misunderstanding. I meant that, in that
case, it would be ok to write :: SearchPath. In general I was saying
that if what appears as a Win32 API call of the form
function_name ( arg-list ) // (*)
and macro-name is defined as
#define macro_name function_name
then putting a :: in front of (*) doesn't cause any syntax error.
If macro_name doesn not expand to a function name (e.g. MAKELANGID)
we, of course, won't use any "::"
>> Also (mea culpa), I didn't check whether there are such macros in the
>> filesystem library sources.
>There's a bunch of them ;).
William, of course there are a lot of macro names that don't expand to
function names. And for those nobody would use the scope resolution
For the "they seem function" group, a quick - non sistematic - glance
at the sources showed the following names:
Those marked with 'mf' are expanded to function names. FindClose,
GetLastError and LocalFree appear to be actual function names (the
question mark on the last one is due to a little hack I found in a
file named edkdebug.h in the vc98/include directory, which anyhow
doesn't affect the filesystem library).
My point was that, except for MAKELANGID, all those names could be
prefixed with ::
In any case, as I said, it's not a big harm if everything remains as
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk