Re: [boost] Re: Filesystem library updated

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-07-18 14:56:54

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

> On Thu, 18 Jul 2002 09:06:17 -0500, "William E. Kempf"
> <williamkempf_at_[hidden]> wrote:
>
> >> >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.

Yes, but my comment was about the philosophy of what "::" meant with regards
to the Win32 API, not with what the result will typically be.  As long as
the macro reduces to a global function then "::" will do what we want it to
(barring other issues barely related to what you're worried about).  But the
Win32 API isn't this clean.  Not all API's are either functions or macros
that reduce to functions, and MS is free to change any of this on a whim
(and has in the past) and doesn't always document it.  A simple example is
the Yield() API which is a do nothing macro in Win32.  Apply the simple
philosophy to this call and you'll get a syntax error.  There's other
examples as well.  I don't think this is compelling enough to not use "::".
I'm only pointing out that the strict meaning isn't correct (::OpenFile
doesn't mean use the global namespace function OpenFile but instead
indirectly means use the global namespace function OpenFileA or OpenFileW)
which can lead to other misconceptions, and the practice won't work all the
time (just the majority of the time).

I guess I've been bitten by the Win32 macros often enough that I have a
slightly different philosophy.  When I use a MS C++ library, such as MFC or
ATL, I prefix calls with "::" to distinguish the global function calls from
class function calls and this works fine most of the time (except for cases
like Yield(), which is a bad example since it's not a function I'd ever call
but is the only one comming to me at the moment that's truly a macro).  In
other cases, I avoid using MS style InitCaps entirely, since this causes
many issues (I once defined a thread class with a Yield() member function
which failed to compile :P), and since I don't use such names there's little
reason to use the "::" prefix and simply don't.  The reason is only because
the "::" says something that may or may not be true since so much of the
APIs are macros (this is being picky about what "::" documents to the user
instead of what it semantically causes, and I'm picky in this case because
there's no reason for the semantic results).

Bill Kempf