Fri, 19 Feb 1999 14:57:32 -0800
I'm not sure exactly what you mean by "persistent data capabilities",
but I think you are talking about variables that retain their values
between program executions. If so, here is my answer. (If not, don't
bother to read any further.)
I maintain software that can be considered to be a very special air
traffic control system. (It isn't, really, but that's the best way I
can describe it.) The users can create customized windows that allow
them to view the aircraft positions, and certain other things, however
they want. They can store these custom designed layouts for future use.
The layouts are available even after they have exited the program and
re-booted the computer. Of course, these layouts are stored in files.
The trick is to give the various files unique names. I do this by
embedding a serial number in the file name. So, I need a serial number
generator that remembers the last serial number used.
The Ada package specification is something like:
package NEXT_SERIAL is
function Number return string;
The program then creates filenames something like this:
FILENAME : constant string := "filename" & NEXT_SERIAL.Number &
The package body of NEXT_SERIAL simply opens a file that contains a
single integer, increments it, creates a string (without a leading
blank) from the new value, writes the new value back to the file, and
returns the string.
My particular application is on a network where the user can run the
program from one of several consoles. All the consoles remember his
preferences, regardless of which console he used last. That's because
the body of NEXT_SERIAL doesn't really open a file. The body I actually
use in that application opens a TCP/IP connection to a server, which
maintains the file, and sends the value back to the client. One of the
beauties of Ada is that I was able to go from the stand-alone prototype
to the network version of the program simply by changing the NEXT_SERIAL
Phil Johnson wrote:
> Is there a Ada-specific method to add persistant data capabilities
> to an application?
> Any hints or comments are welcomed.
> Phil Johnson
> Phil Johnson
> [log in to unmask]