Re: [F77] storing bytes data
From: Gary Scott (gary.l.scott_at_lmco.com)
Date: 04/21/04
- Next message: glen herrmannsfeldt: "Re: Function pointer as function parameter"
- Previous message: Jugoslav Dujic: "Re: Modules and shared libraries"
- In reply to: Richard Maine: "Re: [F77] storing bytes data"
- Next in thread: Ken Fairfield: "Re: [F77] storing bytes data"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 21 Apr 2004 07:11:34 -0700
Richard Maine <nospam@see.signature> wrote in message news:<m2isfuglbh.fsf@vega.avradionet.com>...
> "Gary L. Scott" <garyscott@ev1.net> writes:
>
> > Richard Maine wrote:
>
> >> I *DO*
> >> know of current full-language compilers that don't allow representation
> >> of 256 different values in default character.
> >
> > Why would they do that?
>
> Beats me. I'm reporting the facts. I can certainly speculate
> about reasons, but speculation is all it would be. For example,
> maybe limiting values to the 0-127 range (which I think is what
> happened) keeps you from indexing out of range into some tables.
> Or I could imagine other things as well. But all of them are
> speculation. I'll stick to the facts, 2 of which I consider
> relevant here:
>
> 1. The standard doesn't require it.
>
> 2. Not all compilers do it.
>
> P.S. If you think you can always stick any bit pattern in any data
> type without fear of problem, your experience differs from mine.
Absolutely fully understand that. It simply flies in the face of what
a reasonable user would consider an acceptable design. It is fine if
there is some hardware quirk for example on some particular system
that prevents a design which would allow the user full ability to
control the values of a particular data type. In absence of such
legitimate restriction, I expect that the ability of the user to fully
control the value setting of any data type to be a top priority design
goal. (designing an index table with a limit of 127 just because you
don't want to mess with unsigned integers or some other method of
extending the range is a non-starter). Not all code that I write
requires or is even possible to write portably. I write those
portions that can be done so portably, however, unless I am unwilling
to accept a resultant performance hit. That's one reason I use GINO
for the GUI (improved portability). Everyone needs to realize however
that the vast majority of code written today is non-portable because
it is highly tied to operating system capabilities/APIs. I am all for
striving for portability, but absolutely not at expense of not
providing fundamental capabilities which fully exploit the particular
hardware target. I am always willing to explore better methods of
accomplishing a task so long as I get to choose whether any
performance penalty is acceptable or not.
> Try
> to stick a signaling NaN bit pattern in a floating point variable and
> watch the fun. That was from a discussion earlier today on the J3
> list, but it brings back recollection of days long ago. Seems to
> me that I recall having to worry about whether I used integer or real
> variables for my Hollerith data on some f66 machines because of
> some such issues. I'm vaguely recalling a problem with integer on
> the IBM 1130, but the recollection is to vague for me to be confident
> of it. Could have been another machine; my understanding of the
> problem could have been completely wrong, etc.
>
> In practice, as mentioned several times before in this thread,
> you *CAN* stick any bit pattern in an integer. That's what makes
> integer a really good choice for such things.
- Next message: glen herrmannsfeldt: "Re: Function pointer as function parameter"
- Previous message: Jugoslav Dujic: "Re: Modules and shared libraries"
- In reply to: Richard Maine: "Re: [F77] storing bytes data"
- Next in thread: Ken Fairfield: "Re: [F77] storing bytes data"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
