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

[Francesco Pretto]

Hi Petr,

with push_macro()/pop_macro() as you suggested I can do this:
-------------------------------
enum class TestEnum
{
#ifdef WIN32
#pragma push_macro("WIN32") // Store the WIN32 define with it's value
#undef WIN32
#define WIN32_WAS_SET
#endif // WIN32
    WIN32 = 1,
    WIN32GDI = 1,
#ifdef WIN32_WAS_SET
#pragma pop_macro("WIN32") // This correctly restores WIN32 macro
#endif // WIN32_WAS_SET
};

int main()
{
#ifdef WIN32
    // Still works
#endif // WIN32
    TestEnum enm = TestEnum::WIN32GDI;
    return 0;
}
-------------------------------

It's a bit overkill to me but it solves the problem in a smart way
without forcing an immediate API change. Still, it makes sense to
deprecate the WIN32 identifier since it can't be used safely by all
users.

Regards,
Francesco




On Wed, 6 Jan 2021 at 18:14, Petr Kobalíček <kobalicek.petr at gmail.com> wrote:
>
> You can do that with #pragma push_macro() / pop_macro(), see:
>
>   https://docs.microsoft.com/en-us/cpp/preprocessor/push-macro?view=msvc-160
>
> I think that compatibility with various libraries and build systems is always a greater deal than opinions about what's right or wrong. The problem can be fixed by introducing a synonym to WIN32 (name already proposed) together with still providing the old WIN32 name guarded by push_macro() / pop_macro() - that way no project would break and new projects can start using the new symbol instead.
>
>
> On Wed, Jan 6, 2021 at 4:56 PM Francesco Pretto <ceztko at gmail.com> wrote:
>>
>> Hello James. I reply below.
>>
>> On Wed, 6 Jan 2021 at 16:05, James K. Lowden <jklowden at schemamania.org> wrote:
>>>
>>> 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
>> #endif
>>
>> enum class TestEnum
>> {
>>     WIN32
>> };
>>
>> #ifdef WIN32_WAS_SET
>> #define WIN32 1
>> #endif
>>
>> 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.
>>
>> Regards,
>> Francesco
>> --
>> cairo mailing list
>> cairo at cairographics.org
>> https://lists.cairographics.org/mailman/listinfo/cairo