eneric containers and algorithms often impose certain restrictions on the objects that they manipulate. For example, the std::sort() algorithm requires that the elements on which it operates shall define the However, not all constraints can be expressed and enforced that easily. More abstract constraints such as "must have a base class" or "must be a POD type" require more code maneuvers and resourcefulness from the programmer. The following sections will demonstrate how to implement such constraints in a generic fashion. Presenting the Problem The above are all POD types. However, the following aren't: Several programming idioms rely on the distinction between POD and non-POD types. The standard macro offsetof() (defined in returns the offset in bytes of the member mem. According to the C++ standard, S must be a POD class, struct, or union. Otherwise, the results are undefined. Your task is therefore to write a constraint that automatically distinguishes between POD and non-POD types at compile-time. When the "must be POD type" constraint is violated, the compiler should issue an intelligible error message. Implementing a Constraint Compilers generate code only for member functions that are actually called, either implicitly or explicitly. Therefore, implementing the constraint inside the constructor or destructor of a class template will guarantee its compile-time evaluation in every instance (later we will see how to improve this design). To test the code, instantiate as many specializations as you like using diverse template arguments: As expected, the compiler issues error messages for the last three instances because their template arguments aren't POD objects. Design Improvements At Your Beck And Call "must be POD" is only one example of the numerous constraints you can enforce. Another common constraint is "must be T." Implementing this constraint is almost trivial: This constraint may be useful for example in MFC-style frameworks where all classes must be derived from a common base class. Let's test it: Here's another constraint: "must be an integral type." This one is also easy and can be implemented in many ways. One technique uses the object as an array's index. Since C++ requires that indexes shall be integral types, using any other type will cause a compilation error. I leave the implementation as an exercise to the reader.
#include
How can you enforce compile-time constraints on objects in a generic fashion?
Use "constraint templates" to automate the enforcement of compile-time constraints.
Suppose your app needs to interface with a non-C++ module written in C or SQL. To do so, you need to ensure that all objects passed to the non-C++ module have POD types. Alas, the definition of a POD type is rather evasive:struct S1 { int x;}; class S2 { public: void func(); }; union S3 { struct { int x, y; } t; char c[4];};struct S4 : S1, S2 {};
struct C1 { virtual void func(); //has a virtual function}; struct C2 { struct T{ int x, y; }; ~C2(); //has a destructor}; struct C3 : virtual S1 {} ; //has a virtual base class
size_t nbytes = offsetof (S, mem);
A constraint is essentially an expression or declaration within a member function of a class template. When the constraint is violated, the said expression triggers a compilation error. The challenging part is to find the right compile-time expression(s) that will fire when the constraint is violated. Familiarity with the C++ standard certainly wouldn't hurt here. Fortunately, the standard states in clause 9.5 that a non-POD object shall not be a member of a union. Eureka! Take advantage of this restriction by creating a union whose sole member is the object you want to test:template
//the following three pass compilationPOD_test
Does a constraint incur runtime and space overhead? If it's checked at compile-time, you certainly don't want it to remain in the executable. Modern IDEs are clever enough to optimize away code that isn't needed in the executable. To help the compiler out, move the constraint into a separate static member function constraints() (or any other name you like). Remember to declare this member private so that other clients can't call it:template
Notice that constraints() actually does nothing; it only declares a local union. Since the union isn't used, the compiler may elide the constraints() call in the constructor, thereby avoiding its overhead. //checks whether T1 is-a T2template
is_a_T2