Re: GCC 3.3.1, new warnings with <limits>

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