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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2002-07-23 03:49:32

"Alan Bellingham" <alan_at_[hidden]> wrote in message
news:7bdgjuo2gi6frhvrp62772h3351pgna254_at_4ax.com...
> "Anthony Williams" <anthony_w.geo_at_[hidden]>:
>
> >These are all valid workarounds. I think I prefer option 1, but I
wouldn't
> >like to maintain the de-macro-fying header, given that MS changes/extends
> >the API every few months...
>
> Well, there's always diff ...
>
> >Also, as Gennaro pointed out in another post, the MFC and ATL classes
have
> >members that _pretend_ to be called MessageBox, GetWindowText... If you
make
> >these real names, and not macros, then you will probably meet
> >problems.somewhere.
>
> Erk!
>
> In the name of all that's holy, that's _vile_. Actually, I suspect that
> ATL may be OK (it does tend to be template based code, not relying on
> pre-built code so much),

It's OK, provided you're consistent about the order you include the headers

> but I think you're right about MFC.
>
> What a horrible concept.
>
> Still, given that all headers that rely on this behaviour should be
> included before the undefining header, it looks doable.

For ATL, you just have to remember that they've changed name when you call
them or implement them, if you include the #undef header _after_ the ATL
headers, unless you always include the #undef header _before_ all the ATL
headers (in which case you have to guarantee it's included in every
translation unit).

I totally agree that it's a big mess. Without #undef-ing everything, you
can't use names from the windows API, unless you ensure that windows.h is
included first, in case someone includes it later and renames then can't use
your functions or classes, because the name has changed. If you #undef
everything, then that problem goes away, but you have to #undef things
consistently, which means you probably need to ensure that windows.h _and_
the #undef header are included first in every translation unit, to ensure
everything (except MFC) works out OK.

In short, for code that works whether or not windows.h is included, you are
safest to avoid the names from the windows API, and let MFC and ATL take
care of themselves.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer