Customization in C++

described in the PT proposal are only tangentially relevant to this issue { the same problem would have arisen in dening a BStack100 directly { they do widen the impact of this limitation. A nal similarity between customization and PT lies in the extent to which both stretch the C-based separate compilation model up to, and probably past, its limits. While it may be possible to maintain the C model, both proposals would be best implemented under more sophisticated compilation management environments. [9] O. Madsen and B. Moller-Pedersen. \Virtual classes: a powerful mechanism in object-14 template <class T> T sum(template const Matrix<T>& m) { T s = 0; for (int i = 0; i < m.rows(); ++i) for (int j = 0; j < m.cols(); ++j) s += m.elem(i, j); return s; } This allows the code written for sum to be reused for matrices of any subclass of any Matrix class holding any numerical element type. There may be ways to introduce both customization and parameterization into C ++ that more seamlessly integrate the two concepts (as might possibly be done via an analog of BETA's \virtual classes" [9]). However, it is preferable to keep these mechanisms distinct: When you need one, having only the other doesn't help much. Since class templates generate several otherwise subtype-unrelated classes and/or subclasses simultaneously, they cannot be used to implement customization, or vice-versa, even both might rest upon the same internal compiler features. There is another mesh point between PT and the present proposal. The class template mechanism does not improve one security aspect of homogeneous container classes. Consider the following example: template <class T> class Stack100 { private: int sp; T data[100]; public: void push(const T& a) { data[sp++] = a; } T& top() { return data[sp-1]; } //... This implementation fails to meet one of the most important specications of a stack: Given any sensible denition of \equals", and ignoring the lack of error handling in the simplied implementation, it is desirable, for any legal argument a, that after s.push(a), s.top() should equal a. This property cannot hold when d is pushed in f5(). The problem is solvable via the exact qualier described above. If the member functions could be declared as void push(const exact T& t) and exact T& top(), then legal arguments 13 4 Customization and parametric types Many readers will have noted that customization addresses similar issues, settled …