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 <[email protected]> > On Nov 15, 2013, at 3:40 PM, Yaron Keren <[email protected]> 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:[email protected]<[email protected]> > > > > A.D. 1517: Martin Luther nails his 95 Theses to the church door and is > promptly moderated down to (-1, Flamebait). > -- Yu Suzuki > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
