Hi,

>       1.      Don't look for "_WIN32": use the guaranteed "_MSC_VER" so
> folks with
>       unique build requirements don't have to screw with adding an
> additional
>       definition to their projects.  I.e. "#if defined _MSC_VER" replaces
> "#if
>       defined _WIN32".  This is similar to using "__GNUC__", you know the
> compiler
>       defined it and unless someone is intentionally playing games, there
> should
>       never be a problem using that check.
> 
> 
> 
> 
> _WIN32 is for the platform, _MSC_VER is for Visual Studio.  Visual Studio
> isn't the only compiler for Win32/Win64 and _MSC_VER will break on those
> other compilers, for example MinGW and  Cygwin.

        True, I just have a habit of being very explicit about things.  In
this case I've tested the change for VC and someone with the other compilers
could test it for others on a branch, if/when all happy, I'd suggest not
using _WIN32 still and in config.h or somewhere detecting the known
compilers and then defining ZMQ_WIN32 or something along those lines.  Leave
a pragma error or warning for unknown compilers which says "untested".  This
is not much of an issue for other platforms but it is similar in concept to
why you use autoconf on Linux, everyone is just a little different, be safe,
not sorry.  Well, not sorry, just getting yelled at by folks with really
different setups sucks. :)

> _MSC_VER should only be for fruity #pragmas and particulars of MSVC, such
> as lack of C99 headers, broken inline, etc.
> 
> MSVC is very retarded with static libraries, Winsock for example doesn't
> work properly unless you have WIN32 defined and even MSVC 2010
> conveniently removes it from the default configuration compared to
> application targets.

        Totally agree with the retarded statement.  VC and most Win32
compilers for that matter, have a serious set of failures due to the
platform expectations and SDK silliness, not really the compilers
themselves.  Come on, one of my favorites from the SDK:  No one in their
right mind would ever write a function called "CreateWindow" in a namespace
now would they?  Good you agree because if you try; it's a macro in the SDK
and as such if you "don't" include Windozer.h in various files which use it,
you will get nice link errors everywhere looking for "your
namespace::CreateWindowEx" or the Unicode version instead of what you named
it..  :/  I really despise namespace pollutions and WinSDK is an absolute
nightmare of problems with all its crappy ass macro's.


KB

_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to