Hi Alan,
I have had a look at the two discussions Alaric and you mention, and I agree
that the best choice seems to be _WIN32 to indicate the Windows platform. I
hesitate, however, to be absolutely sure, on the following grounds:
- The tip on detecting the operating systems mentions that there is no
64-bits Cygwin system, but that was the case back in 2012. I have been using
Cygwin 64-bits for a couple of years now.
- There is also mention of Cygwin in a POSIX and in a non-POSIX variant.
I have no clue as to how to determine which one I am working with or how to
specify that at install time.
- Also the table "Windows, Cygwin (non-POSIX), and MinGW" has columns
for the "Windows target" and the "MinGW target". It is unclear to me what they
mean by that.
- Furthermore: is "MinGW" the old-style MinGW or the new one,
MinGW-w64/MSYS2? From the date of the post, I would say the former.
All that does not mean that we should not consistently use _WIN32, but perhaps
some care is to be taken. The page
https://msdn.microsoft.com/en-us/library/b0084kay.aspx indicates that Visual
C++ does define _WIN32 for both the 32-bits and 64-bits platforms. On the other
hand, this page from the GNU C compiler documentation says that macros whose
name starts with two (!) underscores are to be considered reserved and does not
mention the one-underscore macros as being special (only historical):
https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/System-specific-Predefined-Macros.html#System-specific%20Predefined%20Macros.
I guess that only adds to the confusion :(.
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, October 09, 2017 8:02 PM
> To: Arjen Markus; PLplot development list
> Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
>
> Hi Arjen:
>
> I am addressing you because you are our primary Windows platform expert, but I
> would be happy to hear from others here as well (including Alaric) with some
> knowledge of that platform.
>
> What would be your advice concerning replacing our use of the WIN32 and
> __WIN32__ macros in our source code?
>
> Basically, Alaric (see his bug report below) has found a platform where the
> _WIN32
> macro is #defined but not WIN32, and the stackoverflow discussion he
> referenced
> appears to say the two macros ordinarily have the same meaning but the
> underscored one is a bit safer to use because there is a convention it should
> not be
> changed by anyone other than the compiler vendor.
>
> Note, however, that Alaric's bug report does not cover the entire problem in
> our
> code because we also make use of the __WIN32__ macro.
> Another stackoverflow discussion concerning that macro referenced
> <https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/
> 2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
> >.
>
> My conclusion from reading the "Windows, Cygwin (non-POSIX), and MinGW"
> section of that article is the safest course for supporting all Windows
> compilers is
> for us to replace all use of the WIN32 and __WIN32__ macros in our C and C++
> code with use of the _WIN32 macro instead. Do you agree?
>
> If so, I would be willing to take responsibility for the actual code change
> since Linux
> has excellent facilities (find and
> sed) for automatic mass-editing of code.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi
> project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the
> Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ---------- Forwarded message ----------
> Date: Mon, 09 Oct 2017 15:52:10 +0000
> From: Alaric Senat <alaric1...@users.sf.net>
> Reply-To: Ticket 189 <1...@bugs.plplot.p.re.sf.net>
> To: Ticket 189 <1...@bugs.plplot.p.re.sf.net>
> Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
>
>
>
>
> ---
>
> ** [bugs:#189] Using WIN32 Macro instead of _WIN32**
>
> **Status:** open
> **Group:**
> **Created:** Mon Oct 09, 2017 03:52 PM UTC by Alaric Senat **Last Updated:**
> Mon Oct 09, 2017 03:52 PM UTC
> **Owner:** nobody
>
>
> Hello,
>
> This ticket is just about a little detail and its not exactly a bug.
> Me and my team are cross-compiling for windows, and we noticed that you are
> often using the WIN32 macro in your source files to check the current
> compilator
> platform.
> We needed to switch these macros to \_WIN32 because in our case, we are
> compiling with the *-std=c++14* flag and is disable WIN32 cause it's not in
> the
> standard.
> To my mind, It would be a bit safer if those WIN32 were switched to \_WIN32
> in a
> further version of PlPlot!
>
> Here is a nice topic on that point :
> https://stackoverflow.com/questions/662084/whats-the-difference-between-the-
> win32-and-win32-defines-in-c/662543#662543
>
> Regards,
> Alaric Senat
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in
> <https://sourceforge.net/p/plplot/bugs/189/>
>
>
>
> To unsubscribe from further messages, please visit
> <https://sourceforge.net/auth/subscriptions/>
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
