Re: Another PL/I cant
From: James Giles (jamesgiles_at_worldnet.att.net)
Date: 08/28/04
- Next message: James Giles: "Re: Writing a Fortran parser..."
- Previous message: James Giles: "Re: Numeric leak"
- In reply to: David Frank: "Re: Another PL/I cant"
- Next in thread: Rich Townsend: "Re: Another PL/I cant"
- Reply: Rich Townsend: "Re: Another PL/I cant"
- Reply: David Frank: "Re: Another PL/I cant"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 28 Aug 2004 20:29:29 GMT
David Frank wrote:
...
>>> read (hex,'(<len(string)>z2)') (string(i:i),i=1,len(string))
>>
>> ! 1. Non standard format < .. >
>
> One of the VAX extensions that predates the current standard by many years
> and is supported by leading compilers, but not by a compiler choice made by
> ignorant Fortran losers.
I did have a standard conforming way to write something like
that, but CVF now fails to compile it:
read (hex, '('//len(string)//'x2)') ...
I overloaded the // operator so that when used mixed mode with
integer expressions and character expressions, it generates an
character form of the integer value and concatenates that. It's
superior to the non-standard VAX extension in several ways,
most importantly it works everywhere, not just in I/O statements.
But, CVF fails to compile it. CVF is a defunct product. HP accepts
bug reports on it, but I don't think they fix any. Intel has all the
CVF support staff, but I don't think they fix CVF bugs any more
either.
In any case, the VAX extention does not (I hope) predate any
standard feature. It's too limited in where you can use it and
has some very peculiar end-cases. Something more general
is preferable (like my oveload of //, which is already standard
if CVF only complied).
-- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
- Next message: James Giles: "Re: Writing a Fortran parser..."
- Previous message: James Giles: "Re: Numeric leak"
- In reply to: David Frank: "Re: Another PL/I cant"
- Next in thread: Rich Townsend: "Re: Another PL/I cant"
- Reply: Rich Townsend: "Re: Another PL/I cant"
- Reply: David Frank: "Re: Another PL/I cant"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|