In a recent article Bjarne Stroustrup presented the evolution of C++ toward the 0X standard, and asked the C++ community for ideas regarding C++ enhancements. This is a proposal to add to C++ support for rational metaprogramming.
A number of sources, notably Alexandrescu in Modern C+++ Design (Addison-Wesley, 2001), and Czarnecki and Eisenecker in Generative Programming (Addison-Wesley, 2000), have used the C++ template facility for creating elaborate program constructs that are evaluated at compile time. These constructs are valuable, but are difficult to write, read, understand, debug, and reason about. The power of metaprogramming could be made accessible to a wider audience by allowing the compile-time execution of some C++ constructs to support the existing metaprogramming paradigm (nothing more) using a rational syntax.
The rational metaprogramming facility could include support for integer
and type variables, functions, conditionals, and loops. The existing
C syntax for writing imperative code should probably be retained.
A separate keyword (for example compile_time
) would mark a function as one
returning a compile-time constant or type. The generation of compilable
code should probably be left to the existing template mechanism.
One problem with this proposal is deciding what C/C++ facilities to
include in the metaprogramming language. Would perhaps arrays be useful?
How about lists, or a way to create graphs?
A different approach would be to allow metaprogramming to be performed
using the complete C++ language (apart from rational metaprogramming). To
make programs more readable metaprogram code and data could be
introduced with a special keyword (for example compile_time
), or
be placed in different compilation units. The first phase of the
compilation would compile the metaprogram code. During the second
phase of the compilation the compiler would process C++ code containing
calls to metaprogram functions returning a type (probably type_info
)
or a constant, by dynamically loading and calling the function compiled
during the first phase.
For the second approach to work the RTTI system should be augmented with
methods to construct new types out of type_info
elements (for
example pointer_to(type_info))
, and to analyze existing types
identified by a type_info
into their constituent elements.
Alternatively, types could be manipulated as strings. The existing
type_info.name()
method specification should be tightened to
allow metaprogrammers know exactly how types are represented in string
form, and a type_info(String)
constructor should allow
types to be constructed out of strings.
Last modified: Wednesday, July 20, 2005 1:19 pm
Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.