Christian Wendt wrote:
PG>> not "impossible"- you only got to reinvent the wheel and write to PG>> $b80000... _big_ loss in portability & comfort (no easy to call writeln. PG>Nevertheless this will remain my preferred method in BO5. The fastest PG>thing you can imagine on the DOS platform. hmm. is the type of "file" specified in the ISO /Extended? would it be possible to define it similar to TP/BP? there's a list of procedures inwith the file "record" - they specify the functions to init/flush/writebuffer/readbuffer (theoretical you could do the same with an object...)
I assume you mean BP's TFDD (Text File Device Drivers). BTW: It's for "Text", not for typed are untyped files (though there's actually no reason why it shoudln't apply to them, too, except that BP's doesn't).
Indeed, I'd like to have something like this in gpc, too. I'm not at all familiar with the internals of "Text" files (or other files) in gpc. (ISTR, it has something to do with "bindable" variables, but I don't know much about those, either.)
First a short explanation for those not familiar with BP:
Basically, TFDDs allow the programmer to assign procedures with the following semantics to a "Text" variable to be used instead of file I/O:
Open: Input: File mode (Reset / Rewrite / Extend (aka Append))
Read: Input: Buffer size Output: Actual size read (<= Buffer size); the value 0 signals an EOF -- but perhaps it would be better to have a separate EOF function (e.g. for things like serial ports that may have no data at one time, but get some data later). Data that were read (in the buffer)
Write: Input: Data in buffer Size
Flush: (the same as Write, except that it should additionally "physically flush the file", as far as that makes sense -- I can't remember any examples where this did anything different than Write)
Close: -
All procedures also have an "error code" as Output to signal un-/successful completion of the operation.
The TFDD can have a local data space (in BP: up to 16 bytes, AFAIR) -- local to the file to distinguish different "instances" of files assigned to a particular TFDD. (Here we see the similarities to objects...)
The big advantage is that one can do a Write[ln]/Read[ln] with all its possibilites and have the data automatically "piped" to certain routines.
Sure, one could achieve the same in gpc with WriteStr/ReadStr and passing the string to the routines, but
(a) it's not completely as easy (2 statements instead of one),
(b) managing the "local data" would require additional effort everywhere this is used,
(c) it's not TP compatible...,
(d) a TFDD can be used transparently (e.g. a variable assigned to a TFDD can be passed to any procedure that wants a "Text" file).
The particular syntax (and other things) BP uses for this is, IMHO, not very nice (it was introduced after the "good days" of Borland, but before the introduction of OOP, which could have simplified things), so I don't vote for copying BP's mechanism. But any way to do such things would be good. In fact, many of my units use TFDDs, and I can't see a "good" way of porting programs that use them to gpc (only perhaps with heavy use of the preprocessor, but I'd not like to do it like that). I'd not complain at all if it was done with OOP (i.e. "Text" would be an object type, the "procedure" above would be methods, the local data would be the fields of the object), the main thing is that the object could be used in simple Read[ln]/Write[ln] statements.
Any chances to do something like this with reasonable effort?