Re: Integer Coersion

PJH wrote:
David, is that your surname or just a description of your debating style? I
actually pretty much agree with you about the byte thing. Coming to Fortran
from byte oriented languages such as Delphi, all this KIND thing seems very
odd - dare I say bordering on unnecessary 99.9% of the time. I could accept
it more readily if there were better "standard" mechanisms (like sizeof and
a BYTE type) available to work with both. Even being able to define types
based on minimum bit length would be an improvement.

However, "When in rome..." and as this is Fortran not Delphi, I feel I
should at least try to play by the local rules and produce code that is
vaguely standard conforming.

Paul Holden

ps
Someone around here is going to get hot under the collar with you for saying
that INTEGER(1) implies 1 byte, rather than INTEGER*1. I'm sure there
actully are some compilers out there that deliberately don't have a
KIND=BYTE equivalence.

It would be amazingly stupid of a compiler vendor to not support a byte-sized integer. It is a more natural method of solving many problems than some of the old hacks with characters. Fortran needs to begin defining a standard "system-programming" module of optional features to be supported based upon the specific system architecture.



David Frank wrote


Several points..
1. Your compiler (IVF) supports SIZEOF as do several others including my
CVF compiler.
2. Its amazing to me that people are bending their syntactic noses out of
shape to allow a memory byte
to be other than 8bits when cheap memory came on the scene and BURIED
those mfg's computers
models that didnt support it..
3. Since 2 is true, (ALL memory today is organized/addressed by hardware

as

8bit entities) it follows
that AFAIK no compiler being sold today doesnt recognize the 1 byte
integer declaration,

INTEGER(1) :: one_byte

and those that support quad precision (intel, ibm, et al) support bytes
as the de-facto standard for reals also

REAL(4) :: x
REAL(8) :: y
REAL(16) :: z

IOW, BYTES RULE!! screw those that try to jam KIND syntactic
horrors down our collective throats
ignoring the recent standardization of physical memory that has

occurred

SINCE F90 was first approved.





--

Gary Scott
mailto:garylscott@sbcglobal dot net

***** 5 Jan: Back from 7 days in Cozumel! *****

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages

  • Re: IVF vs CVF
    ... I would paraphrase part of it as: Microsoft didn't accept ... > Fortran for a lower price than CVF. ... > necessity for a commercial compiler. ... High quality compiler, good support, free email support within ...
    (comp.lang.fortran)
  • Re: Bugs at my web site
    ... >> I don't think it's being maintained now, but given that Fortran 77 isn't ... >what might prove fatal with a new compiler. ... >that I think they are good traditional fortran, whatever some standard might ... guess at heart I'm still a scientist rather than a Real Programmer :-) ...
    (comp.lang.fortran)
  • Re: new book: Guide to Fortran 2003 Programming (Brainerd)
    ... which looks at compiler support for the Fortran 2003 standard. ... but some people do seem to overlook that feature ...
    (comp.lang.fortran)
  • Re: Bugs at my web site
    ... what might prove fatal with a new compiler. ... that I think they are good traditional fortran, whatever some standard might ... I hope the g95 people, after taking a good long vacation to ...
    (comp.lang.fortran)
  • Re: Integer Coersion
    ... and as this is Fortran not Delphi, ... vaguely standard conforming. ... Your compiler supports SIZEOF as do several others including my ... to be other than 8bits when cheap memory came on the scene and BURIED ...
    (comp.lang.fortran)
Quantcast