Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6158: Compilation error in numeric using gcc 4.6.1 on Solaris/SPARC
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-01-28 18:35:00
#6158: Compilation error in numeric using gcc 4.6.1 on Solaris/SPARC
-----------------------------------------------------------+----------------
Reporter: Ioannis Papadopoulos <ipapadop@â¦> | Owner: brandon.kohn
Type: Bugs | Status: new
Milestone: To Be Determined | Component: numeric
Version: Boost 1.48.0 | Severity: Showstopper
Resolution: | Keywords: solaris numeric gcc
-----------------------------------------------------------+----------------
Comment (by johnmaddock):
>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?
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6158#comment:5> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:08 UTC