Re: Proposal for a (small) enhancement to the value() function.
CChris wrote:
> I just looked at be_execute.c in this respect.
>
> If getc() was defined as an inline function, you could remove this problem by
>
> * having a one char buffer for each open file (handle)
> * having getc() to update this buffer on each read
> * having one excess_read flag per file which says whether a character is to
> be physically read from the file if clear
> * causing Get() (or Get2() in my version) to attempt to back up using seek()
> if it reads a pure number in a file as a top level object, and set the above
> flag using a machine_proc() interface on failure to back up
> * if the excess_read flag for a file is set, getc() clears it and returns the
> buffered char, which was read in excess. Otherwise it behaves as usual.
> * having where() to adjust its return value according to the excess_read
> status
> for the requested file.
> * having seek() to clear the flag for the file for which it is called
>
> I am not sure whether the above can be done as getc() is a macro.
> And, even if it can be done, is it worth the effort, and is there any chance
> of a performance penalty in this sensitive area? I don't know C well enough,
> you probably have a clearer idea. And the final answer may depend on the
> compiler
> too.
I thought about adding an ungetc() several years ago,
but I didn't go ahead with it because:
- there would be added complexity and chance of subtle bugs
- Watcom had a bug in this area
- no one had ever asked for it
- there would be a tiny loss of performance
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
