David Luff:

David Luff:

Attached is a patch to the airport data storage that I would like committed
after review if acceptable.  Currently the storage of airports mapped by ID
is by locally created objects - about 12 Meg or so created on the stack if
I am not mistaken.  I've changed this to creating the airports on the heap,
and storing pointers to them - see FGAirportList.add(...) in
src/Airports/simple.cxx.  I believe that this is probably better practice,
and it's certainly cured some strange problems I was seeing when accessing
the airport data with some gps unit code.  Changes resulting from this have
cascaded through a few files which access the data - 11 files are modified
in all.  Melchior and Durk - you might want to test this and shout if there
are problems since the metar and traffic code are probably the biggest
users of the airport data.  I've also added a fuzzy search function that
returns the next matching airport code in ASCII sequence in order to
support gps units that have autocompletion of partially entered codes.

More generally, the simple airport class seems to have grown a lot with the
fairly recent addition of the parking, runway preference and schedule time
code.  It is no longer just an encapsulation of the global airport data
file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!).
 My personal opinion is that we should look to just store the basic data in
apt.dat for all global airports in a simple airport class, plus globally
needed data (metar available?), and then have the traffic, AI and ATC
subsystems create more advanced airports for themselves as needed in the
area of interest.  Once a significant number of airports worldwide have
ground networks and parking defined, it will be impractical and unnecessary
to store them all in memory.  That's just a thought for the future though.