Date: Mon, 14 Jul 2003 06:38:23 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-current@freebsd.org Subject: Re: GCC 3.3.1, new warnings with <limits> Message-ID: <20030714061544.I5570@gamplex.bde.org> In-Reply-To: <20030713183151.GA78045@dhcp01.pn.xcllnt.net> References: <20030712155333.GA79322@crodrigues.org> <BEDC8C48-B4DC-11D7-BE3B-0003937E39E0@mac.com> <20030713000559.28c18be6.kabaev@mail.ru> <20030713183151.GA78045@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 13 Jul 2003, Marcel Moolenaar wrote: > On Sun, Jul 13, 2003 at 08:23:54AM -0500, David Leimbach wrote: > > > > This is a good policy in general, however, one could easily argue that > > what > > is trying to be determined with signedness and such being > > less-than-compared > > to 0 isn't really a big deal and possibly the only way to implement this > > numeric_limits<T>::digits thing without any type introspection which > > C++ currently > > lacks. > > What about? > > #define issigned(T) (((T)(0)>(T)(~0)) ? 1 : 0) This is worse than any version that uses -1 instead of ~0, since ~0 gives implementation-defined behaviour. I think it can set trap bits. Anyway, the value of ~0 is unclear. I think it is -0 == 0 on 1's complement machines. Since its value is unclear, the result of converting this value to even an unsigned type T is also unclear. I think the above actually does work for the 3 representations in C99 iff ~0 has no trap bits, but this is unclear. These problems are avoided by using plain -1. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030714061544.I5570>