Are Boost.Multi_Index and Boost.Format Planned for 64-bit Portability?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Are Boost.Multi_Index and Boost.Format Planned for 64-bit Portability?

Wu Yinghui, Freddie
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 <multi_index> =====
..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(129)
: warning C4312: 'type cast' : conversion from
'boost::multi_index::detail::uintptr_type' to 'void *' of greater size
..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(134)
: warning C4311: 'type cast' : pointer truncation from 'void *' to
'boost::multi_index::detail::uintptr_type'
..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(161)
: warning C4312: 'type cast' : conversion from 'const
boost::multi_index::detail::uintptr_type' to 'void *' of greater size
..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(509)
: warning C4610: struct
'boost::multi_index::detail::ordered_index_node_impl' can never be
instantiated - user defined constructor required
..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(512)
: warning C4510:
'boost::multi_index::detail::ordered_index_node_trampoline<Super>' :
default constructor could not be generated
..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(562)
: warning C4510: 'boost::multi_index::detail::ordered_index_node<Super>'
: default constructor could not be generated
===== snip =====

===== snip <format> =====
..\..\..\boost-1.x\include\boost-1_34\boost\format\alt_sstream_impl.hpp(110)
: warning C4244: 'argument' : conversion from
'boost::io::basic_altstringbuf<Ch,Tr,Alloc>::off_type' to 'int',
possible loss of data
..\..\..\boost-1.x\include\boost-1_34\boost\format\feed_args.hpp(98) :
warning C4244: 'argument' : conversion from 'const
stlpd_std::iterator_traits<_Iterator>::difference_type' to 'int',
possible loss of data
..\..\..\boost-1.x\include\boost-1_34\boost\format\feed_args.hpp(53) :
warning C4244: 'argument' : conversion from 'stlpd_std::streamsize' to
'stlpd_std::basic_string<_CharT,_Traits,_Alloc>::size_type', possible
loss of data
===== snip =====

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.

Cheers,

Freddie

--
Wu Yinghui, Freddie
Research & Development
Software Engineer

Volume Interactions Pte Ltd
1 Kim Seng Promenade, #12-01
Great World City East Tower
Singapore 237994
Tel:   +65 62226962 (Ext 216)
Fax:   +65 62226215
Email: [hidden email]
URL:   http://www.volumeinteractions.com

Important:  This message is intended for the recipient(s) addressed
above.  It contains privileged and confidential information.  If you are
not the intended recipient, please notify the sender immediately by
replying to this message and then delete it from your system.  You must
not read, copy, use, or disseminate this communication in any form.
Thank you.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

yhwu.vcf (800 bytes) Download Attachment
signature.asc (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are Boost.Multi_Index and Boost.Format Planned for64-bitPortability?

Joaquin M LópezMuñoz
"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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Are Boost.Multi_Index and Boost.Format Planned for64-bitPortability?

Wu Yinghui, Freddie
> 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.
Thanks for your helpful explanation. Since this types of warnings flood
the compiler output, which very difficult for us to notice other more
valuable warnings. Guess we'll need to figure out some way to "hide" the
stupid compiler behaviour?

> * 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.

Hmm... In this case, I guess I'd just try to add some default
constructors for these classes without implementing them. That way, I
can at least get away with this type of warnings.

> So, Boost.MultiIndex must work in Win64, the best way to
> check this out is to actually try.

I do not have the 64-bit machine with me yet. But I'll report back later
once I actually have the chance to try it out.

> 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.

Thanks for your insights!

> Joaqu?n M L?pez Mu?oz
> Telef?nica, Investigaci?n y Desarrollo
>
Cheers,

Freddie

--
Wu Yinghui, Freddie
Research & Development
Software Engineer

Volume Interactions Pte Ltd
1 Kim Seng Promenade, #12-01
Great World City East Tower
Singapore 237994
Tel:   +65 62226962 (Ext 216)
Fax:   +65 62226215
Email: [hidden email]
URL:   http://www.volumeinteractions.com

Important:  This message is intended for the recipient(s) addressed
above.  It contains privileged and confidential information.  If you are
not the intended recipient, please notify the sender immediately by
replying to this message and then delete it from your system.  You must
not read, copy, use, or disseminate this communication in any form.
Thank you.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

yhwu.vcf (800 bytes) Download Attachment
signature.asc (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are Boost.Multi_Index and Boost.Format Plannedfor64-bitPortability?

Joaquin M LópezMuñoz


"Wu Yinghui, Freddie" ha escrito:


> Joaquín M López Muñoz ha escrito:
> > * 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.
>
> Thanks for your helpful explanation. Since this types of warnings flood
> the compiler output, which very difficult for us to notice other more
> valuable warnings. Guess we'll need to figure out some way to "hide" the
> stupid compiler behaviour?

Can't you use #pragma warning(disable:4311) etc.? If I'm right,
you'll only need the pragmas when using /Wp64, not when actually
compiling in Win64 mode.

Best,

Joaquín M López Muñoz
Telefónica, Inevstigación y Desarrollo


>
>
> > * 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.
>
> Hmm... In this case, I guess I'd just try to add some default
> constructors for these classes without implementing them. That way, I
> can at least get away with this type of warnings.
>
> > So, Boost.MultiIndex must work in Win64, the best way to
> > check this out is to actually try.
>
> I do not have the 64-bit machine with me yet. But I'll report back later
> once I actually have the chance to try it out.
>
> > 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.
>
> Thanks for your insights!
>
> > Joaqu?n M L?pez Mu?oz
> > Telef?nica, Investigaci?n y Desarrollo
> >
> Cheers,
>
> Freddie
>
> --
> Wu Yinghui, Freddie
> Research & Development
> Software Engineer
>
> Volume Interactions Pte Ltd
> 1 Kim Seng Promenade, #12-01
> Great World City East Tower
> Singapore 237994
> Tel:   +65 62226962 (Ext 216)
> Fax:   +65 62226215
> Email: [hidden email]
> URL:   http://www.volumeinteractions.com
>
> Important:  This message is intended for the recipient(s) addressed
> above.  It contains privileged and confidential information.  If you are
> not the intended recipient, please notify the sender immediately by
> replying to this message and then delete it from your system.  You must
> not read, copy, use, or disseminate this communication in any form.
> Thank you.
>
>   ------------------------------------------------------------------------
>                        Name: signature.asc
>    signature.asc       Type: application/pgp-signature
>                 Description: OpenPGP digital signature
>
>   ------------------------------------------------------------------------
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users