[cairo] cairomm: Visual Studio WIN32 define clash with Surface::Type::WIN32

Francesco Pretto ceztko at gmail.com
Wed Jan 6 15:56:19 UTC 2021

Hello James. I reply below.

On Wed, 6 Jan 2021 at 16:05, James K. Lowden <jklowden at schemamania.org>

> On Wed, 6 Jan 2021 11:05:24 +0100
> The best solution ISTM is to add
>         #undef WIN32
> somewhere early in the Cairo header files, and document it
> accordingly.  Short of that, document it only, and caveat emptor.
> Developers should minimize use of the preprocessor, and definitely
> not define macros that don't need to be defined!
I just tried a quick "hello world" program and this does not seem to work
to me, or it doesn't
seems to be a viable solution, unless you point me how it is supposed to
work. I show what you what I tried:
#ifdef WIN32
#undef WIN32
#define WIN32_WAS_SET

enum class TestEnum

#ifdef WIN32_WAS_SET
#define WIN32 1

int main()
    TestEnum enm = TestEnum::WIN32; // Doesn't compile anyway in VS2019
    return 0;

Re-defining WIN32 if it was found defined is a must, because it would be
bullying, if not "criminal", to just undef it, potentially breaking outer
software that legitimately use it.
Is there a way to escape the TestEnum::WIN32 identifier in C++ in this
case? Consider that I'd prefer to not use odd solutions, but still show me
what you suggested.

>  or read the words of the project maintainer Brad King[3].
> As I read his words, he was asking for the nonexistent, namely official
> Microsoft documentation for WIN32.  Four years ago he said that 14
> years prior CMake had defined WIN32 because "the project ... wanted it
> defined". Two decades ago, that was common practice.  No need to
> promulgate it further today.
When the implications are very small (and I think we are in this domain) I
think that library developers should be pragmatic and not waste their
resources in fighting against windmills. WIN32 is still defined today in
all default projects in latest VS 2019, and all projects generated by the
latest CMake version. Unless there is a 100% working solution that keeps
the WIN32 identifier and that doesn't possibly break any correct use of the
WIN32 macro, as defined by the SDK, the build system or the user, the wiser
choice would be to just assume WIN32 is a reserved word when compiling
under Visual Studio.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20210106/ef049526/attachment.htm>

More information about the cairo mailing list