Re: V3 PATCH: numeric_limits<> support, fix PR/3865

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Neil Booth <neil@daikokuya.co.uk> writes:

| Gabriel Dos Reis wrote:-
| 
| > It predefined several data type precision we're trying to second-guess
| > or having duplicated configuration files for.  When compiling C++, it
| > also predefined __WCHAR_UNSIGNED__ based on the fact that wchar_t (a
| > distinct type in C++) is unsigned or not.
| 
| I just worry about the vast number of new macros you're defining.

Hi,

  I understand your fear, however I'm trying to minimize the amount of
information we need from the compiler.  Trying to duplicate
configuration files has proven to lead to all kinds of known errors.
It is far better to keep the information in one place and have it
propagated in a scalable and sensical way.  See a message from Matta
Austern for example.

|  Are
| they going to be enabled only for C++ so C doesn't have to carry the
| baggage?

The __WCHAR_UNSIGNED__ sign is defined only in C++ as explained.
However other information about type precision and floating point
format as defined both in C and C++.  Why do you think they are
unnecessary in C? For proper floating point support in C99 and C++
(i.e. without mismatch), both languages library supports have to share
the same information.

|  Are they really necessary (e.g. how does Dinkumware handle
| it since they don't control a compiler)?

I don't know how Dinkunware implements data format on the varieties of
plateforms GCC supports.  

| Signedness of wchar_t is easily tested with if () or #if, for example;
| a macro is quite redundant.

wchar_t is a keyword in C++, how do you easily test its signness with
if(0 or #if at compile-time and having that information in accordance
with the compiler's own idea?

-- Gaby