On Oct 15, 5:00pm, John Bray wrote:
> Subject: Re: F90 and Purify
> We made the active decision to not check ALLOCATE and DEALLOCATE
> status because HP Nag and Cray compilers did report the problem
> line properly, and the error trapping approach caused too much
> output, especially in MPP situations. For routines allocating
> 50'odd variables in a strucuture, error calls for every ALLOCATE
> makes the code very bulky, and a GOTO a single error trap point
> just tells you one of the allocates failed, not which.
...
Well, this is partly a matter of taste and style and partly one
of differing utility in differing contexts.
The only negative you cite is code bulkiness, and indeed this
is something I put up with. Probably half my lines of code
involve checking for error conditions of one kind or another
-- not just this sort of thing, but also sanity-checks on user
input, checks for bounds overflows of statically allocated
arrays filled from user input, etc. My personal experience
is that for my apps, which are used by thousands of people
who don't have source code and which I have to support when
they have problems, it's well worth it.
I even have a "verbose" mode which I can set on startup that
allows me to track each allocation with an informative message;
what could be done with a single ALLOCATE statement ends up
looking like this:
SUBROUTINE derivs_alloc( ... )
...
msg = 'derv1'; nword = nderv1
ALLOCATE( derv1(nderv1), STAT=status )
IF( status .NE. 0 )THEN
GOTO 900
ELSE IF( verbose )THEN
WRITE( iwrit, '(A,2I8)' ) &
& 'derivs_alloc: derv1 ALLOCATEd to SHAPE= ', &
& SHAPE(derv1)
ENDIF
...
RETURN !!! normal return
900 CONTINUE
error = .TRUE.
WRITE( 6, '(3A,I20)' ) &
& 'derivs_alloc: could not ALLOCATE ', &
& TRIM(msg), '; size= ', nword
END
Of course, the calling routine checks "error", sees that it
is .TRUE., and prints its own name with another message, etc.
This sort of thing has saved my bacon so often that I find it well
worth it; also, much of it is boilerplate that I can enter in
my sleep (at least if I'm having a bad dream :-) ) or else that
can be copied and altered. And I'm sufficiently used to reading
code written according to this convention that I can quite easily
filter out the boilerplate and focus on what is going on underneath.
Again, that's just me, and I'm offering this as an example what
I do, not what anybody else should do.
I think some of the proposals for better error handling are designed
to allow this degree of checking in a less verbose fashion.
-P.
--
*** "Freedom's just another word for nothing left to lose." (B. Yeltsin)***
*Peter Shenkin; Chemistry, Columbia U.; [log in to unmask] (212)854-5143*
*MacroModel WWW page: http://www.columbia.edu/cu/chemistry/mmod/mmod.html *
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
