The cpp paradox
Abstract :
CPP is the C preprocessor. For most researchers this is a tool of the past. For most practitioners it is a tool from the past but one which is currently used. The heavy use of CPP can lead to unreadable programs; nevertheless large amounts of code are written using it. CPP makes maintenance difficult, but CPP is largely used for maintenance... CPP can convert good programs on which many program understanding tools apply, to incomprehensible programs with no tool assistance... The presence of CPP constructs in programs is a headache for maintainers and for tools builders, and CPP is still here... CPP provides low level mechanisms typically used for different purpose. Research efforts have led to a clarification of notions like modularity or versioning and propose tools supporting them. However CPP is still widely used, sometimes in conjunction with such tools, but is poorly integrated.Most software engineering researchers consider CPP as an uninteresting tool of the past but, when implementing their research prototypes, they turn into practitioners and use it.
This introduction is controversial. The aim of this paper is to present what lies behind these paradoxes and assess what should be done. In fact here CPP is taken as a scapegoat. While some cpp specific features are taken into account, a large proportion of this discourse is more general. Such paradox are representative of other distinctions: Industry vs Research, State-of-the-practice vs State-of-the-art, Maintenance vs Development, Reengineering vs Engineering.
Programming-in-the-large vs Programming-in-the-small
The distinction introduced by De Remer and Kron in “Programming-in-the-large vs Programming-in-the-small” [Der76] is also relevant here. They argue that programming languages are well suited to describe algorithms but not to describe the structure of complex versioned software products. Since then, the separation of concerns between Programming-in-the-large (PITL) and programming-in-the-small (PITS) has been considerably reinforced and the corresponding research lines have evolved in parallel. This distinction usually implies a granularity step. For instance, PITL tools typically see files as elementary values without considering their contents. Conversely, programming languages deal with instructions, integer and character values and usually do not provide support for versioning.
As shown in this paper, the C preprocessor is a pragmatic tool which bridges the gap between PITS and some aspects of PITL. On the one hand, CPP has been designed by PITS practitioners and is itself a (degenerated) programming language. On the other hand CPP tries to partially solve some of the PITL problems, like modularity, versioning and configuration issues.
Content of this paper
Section I presents CPP from the State-of-the-practice point of view and gives answers to such questions as: Why to talk about CPP? What mechanisms are provided by CPP? How, when and why are they still used in practice? What is wrong with CPP?
CPP is then considered from a reengineering point of view. Section II answers questions like: What is Reengineering-in-the-large? What to do with cpp files? What techniques can be applied?
