From:	Charles Krug <charles AT mail DOT pentek DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Still working on c++ std <limits> file . . .
Date:	Mon, 11 Jan 1999 10:19:29 -0500
Organization:	Pentek Corporation
Lines:	24
Message-ID:	<369A1681.BC8F2471@mail.pentek.com>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990110133010 DOT 20678O-100000 AT is>
NNTP-Posting-Host:	mail.pentek.com
Mime-Version:	1.0
X-Mailer:	Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language:	en
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Eli Zaretskii wrote:

> Why should you care about different types of a NaN?  Aren't these
> definitions related to how the FP environment is set up by the library
> startup code?  In other words, if the ``signalling NaN'' doesn't
> really raise any signal, should you care about its definition?

I realize that these are somewhat esoteric questions that don't come up
very often in my work, which is almost exclusively done with integers.  It
is however part of the C++ standard <limits> file.  If I'm generating a
standard conforming <limits> file, I need to know all about those
definitions in excruciating detail, so that someone learning c++ who is
using djgpp, and who is referred to the non-existing <limits> file, can
ask the question, "Hey, I can't find the standard <limits> file," and get
a better answer than, "use climits" which isn't what c++ texts are
referring to at all.

Since I use djgpp and have the knowledge, resources, and time required to
generate the standard <limits> file, which isn't all that difficult given
the correct set of definitions, it seems to me I should make one.


Charles

- Raw text -