PLplot has a fairly complex C API. There are lots of functions, and several facilities have multiple entry points with similar names but different argument lists. (Think contouring, shading). Often these differing argument lists are to accommodate a variety of data storage paradigms, one of which you are expected to be using!

Especially in the case of the 2-d API's for contouring and shading, sophisticated C++ users may feel a special sense of exasperation with the data layout prescriptions, since they are extremely primitive, pointer rich, and prone to a wide class of memory leaks and other sorts of programming errors. Many C++ users know good and well that better ways exist (templated matrix classes, etc), but historically have not been able to use these more sophisticated techniques if the contained data ever needed to get plotted.

Besides the 2-d API functions, there is also the multiple output stream capability of PLplot. Anyone who knows C++ well, and who has used multiple output streams in PLplot, has probably noticed striking similarities between the PLplot PLStream pointer and the C++ this pointer. Although multiple output streams have not been widely used in PLplot applications in the past, the availability of the plframe Tk widget, and the extended wish concept, is making it much more attractive to use multiple output streams.

Unfortunately, if you do write a Tk extended wish application, and endow your interface with multiple plframes, the event driven character of X applications makes it difficult to ensure that PLplot output shows up in the right plframe window. If a plot is generated to one plframe, the PLplot PLStream pointer is directed to that stream. If a user then pushes a Tk button which should generate a plot to a different plframe, the plot goes to the old plframe instead! Schemes for controlling this can be imagined, but the logic can be complex, especially in the face of the ability to /also/ make plots to the same plframe from either Tcl or C++.

Beyond this, the C API is downright "ugly" for a significant number of the functions, particularly those which return values by accepting pointers to variables in their argument lists, and then changing them in that way. Sophisticated C++ users generally take considerable pride in banishing the offensive bare pointer from their code, and consider it disgusting to have to insert &'s just in order to make a call to an API function.

In order to address these issues (and more), I have begun constructing a C++ interface to PLplot. The purpose of this missive is to describe its architecture and usage.