On Monday, 24 October 2011 20:31:02 UTC+1, Cactus wrote: > > You are right - size_t is supposed to be 64-bits on Windows x64. But to > get this behaviour, you have to define _WIN64 during the build process. > > I have been caught by this so many times because _WIN64 is supposed to be > a predefined macro, onr that is automatically defined for 64-bit builds. > > But, as far as I can see, it has to be user defined. > > Brian > > Sorry this is late in the day, but surely defining _Win64 is required internals to getting an x64 build? In Intel MKL at least ILP64 is the usual notation for 64bit integers on x64 - while LP64 refers to using 32 bit integers in an x64 environment. This is orthogonal to the language used in this thread.
At the risk of opening old discussions, one point I never understood is the trouble over 32bit and 64 bit integers in GMP/MPIR. It seems this is still (2016) causing trouble in some parts of the testing code. The mkl solution is one way, with distinct ILP64, LP64, WIN32 libraries; but ?unless I am missing something, it seems that all MPIR wanted was integers that are 64 bit on 64 bit machines and 32 bits on 32 bit machines. Surely this configuration is always available from the original unix code via a global replace of unsigned int by std::size_t and int by std::ptrdiff_t in <cstddef>. As far as I can see this is truly system independent and standard compliant. If one wants precise bit length integers then int32_t and int64_t seem the way to go - as they are (rather elegantly) only defined in the standard if the OS actually has those lengths (which it may not since a byte may not be 8 bits). The subtle flaws referred to in MPIR documentation really come neither from windows or unix but from using a non-standard defined behaviour of int when really this is not necessary (although understandable). The type int should probably not appear anywhere in the code of MPIR except for input and output to other api's (such as output) where it should be checked for overflow using safeint<> or similar. I worry that builds (at least of tests) still show some 64bit<->32bit conversion warnings. I suppose now that the underling library code is really OK. I certainly believe/assume that if I use strings to serialise and pass long integers between machines in MPI there is no danger of lost information. In fact I think MPIR::GMP is a great tool. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
