Fortran, which we're all familiar with, has a long history and is very well adapted to the core modeling activities that we often are involved in. On the other hand, it does date to the 1950's, and some things have been learned in the last few decades on how to build a general purpose programming language. Two of the key elements are abstract data types, and object orientation. Fortran 90 (which we is now available on the workstations and central systems) takes some steps in the direction of abstract data types. Object orientation is still left out of Fortran (and it isn't clear to me that it is even possible to add it without breaking some of the features which make Fortran efficient for the modeling).
Abstract data types are structures which the programmer, rather than the language, defines. One we could use is 'buoy report'. A buoy report contains certain types of information, all of which should remain associated with each other. In Fortran, I've kept the association by doing things like having a bunch of arrays (latitude, longitude, temperature, wind speed, pressure, ...) and using the same index to mean a given buoy. While this works, it does leave open the possibility that I've mis-typed an entry so that I've got latitude(j) and longitude(i), where i and j turn out to be different numbers. (Murphy's law being what it is, I've done exactly this.) With an abstract data type, I would be referring to buoyreport(j). Each element is then pieced together by the computer and I don't have to remember multiple indices. Much reduces the opportunity for errors (though, of course, Murphy will have his shots anyhow). It also means that in writing the program, I can use much more intuitive description and intuitive functional units. All of my data are in nice little packages, and I can define the packing to be as close as possible to how I think of the problem.
Object orientation takes this the next steps. The first step is, we package not just data units, but the operations that we routinely perform on those units. The major step is that once we've declared some object type, say a '2d grid', we can then create a new object type, such as a 'metric 2d grid', which will on creation be able to do all the things that the '2d grid' was able to do (we packed the operations in to the definition)! This is inheritance. In this example, 2d grid is just a 2d array of things - they may be numbers, they could be buoy reports, they could be model fields. The metric grid adds operations to locate i,j points in terms of latitude and longitude. More on this later.
Once these objects are created, if we've done the job correctly, any later user can use the objects without having to go in to the gore of how things are being done. This goes well beyond the Fortran notion of having a library of functions and subroutines. In Fortran (even in '90) if you wanted to locate the latitude-longitude of a point in a grid, you'd still have to know the full grid specification (standard latitude, standard longitude, location of pole in x and y, resolution in x and y, ...). With C++, you would request creation of a 1/16th Bedient mastermap object (call it x). If you then wanted the location of a point in that grid, you'd get it by asking for x.locate(ijpt). At no time do you need to know anything about the nature of the grid (even the fact that it is polar stereographic, much less what a Bedient grid is). The grid is an object, and the behavior of the object is specified by the library.
In the rest of the document, I'll go in to some more detail on how it is that C++ fills these roles, and what it is that is useful to us. A reminder is that if the primary operation is hammering on arrays of numbers, then Fortran is still the preferred language. If the problem, as it is for satellite data, involves mostly deciding what the data are that we're going to work with, and doing some relatively modest mathematics on them, then C++ is probably the better tool. I'll go in to detail later, but note that BUFR and GRIB messages are themselves objects. Much of our agony in dealing with them is that we're not treating them as objects.
The following sections are: abstract data types, objects introduction, objects and operators, object templates and inheritance, using the MMAB class library, and other considerations.