Are Boost.Multi_Index and Boost.Format Planned for 64-bit Portability?
Hi all,
It's the first time I tried multi_index and format. I have to say that
they are so powerful that I love them from the beginning!
Nonetheless, when I enabled /Wp64 on my MSVC71 compiler, the headers
gave me a lot of problems regarding possible pointer truncations (and
sometimes default c'tor problems). The relevant warnings are something
like the following:
==== snip
"Wu Yinghui, Freddie" ha escrito:
Hi all,
It's the first time I tried multi_index and format. I have to say that they are so powerful that I love them from the beginning!
Nonetheless, when I enabled /Wp64 on my MSVC71 compiler, the headers gave me a lot of problems regarding possible pointer truncations (and sometimes default c'tor problems). The relevant warnings are something like the following:
[...]
So I just wonder if both of these libraries have any plan on considering this issue? I really love these libraries, and I want to integrate them into our future product. But if the 64-bit portability issues are not solved, I'm afraid I'll have some problem pursuading the managers.
Hello Freddie, As for Boost.MultiIndex, I can confirm the lib does work in 64-bit environments (for instance, Linux PPC64, Tru64) and must also work for Win64, although I've never had actual reports about this latter platform (if you've got access to Win64, you might want to try and tell back.) With respect to /Wp64 warnings, they are of two kinds: * C4312/C4311, conversions between differently sized types: this is a case of /Wp64 being too dumb in its analysis of the type boost::multi_index::detail::uintptr_type; this type is defined with some metaprogramming machinery to be some integral type with the same size as void*. So, it is unsigned int in Win32 and unsigned long long in Win64. But /Wp64 sees it defined as unsigned int, hence the warning. It is as if you had: #ifdef _WIN64 typedef unsigned int integral_type; #else typedef unsigned long long integral_type; #endif void *p; integral_type x=(integral_type)p; /Wp64 is not able to see that integral_type will be defined as unsigned long long in Win64, and emits a C4311. * Complains about some internal node classes not being constructable or about their automatic default constructors being impossible to generate. I don't see what this has to do with 64-bit portability; in any case, the compiler is right about the analysis, but not about the consequences: these classes are in effect never default constructed, their lifetime being managed through an allocator interface. This is just an overzealous warning. So, Boost.MultiIndex must work in Win64, the best way to check this out is to actually try. As for Boost.Format, I cannot say cause I'm not the maintainer, but in any case it seems to work on other 64-bit environments as per the regression tests, and potential 64-bit problems should be easy to tackle. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (2)
-
Joaquín Mª López Muñoz -
Wu Yinghui, Freddie