Re: Two or three initial observations on the fp prining patch

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

Paolo Carlini <pcarlini@unitus.it> writes:

| Gabriel Dos Reis wrote:
| 
| > | Are you suggesting to re-add you patch?
| >
| > Sort of.
| 
| To be clear: I'm all for this, I agree that this would
| be the cleanest approach.
| 
| However, now that the numeric_limits<> issue has been fixed
| in another way, do you think that the compiler people will
| accept that kind of work, which has the "only" motivation
| of the fast float_to_char routines?

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.  

| You understand that this kind of work, touching the compiler,
| is something special for us, and *definitely* we must know at
| the outset if the final patch will be well received or otherwise
| we had better including tm.h ;) ...

Including tm.h would be the worst thing to do.