Tuesday, May 24, 2005

On generic programming

A software engineering notion, after its inception, goes through a serious of evolutionary stages towards its maturity as an abstraction. The path of maturity is paved with colorful implementation attempts. However, once the abstraction has matured, only science should draw the borders of its representation in the form of a linguistic construct. In particular, design limitations dictated by the underlying virtual machine is contrary to the principle of independence from technology.

The goal of a mechanism for generic programming is the availability of libraries of abstract data types and generic algorithms. The C++ template mechanism is an elegant linguistic design of the cumbersome procedure of using C header files. The C++ design is not dictated by a virtual machine. However, the design of an abstract language should not be polluted with implementation obstacles, either.

The issues of C++ templates, at times agonizing, are consequences of the requirement that the bodies of template functions accompany their prototypes. In a project comprising of multiple source files it is common to spend a long time resolving linkage errors by utilizing the C preprocessor defines. However, the requirement is due to implementation. The actual requirement is that the definition is visited prior to instantiation.

The requirement mentioned above cannot be further weakened though we will not discuss that in this note. The consequences are quite dramatic, though. It is possible to separate the definition of a class template from the implementation of the bodies of its methods. Thus, in a project one can have source files consisting of template definitions only, and other source files that use those templates, separately compiled.

The Z++ compiler uses the weaker requirement. It is not necessary to use the C defines in order to avoid generating duplicate symbol or undefined symbol linkage errors.