The use of AST_ANNUL () is not completely
foolproof, however. Consider the following:
CALL AST_SHOW( AST_ZOOMMAP( 2, 5.ODO, ' ', STATUS ), STATUS )
This creates a ZoomMap and displays it on standard output
(). Using function invocations as
arguments to other routines in this way is very convenient because it
avoids the need for intermediate pointer variables. However, the
pointer generated by AST_ZOOMMAP is still active, and since we have
not stored its value, we cannot use AST_ANNUL to annul it. The
ZoomMap will therefore stay around until the end of the program.
A simple way to avoid this problem is to enclose all use of AST routines between calls to AST_BEGIN and AST_END, for example:
CALL AST_BEGIN( STATUS ) CALL AST_SHOW( AST_ZOOMMAP( 2, 5.ODO, ' ', STATUS ), STATUS ) CALL AST_END( STATUS )
When the AST_END call executes, every Object pointer created since the previous AST_BEGIN call is automatically annulled and any Objects left without pointers are deleted. This provides a simple solution to managing Objects and their pointers, and allows you to create Objects very freely without needing to keep detailed track of each one. Because this is so convenient, we implicitly assume that AST_BEGIN and AST_END are used in most of the examples given in this document. Pointer management is not generally shown explicitly unless it is particularly relevant to the point being illustrated.
If necessary, calls to AST_BEGIN and AST_END may be nested, like
IF...ENDIF blocks in Fortran, to define a series of AST pointer
contexts. Each call to AST_END will then annul only those Object
pointers created since the matching call to AST_BEGIN.
AST A Library for Handling World Coordinate Systems in Astronomy