Kurt writes:

> about the Pascal I/O performance, nobody however addressed the problem
> described: is Pascal/XL 'readln()' and 'read()' NOT ABLE to read textfiles of
> records longer than 254 bytes???

True...because it's a "why bother" ... as in,  I can't tell what color
the dog that's biting me is.   Why bother?  Get away from the dog!


> With Pascal I/O I can write:
>
> Do
>    stringA := ....; stringB := .... ; ....  StringZ := ... ;
>    ....
>
>    writeln(stringA, stringB, stringC, ..... ,stringZ) ;
> until .... ;

And you can't properly handle errors, either.   Your program either
quietly ignores them, or aborts.  (Errors like: more data entered than
the string can hold, or the output file filled up.)

> To the performance guru's: how many lines of codes do you
> need to program the equivalent of the writeln statement  using 'fwrite's?


> How much MORE time do you need to program and to test your code?

Far, far, far less time!   If you examine the example I posted, you
see "fmti", "spout" ... I have used these (or variations) in
many languages (ALGOL, C, Pascal, SPL, SPLash!, Java) for 26 years ...
I don't have to think "how can I do the equivalent of a FORTRAN I4
format in the current language" ... it's just "fmti (xxx, 4)".

I don't have to write in-line code (perhaps using Pascal's strwrite
plus string functions) to do a "I4, but emit blanks if the value is 0" ...
I use fmti (xxx, 4 + fmt_blank_if_zero)   (not shown in example code)

Pascal has very little formatting to speak of...do you want
left-justified numbers?  Leading 0?  Zero-suppressed?  Hex? Octal?
...tough luck.

Also, note the support problem apparent in the original question ...
Pascal built-in I/O is generally not robustly defined, so supporting
it can be a nightmare (as we've just seen!).

> How much is the increase in cost for your company? And, finally, ...

Net savings...not an increase in cost.

> how many readln() can your CPU execute until the additional CPU cost
> becomes higher than the additional programming costs?

A very good question...and one I've asked a number of times about various
things I've spotted in people's code over the years.

For readln(), the answer is easy:  1.

readln simply has a very high support cost ... the question of what
happens when unexpected input is provided, or I/O errors occur,
or input is redirected, is so large that it just makes it too risky to use
...and that's without considering performance!

> ... and what about program readabilty and maintenance, maybe years later,
>   by a different programmer?

I'd rather have a standardized package used across several languages
in my company, so that programmers moving from C to Pascal don't
have to say "hey, I don't remember...does READLN "eat" a carriage
return"?   Instead, they call get_a_line or get'a'line or something,
which has well defined semantics.

BTW, using language-based I/O instead of intrinsic I/O was the basis
of the most expensive mistake I've ever seen.

A programmer was using FORTRAN I/O (with format statement) to read
data from a punched cards ... the data was supposed to be all "1" and "0"
characters (no blanks!).  The card reader dropped a column, shifting
everything left 1 character ... but FORTRAN I/O said "blank, I'll treat
that as "0"" ... so the program wasn't aware of the problem, and thousands
of ROMs were made incorrectly.

OTOH, anecdotes don't matter ... for any given question, you can almost
always find anecdotes that support either side of the question!

It's the overall results that count ... and I've seen the best results
gained by ignoring language-provided I/O, and using intrinsic-access
via encapsulated routines.

Why?

Performance, Power, Portability.

It's just that simple.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html