From: Wheeler, F. W (Research) <wh...@cr...> - 2003-10-27 15:52:18
|
How about a new option named VXL_SUPPORT_INT_64. It would default to false on MSVC 6.0 and true elsewhere. True would indicate that the user wishes for the VXL build to support int64. int64 stuff would only the compiled if VXL_SUPPORT_INT_64 is true *and* VXL_HAS_INT_64 is true. Or, we could have a new try-compile test to see whether the int64 type is actually supported by the compiler and associated libraries, by trying things like casting to double, and sending an int64 to cout. It might be named VXL_INT_64_SUPPORTED. Fred Wheeler > -----Original Message----- > From: Ian Scott [mailto:ian...@st...] > Sent: Monday, October 27, 2003 10:35 AM > To: Vxl-maintainers (E-mail); Brad King (E-mail) > Subject: [Vxl-maintainers] vxl_int_64, vxl_config.h and MSVC6.0 > > > Currently VXL_HAS_INT_64 is true for MSVC6.0, and vxl_int_64 > is typedefed to > __int64, a compiler-defined type. > > Peter Vanroose has started adding lots of optional 64 bit > code which is > being turned on for MSVC6.0 Unfortunately MSVC6.0's idea of a > 64 bit integer > doesn't extend to support in the stream library, or even > casting to double. > It seems to me that whilst MSVC6.0 has an 64bit type, it > would be best if we > pretended it didn't. > > Now currently both the old hard-coded version of > vcl\config.win32\vc60\vxl_config.h and the new, CMake > generated one give > identical results. It is trivial to fix the old hard-coded > version. But I > have no idea of the best means of overriding the result > generated by CMake. > > Any comments/suggestions? > > Ian. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <pe...@cs...> - 2003-10-27 16:04:47
|
I think it's a bad idea to have yet another variable. With more variables, the checks become more complicated and error-prone. I think we should either add support to output 64-bit ints for MSCV 6 http://groups.google.com/groups?selm=77iksn%243v4%241%40brokaw.wa.com (provided this is the only problem), or else indicate that 64 bits are not available on MSVC 6. 64 bit ints are an extension anyway, so supporting them is not crucial. On Mon 27 Oct 2003, Wheeler, Frederick W (Research) wrote: > Or, we could have a new try-compile test to see whether the int64 type is > actually supported by the compiler and associated libraries, by trying > things like casting to double, and sending an int64 to cout. It might be > named VXL_INT_64_SUPPORTED. We should do this anyway, either for configure purposes or in the regression tests, just to make sure that support does mean support. Just my thoughts. Amitha. |
From: Ian S. <ian...@st...> - 2003-10-27 16:30:24
|
> From: Amitha Perera [mailto:pe...@cs...] > I think it's a bad idea to have yet another variable. With more > variables, the checks become more complicated and error-prone. I agree. > > I think we should either add support to output 64-bit ints for MSCV 6 > > > http://groups.google.com/groups?selm=77iksn%243v4%241%40brokaw.wa.com > > (provided this is the only problem), or else indicate that 64 bits are > not available on MSVC 6. There are other problems. e.g. the following fails. unsigned __int64 i = 64; double d = (double) b; with an error suggesting you cast the unsigned __int64 to __int64 before casting to double. Whilst we could use the fix for streams, and provide a global cast operator somewhere, and fix any other hassles that turn up. I doubt anyone on MSVC6.0 uses 64 bits, so it would easier to have VCL_HAS_64_INT=0 I just don't know the best way to achieve this in the new CMake scheme. Ian. |
From: Gehua Y. <ya...@rp...> - 2003-10-27 18:04:13
|
----- Original Message ----- From: "Ian Scott" <ian...@st...> To: "Vxl-maintainers (E-mail)" <vxl...@li...> Sent: Monday, October 27, 2003 11:29 AM Subject: RE: [Vxl-maintainers] vxl_int_64, vxl_config.h and MSVC6.0 > Whilst we could use the fix for streams, and provide a global cast operator > somewhere, and fix any other hassles that turn up. I doubt anyone on MSVC6.0 > uses 64 bits, so it would easier to have VCL_HAS_64_INT=0 > I agree with Ian that it is easier to pretend MSVC6.0 does not have 64 bits. I think most people using MSVC6.0 would not care about 64bit integer at all. Besides, It is an extension anyway. On Mon 27 Oct 2003, Wheeler, Frederick W (Research) wrote: > Or, we could have a new try-compile test to see whether the int64 type is > actually supported by the compiler and associated libraries, by trying > things like casting to double, and sending an int64 to cout. It might be > named VXL_INT_64_SUPPORTED. I think we should do it this way. Just a couple thoughts. Gehua |
From: Amitha P. <pe...@cs...> - 2003-10-27 20:43:00
|
On Mon 27 Oct 2003, Ian Scott wrote: > > From: Amitha Perera [mailto:pe...@cs...] > > I think it's a bad idea to have yet another variable. With more > > variables, the checks become more complicated and error-prone. > > I agree. [...] > I just don't know the best way to achieve this in the new CMake > scheme. I've just committed a couple of changes that makes the CMake process do a more thorough check. With this, MSVC 6 does not have a 64-bit int type while MSVC 7 does. This should take care of the problem. Amitha. |