Re: Philosophical Question (End_Of_File)

[Pascal Martin <pascal.martin@iname.com.nospam>]

In article <38A4A341.7F7ACDCF@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> wrote:
>> BTW GNAT that doesn't do so (in Direct_IO, 3.11) is *much* faster
>> with simple loop within a begin..exception..end block than with
>> "while not End_Of_File loop" (maybe because both End_Of_File and Read
>> do check file status ?)
> 
> NB: the Manual (A.8.3(4) and so) forces the Read procedure to raise End_Error
> if one is after the end of the file - thus this exception can be trusted,
> can't it ?
> The efficiency (in terms of speed) of the End_Of_File implementations
> you've seen is another debate. But in the ((End_Of_File test), Read) pair
> it could be not so bad. Surely it has been studied to death...
> 
> G.

That remind me of something: when I was working on porting an Ada IO
runtime to VRTX, we had many similar problems. The Ada runtime was
built in a somewhat similar way as the original posting's code:

    if something_prevent_me_from_doing_it then
        raise the_appropriate_exception;
    else
        do_it;
    end if;

Sounds like the perfect software engineering way of doing it. The problem
was that VRTX gave us no clue if we could or could not do it. So we ended
with the following logic:

   do_it;
   undo_it;
   if error then
      return false;
   end if;
   return true;

We found no other choice. By chance the impacted operations was open() and 
friends, not get(), so the performance hit was not significant. My own conclusions was
the hell software engineering, if performing the operation is not going to kill someone,
let try and then catch the error, if any. Kind of play to win, rather than betting heavily
on failure.

In a few words: go forward, read on, and catch the exception.

------------------------------------------------------------------
Pascal F. Martin.