Re: Integer Coersion

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.


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.


.

Relevant Pages

  • 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: allocatable non-dummy local variables and pointers to them
    ... must release the memory used by a process when the process terminates. ... I do remember that Fortran Powerstation 4.0 did have a memory leak ... digging to find whether it claims to be an f90 or f95 compiler. ... compiler has to behave for allocatables that get undefined allocation ...
    (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: ARM/Linux: Is this a cross-compiler bug? ¡]memcpy doesnt work as expected)
    ... memory by casting a pointer from A to B. The compiler is ... pointers point to different memory. ... What the standard says is not relevant. ...
    (comp.arch.embedded)
  • Re: [patch] spinlocks: remove volatile
    ... >> memory or whatever. ... The compiler CALLS the assembly code. ... Don't like the standard? ... Not just the nearest bus. ...
    (Linux-Kernel)