[libcxx] r194870 - Windows.h is not required.

[Yaron Keren]

Hi Marshal,

If min or max is defined before libcxx, it will warn:

../../libcxx/include\__undef_min_max:16:2: warning: : macro min is
incompatible with C++. #undefing min [-W#warnings]  #warning: macro min is
incompatible with C++.  #undefing min

If min or max is defined after libcxx it's will clash with uses of min and
max in user code.

Either way defining min or max is not compatible with libcxx (or any other
standard C++).

The user does not really have choice. He would have to make sure min and
max are not defined when using libcxx.  Defining NOMINMAX helps the user in
a common use-case.

Yaron




2013/11/18 Marshall Clow <mclow.lists at gmail.com>

> On Nov 15, 2013, at 3:40 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
>
> It may be ok for the library (I did not check yet if ntdef.h or
> minwindef.h are not included indirectly somehow) but will pose a possible
> problem for the libcxx user:
> if he  includes libcxx header followed by <windows.h> without NOMINMAX defined
> he would get min and max defined and trouble.
>
> So to be on the safe side, we would like to get NOMINMAX always defined.
>
> What do you think about moving the code to  __config:
>
> #ifdef _WIN32
> #ifndef NOMINMAX
> #define NOMINMAX
> #endif
> #endif
>
> It will work if the library user includes libcxx before window.h.
>
> In the reverse case we can't avoid getting min and max defined but
> __undef_min_max will warn and undef them.
>
>
> In general, I think that this is a bad idea; we're dictating policy to the
> user of the library.
>
> Besides, it already exists :-)  in include/support/win32/support.h.
>
>
> -- Marshall
>
> Marshall Clow     Idio Software   <mailto:mclow.lists at gmail.com<mclow.lists at gmail.com>
> >
>
> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is
> promptly moderated down to (-1, Flamebait).
>         -- Yu Suzuki
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131118/88cbdf4b/attachment.html>