GCC 3.3.1, new warnings with <limits>
David Leimbach
leimy2k at mac.com
Sun Jul 13 06:24:53 PDT 2003
On Saturday, July 12, 2003, at 11:05PM, Alexander Kabaev wrote:
> On Sat, 12 Jul 2003 23:13:12 -0400
> Craig Rodrigues <rodrigc at crodrigues.org> wrote:
>
>> I am guessing that the C preprocessor does not think that it is
>> in a system header, and thus prints out the warning.
>
> We specifically disable automatic warning suppression for system
> headers, because we _want_ to know about them. Your Linux distribution
> apparently does not care.
>
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.
The following would work for example in a template function:
template <typname T>
void foo(T const & f)
{
if (numeric_limits<T>::digits % 2)
//type is signed
else
//type is unsigned
}
However to implement "digits" we have that nasty macro that makes the
comparison
which is meaningless for unsigned types of "< 0".
This is probably a perfect example of where the C++ standards committee
folks should
be queried about the best way to implement numeric_limits<T>::digits.
Some of them
have had no trouble pointing out that C99's tgmath.h header cannot be
implemented in
pure standard C99. This may also be true of numeric_limits<T>::digits.
I am going to the newsgroups... My old college advisor is/was a
moderator on
comp.lang.c++.moderated and he may "just know" the answer :).
>>
>> Any GCC/FreeBSD expert care to comment? ;)
>>
> Short of fixing offending files in FSF libstdc++ or turning warning
> suppression back on for standard C++ include files selectively, I have
> no suggestion.
I'd rather we fix the problem in gcc but this extra verbosity when
there is nothing
wrong with user code also seems incorrect. I think the gcc developers
should have a
separate command line option for internal headers don't you?
>
> --
> Alexander Kabaev
More information about the freebsd-current
mailing list