Two or three initial observations on the fp prining patch

[Paolo Carlini]

Gabriel Dos Reis wrote:

> At the time I added the various endianness flag, the idea was to
> support numeric_limits (and more). The numeric_limits issue was
> solved differently and elegantly. I appreciate that. But the new
> numeric_limits implementation does not solve the endianess problem.
> That ought to be understood.
>
> And, anyway, there are suggestions on the C++ Evolution Group list to
> have support for system programming that includes those kind of stuff
> (alignment, endianness), and my guess is that it is a suggestion on
> good track/ I.e., there is a high chance that it gets its way through
> C++0x.
>
> I do think that a compiler should be built to support language usage
> (i.e. programnmation, library implementations , ...), not just for the
> sake of the beauty of the implementation. This endiann thingy does
> have direct relevance to how we do organize and implement libraries.
>
> In short, the endianness thingy is not "only" for supporting
> numeric_limits as described in C++98 or C++03. It goes beyond that.

Ok, thanks for the explanation!||

Therefore, to recap, we shall follow the predefined macros approach.

We already have |__SHRT_MAX__, ||__INT_MAX__ and so on for the integer 
types,|
|therefore, basically, we lack: floating point endianness and 
floating-point|
|format. I would try to extract and update those bits from your original|
|patch, this seems feasible.

However, basing on your explanation above, I wonder if something more
general, including integer endianness and so on, would be better...

Perhaps you should just propose again to gcc-patches your patch with the
new motivations?!?
|||
|Thanks again,|
|Paolo.|