Shiva writes:
>
> I am facing the following strange behaviour of the pascal 'READLN()' and
> 'READ()' functions on the MPE.
>
...
>
> Now I am observing some strange or unexpected behaviour of this small pascal
> program under the following instances of input file:
I have two rules about writing Pascal programs:
1) don't use Pascal I/O.
and, rule #2, which is very important if you broke rule #1:
2) *NEVER* use Pascal I/O!
Pascal I/O is terribly slow, and has a variety of problems ... I've seen
orders (yes, 100 times!) of magnitude improvment in some programs when
we dumped the Pascal I/O and replaced it with intrinsic I/O.
Suggestion...find the calls to READLN, and replace them with a procedure
call like "get_a_record". (I.e., "encapsulate" them, so there's only
a single READLN call in the source code.)
Then, change the READLN to an FREAD (or FREADDIR, if appropriate).
By encapsulating, you only have to change a few lines if you ever port
the code to another operating system ... and you've still avoided using
Pascal I/O.
Why doesn't C's I/O have the same problems as Pascal's I/O?
Partially because the C language *DOESN'T* have any I/O, any more than
SPL does ... instead, there is a library of routines (fopen, fread, etc.)
that are implemented as calls to the OS intrinsic routines. In MPE's case,
the mapping is pretty direct.
Pascal, OTOH, has I/O built into the language ... and it's pretty funky
I/O model. It was probably a good match for the teaching environment
it was designed in (and for) ... but not for the real world.
Note: on MS-DOS machines, I usually end up using Pascal I/O, but still
in an encapsulated manner ... so I can use DOS calls where possible
(instead of READLN, for example).
The general rules of programming (any language):
1) make it readable
2) try to avoid GOTOs, but don't be paranoid about it
3) don't use Pascal I/O
:)
--
Stan Sieler [log in to unmask]
http://www.allegro.com/sieler.html
|
