Philosophical Question (End_Of_File)

Philosophical Question (End_Of_File)

[Wes Groleau]

We're taught to embed file input statements inside a control structure
with an End_Of_File test, right?

The idea is that instead of reading and then handling the exception, we
avoid the exception, right?

So why do some vendors implement End_Of_File something like this?

function End_Of_File (....) is
   begin
      Read_Without_Advancing;
      return False;
   exception
      when End_Of_File => return True;
   end End_Of_File;

I know of at least three that do this.  It can't be easier--somewhere
down in the lower level, the end of file had to be detected and the
exception raised.

Am I missing something?

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Philosophical Question (End_Of_File)

[Gautier]

Wes Groleau wrote:
(...)
> So why do some vendors implement End_Of_File something like this?

> function End_Of_File (....) is
>    begin
>       Read_Without_Advancing;
>       return False;
>    exception
>       when End_Of_File => return True;
>    end End_Of_File;

Mmmmmh interesting...
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 ?)
ex. @ http://members.xoom.com/_XMCM/gdemont/uza_html/unz_io__adb.htm#9_11

G.

Re: Philosophical Question (End_Of_File)

[Gautier]

> 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.

Re: Philosophical Question (End_Of_File)

[Pascal Martin]

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.

Re: Philosophical Question (End_Of_File)

[Robert Dewar]

In article <38A4799B.6D2E7ABE@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:

> We're taught to embed file input statements inside a control
> structure with an End_Of_File test, right?

Well who knows who teaches what. There are two ways of doing
things in Ada, choose the one that is most convenient. If you
are concerned with efficiency, measure which is most efficient
in your implementation and do it. This is something that may
easily vary from one implementation to another.

As to your worries about the internal implementation, I don't
understand, do you have some feeling that they are wrong or
inapropriate? If so why? One would assume that each
implementation uses the most appropriate approach.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Philosophical Question (End_Of_File)

[John English]

Wes Groleau wrote:
> We're taught to embed file input statements inside a control structure
> with an End_Of_File test, right?
> 
> The idea is that instead of reading and then handling the exception, we
> avoid the exception, right?

Sometimes you can't use End_Of_File reliably -- e.g. if you want
to read an integer from a file, End_Of_File may be false, but it
may become true in the process of skipping leading whitespace in
search of the start of the integer, so in this case you are forced
to use End_Error to detect the end of the file instead...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

CFP OOPSLA 2000

[Sherman Alpert]

Please forgive me if you receive this more than once;
there seem to have been problems with my mail server.
=====================================================
   
OOPSLA 2000 Call for Participation

        OOPSLA 2000
        October 15-19, 2000
        Minneapolis Convention Center
        Minneapolis, Minnesota USA

The ACM OOPSLA Conference (Object-Oriented Programming, 
Systems, Languages, and Applications) is the world's 
premier forum for object-oriented technology.
If you're involved in object technology, OOPSLA 2000 
is the place to be.

Submissions are solicited in the following categories:

RESEARCH PAPERS, TUTORIALS, PRACTITIONER REPORTS, PANELS
DEMOS, EDUCATORS' SYMPOSIUM, WORKSHOPS, POSTER SESSIONS
DOCTORAL SYMPOSIUM, DESIGNFEST, EXHIBITS

For more info, check out our Web site: 
    http://oopsla.acm.org

Important Dates
April 3, 2000:  Due date for Technical Papers, 
    Practitioner Reports, Educators' Symposium,
    Tutorial, Workshop, and Panel proposals, 
    and DesignFest problems
July 24, 2000:  Due date for Posters, Demonstrations, 
    Doctoral Symposium, and Student Volunteers