Boost C++ Libraries: Ticket #6158: Compilation error in numeric using gcc 4.6.1 on Solaris/SPARC

attachment set

ipapadop@… — Tue, 29 Nov 2011 19:27:34 GMT

attachment → cstdint_patch.diff

cstdint.hpp patch for Solaris 10.0/gcc 4.6.1

tsandnes@… — Tue, 20 Dec 2011 13:57:03 GMT

I am seeing the same thing on windows 7, mscv100.

The error is slightly different:

error C2766: explicit specialization; 'boost::numeric::numeric_cast_traits<char,uint64_t>' has already been defined C:\svn\Backend\third_party\win32_vc100\include\boost\numeric\conversion\detail\preprocessed\numeric_cast_traits.hpp 263

Changing from using::int8_t to typedef signed char int8_t; as in the patch for solaris solves the problem here as well. Maybe the patch should be modified to change this for windows7/msvc100 too?

owner changed

John Maddock — Sat, 28 Jan 2012 12:25:32 GMT

owner changed from Douglas Gregor to Brandon Kohn

IMO this is the wrong fix: our code should make no assumptions about the actual type of uintXX_t etc.

IMO the preprocessed headers are just plain wrong - you can't mix concrete types (char short etc) with typedefs (intXX_t) because you're just asking for problems with duplicate specializations. It has to be all real types throughout.

BTW in addition to the two platforms mentioned above, this is also broken for Sun on Linux.

Reassigning to the person who made these changes...

Brandon Kohn — Sat, 28 Jan 2012 15:06:31 GMT

I'll have a look at making these use the fundamental types. As a workaround you can use the following macro to disable these definitions:

#define BOOST_NUMERIC_CONVERSION_RELAX_BUILT_IN_CAST_TRAITS

anonymous — Sat, 28 Jan 2012 15:32:10 GMT

I think the proper way to solve this is to have a single set of typedefs with the guarantee that those types/typedefs uniquely cover (disjointly) the range of fundamental types on each platform. I had naively assumed this was the case with the cstdint defs. I threw the char one in after a discussion on the mailing list which informed me that char/signed char/unsigned char were always 3 distinct types according to the standard. I suppose the most pragmatic way forward will be to define a sequence of types for each platform (with common ones rolled into sets), and then use those to generate the specializations.

John Maddock — Sat, 28 Jan 2012 18:35:00 GMT

I think the proper way to solve this is to have a single set of typedefs with the guarantee that those types/typedefs uniquely cover (disjointly) the range of fundamental types on each platform. I had naively assumed this was the case with the cstdint defs. I threw the char one in after a discussion on the mailing list which informed me that char/signed char/unsigned char were always 3 distinct types according to the standard. I suppose the most pragmatic way forward will be to define a sequence of types for each platform (with common ones rolled into sets), and then use those to generate the specializations.

I don't think that would work - besides the complete range of types are those given in the C++ standard:

char, unsigned char, signed char, short, unsigned short, int, unsigned int, long unsigned long.

Plus only if BOOST_NO_LONG_LONG is not defined: long long and unsigned long long long.

True there may be other compiler specific types hidden away - MS has __int8 __int16 etc which may or may not be distinct types depending on the compiler version. But I assume that the default template instantiation can cover any extra compiler specific types?

anonymous — Sat, 28 Jan 2012 19:14:14 GMT

Yeah, what you propose is how I am handling it.

status changed

Brandon Kohn — Sat, 28 Jan 2012 20:02:56 GMT

status new → assigned

Brandon Kohn — Sat, 28 Jan 2012 20:03:48 GMT

A fix is up in the trunk. Please test on those platforms at your earliest convenience.

Randy — Tue, 31 Jan 2012 00:05:51 GMT

I had the same problem. I can confirm that it at least compiles now (with your fix, brandon.kohn).

rakesh@… — Sat, 04 Feb 2012 15:41:09 GMT

Works for me with GCC 4.6.2 on OpenIndiana.

status changed; resolution set

Brandon Kohn — Mon, 27 Feb 2012 14:49:18 GMT

status assigned → closed
resolution → fixed

The fix is in the 1.49 release.