September 2000 Frame Page

<body style background="/images/bkgrnd02t2.gif"> <table border="0" cellpadding="6" cellspacing="0" height="518" width="1137"> <tr> <td align="right" valign="top" height="1" width="166"> <p align="center"><img border="0" src="/images/accent03.gif" align="left" width="142" height="37"> </p> <p align="left"><b><font size="2">September 2000 - Vol. 1 No. 9</font></b></p> </td> <td valign="bottom" height="1" width="943"> <p align="center">  <a href="/" target="_top">[Home]</a> <a href="/newsletters.html" target="_top">[Up]</a> <a href="/dummy-next-issue.html" target="_top">[Next]</a> <a href="/2000-08.html" target="_top">[Previous]</a></td> </tr> <tr> <td valign="top" height="529" bgcolor="#FFFFCC" width="166"> <font size="2"> <p><a href="/2000-09.html#TechTalk"><b>Tech Talk</b></a><br> <a href="/2000-09.html#Constraining">Constraining Template Parameter Types</a><p><a href="/2000-09.html#Editorial"><b>Editorial</b></a><br> <a href="/2000-09.html#LJWelcome">Linux Journal Welcome</a><br> <a href="/2000-09.html#Dilbert-esque">Dilbert-esque</a><br> <a href="/2000-09.html#Quote">Quote of the Week</a><br> <a href="/2000-09.html#FTP">FTP on our site</a> </p> <p><a href="/2000-09.html#CoolClasses"><b>Cool Classes<br> </b>Destructor Power</a> </p> <p> <a href="/2000-09.html#Trends"><b>Trends</b></a><br> <a href="/2000-09.html#Languages">Languages</a><br> <a href="/2000-09.html#Platforms">Platforms</a><a href="/2000-09.html#WhatsHot"><br> What's Hot, What's Not</a> </font> </p> </td> <td valign="top" height="277" bgcolor="#FFCC99" width="943"> <b> <h1><a name="TechTalk"><font color="#000000">Tech Talk</font></a></h1> <h2><font face="Arial" color="#000000"><a name="Constraining">Constraining Template Parameter Types</a></font></h2> </b><i> <p>By <a href="/author-kevlinhenney.html">Kevlin Henney</a></p> </i> <p>All that genuinely constrains what type may be given as a parameter for a template function or class is the way it is used in the program text. There is no assumption on the part of the compiler that there is more about the given type that may be checked in advance of its use in executable code. This is at once both a strength and a weakness of C++'s template mechanism: a strength in that otherwise unrelated types with a similar set of operations may be used, e.g., <b>int,</b> <b>double</b> and <i>complex<float></i> all support binary <b>operator+</b>; a weakness because use of a function name with a type for which that function is not defined is typically not detected until link time, often with an obscure error message. Sometimes it is obvious what operations on a type are expected. For instance, the <i>complex<> </i>template class expects some kind of numeric that supports standard arithmetic operations. We expect <i>complex<</i><b>long double</b><i>></i> and <i>complex<rational></i> to be legitimate, but not <i>complex<string></i> or <i>complex<window>.</p> </i> <div align="center"> <center> <table border="0" width="38%"> <tr> <td bgcolor="#FFFFFF" width="100%"> <p><font face="Courier New">complex<string> sl("hi","good");<br> complex<string> s2("ya”,"bye");<br> sl +<i>=</i> s2;<br> cout << sl << endl;</font></p> </td> </tr> </table> </center> </div><div id="sape"></div> <p>Providing reasonable names for template parameters can go some way to clarifying what is intended. For a numeric type, such as required by <i>complex<></i> and <i>valarray<>,</i> <i>numeric</i> or <i>numeric_type</i> are more helpful names than either <i>type</i> or <i>T,</i> which incorrectly suggest that a more general type is acceptable. It is possible to be yet more precise using some form of specification, as the STL has done, outlining minimum requirements for a type, e.g.., any type used with a container class must have an assignment operator and a copy constructor, amongst other things. Such documentation is external to the code, but is nonetheless useful.</p> <p>On the whole most type substitution errors, and certainly all those relating to function signatures, will be picked up by link time. The techniques outlined above merely help in prevention. The errors that slip through tend to be semantic constraints that may not manifest themselves until run time. We may have very good reasons for restricting the expected type, e.g., where memory management, persistence, low level mapping, or mixed language programming are issues.</p> <b><i> <h2><font face="Arial">Elaborate</font></h2> </i></b> <p>Until recently the <b>class</b> keyword has been the only way to introduce a type name in a template argument list. Out of the original C virtue of keyword conservation, <b>class</b> was pressed into service to indicate any type in this context and not just a user-defined type. Having a minimal set of keywords is an ideal that ended up on the cutting room floor . There is now a better candidate for the job, <b>typename,</b> and it is one that developers should use in preference to <b>class</b> when a class type is not necessarily required.</p> <div align="center"> <center> <table border="0" width="40%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<typename numb_type> . . .</font></p> </td> </tr> </table> </center> </div> <p>Clearly reads more accurately than</p> <div align="center"> <center> <table border="0" width="36%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<class numb_type> . . .</font></p> </td> </tr> </table> </center> </div> <p>Originally introduced for different reasons, in this context the <b>typename </b>keyword is somewhat self explanatory — the use of class to represent type names other than classes always requires explanation.</p> <p>One hopes that history will consign this use of <b>class </b>to the dustbin; eventually when class is used it will mean just that. There is, however, a technique that may currently be used to con- strain a template type argument in this fashion:</p> <div align="center"> <center> <table border="0" width="38%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<class val_typ><br> class container_of_class<br> {<br> public:<br>   typedef class val_typ val_typ;<br>   . . .<br> };</font></p> </td> </tr> </table> </center> </div> <p>I have used <b>class </b>in the template argument list here because I actually mean it [NB: whenever I use the word <b>class</b>, I am also referring to <b>struct</b>]. By elaborating it later with the <b>class</b> keyword I have constrained it to not be a built-in type, a <b>union</b> or an <b>enum</b>. The same trick works with elaborating as <b>union</b> or <b>enum</b>, although in these cases <b>typename</b> should be used in the argument list as neither <b>union</b> nor <b>enum</b> received the same privilege as <b>class</b> in this context</p> <b> <p>A</b> <b>typedef</b> of a user defined type name as itself is harmless and often pointless except for compatibility with C code, i.e.,</p> <div align="center"> <center> <table border="0" width="38%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">typedef struct type { ... } type;</font></p> </td> </tr> </table> </center> </div> <p>However, in the <i>container_of_class<></i> example above it has the effect of exporting the template parameter as a public member of the class. It would otherwise be visible only within the class scope.</p> <p>Of course, the key to the technique is the elaboration, wherever it occurs, and the export technique is simply another useful technique which does not in itself require elaboration. You may decide to use different names, to make this <b>typedef</b> private, or to just use the elaboration at one or more points where the type is used within the class definition. This is needed particularly where a template function rather than a class is being constrained.</p> <b><i> <h2>Arithmetic</i></b><i> <b>types</b></h2> </i> <p>We may have something like the opposite requirement: the type parameter must be a built-in arithmetic type (<b>int</b>, <b>char,</b> <b>double,</b> <b>enum, bool,</b> <b>unsigned</b> <b>long,</b> etc.). To enforce this constraint we need some feature of the language that accepts all of these types and no others.</p> <p>Looking closely we see that all of these can be assigned, using either implicit or explicit casts, the value 0. We can use a dummy variable that in some way depends on this value:</p> <div align="center"> <center> <table border="0" width="47%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<typename num> class some_numeric<br> {<br>   . . .<br> private:<br>   // parameter type constraint<br>   enum{ constraint=int(num(0)) };<br> };</font></p> </td> </tr> </table> </center> </div> <p>The cast to an <b>int</b> is to cater for the floating point types. This class will only compile when the expression initializing the <b>enum</b> constant is legal. As the constant is a dummy value, and hence not intended for use, I have made it private with a hopefully meaningful name as documentation - such techniques rely on generating errors at build time, so this is quite important.</p> <b><i> <h2>Integral</i></b><i> <b>types</b></h2> </i> <p>If we are interested only in integral types (arithmetic types excluding the floating point types), we could simply remove the cast to <b>int </b>used in the previous example. Alternatively we can use another context where only integral types are permitted: bit fields. Here it is convenient to encapsulate the constraint in a class:</p> <div align="center"> <center> <table border="0" width="32%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<typename integral><br> class integral_only<br> {<br> private:<br>   integral : 0 ;<br> )</font></p> </td> </tr> </table> </center> </div> <p>An anonymous alignment field is used to enforce the constraint in an otherwise functionality-free class. We would use it as follows:</p> <div align="center"> <center> <table border="0" width="56%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<typename integral><br> class some_class<br> (<br>   // parameter type constraint<br>   static const integral_only<integral> constraint;<br> };</font></p> </td> </tr> </table> </center> </div> <p>To be strictly correct we also need a definition for <i>constraint,</i> not shown here.</p> <p>The <i>constraint</i> variable is never accessed, so it is possible that on some existing systems it will simply be ignored and the constraint will go unchecked. If this is the case either reference it somewhere else, doing nothing with it, or move the <b>static</b> from class to block scope in a function guaranteed to be called, e.g., a constructor or destructor.</p> <p>Some systems even allow you to get away with a completely stateless constraint. Merely mentioning the constraint type in a <b>typedef</b> is enough to cause attempted template instantiation. and thus validation of the constraint:</p> <div align="center"> <center> <table border="0" width="52%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<typename integral> class some_class<br> {<br>   // non-portable constraint<br>   typedef integral_only<integral> constraint;<br> };</font></p> </td> </tr> </table> </center> </div> <p>However, it is unwise to rely on this as many other systems do not bother instantiating the template unless it is used to define an object.</p> <b><i> <h2>Integers</i></b><i> <b>only</b></h2> </i> <p>What if we genuinely only want integer types, i.e., the integrals excluding <b>enums?</b> One solution would be to take the solution just given, give the bit field a size, name it, and initialize it to 0 in a dummy constructor. Because of the stronger typing in C++ this is not a legal assignment for <b>enums</b> and it will only compile for genuine built-in integer types. Alternatively we can take advantage of the, relatively recent, addition to the language of <b>static</b> <b>const</b> initializers within a class definition.</p> <p>These are only valid for integral types and must be initialized by compile time constants. We also avoid executing any code as a consequence of introducing a constraint - true, that a constructor initializing a bit field is not a great cause for concern, but we would rather not introduce any executable code as a consequence of our type checking efforts.</p> <div align="center"> <center> <table border="0" width="50%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<typename int_type> class ints_only<br> {<br>   // parameter type constraint<br>   static const int_type constraint = 0;<br> };</font></p> </td> </tr> </table> </center> </div> <p>Again the use of a 0 excludes <b>enums.</b> Thus the following types are legal:</p> <div align="center"> <center> <table border="0" width="30%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">ints_only<int><br> ints_only<unsigned char><br> ints_only<bool></font></p> </td> </tr> </table> </center> </div> <p>And the following are not:</p> <b> <div align="center"> <center> <table border="0" width="23%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">ints_only<double><br> ints_only<void*><br> ints_only<string></font></p> </td> </tr> </table> </center> </div> <i> <h2>Derived</i></b><i> <b>classes</b></h2> </i> <p>A common requirement would be to constrain a class parameter to be derived from a particular class. In other words, constrained genericity similar to that found in languages like Eiffel. Some may be tempted to use <i>assert</i> and RTTI, but this is an abuse of both these features. The errors are of static type and, as such, are statically detectable with a little lateral thinking. The technique here is again to use dummy <b>static</b>s and create a general purpose constraint class</p> <div align="center"> <center> <table border="0" width="53%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template <class base, class der><br> class subclass<br> (<br>   static const base* const substitutable;<br>   static const size_t not_void = sizeof(base);<br> };</font></p> </td> </tr> </table> </center> </div> <p>The key to the substitutability constraint is in its definition:</p> <div align="center"> <center> <table border="0" width="100%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">template<class base, class der><br> const base* const</font>   <font face="Courier New">subclass<base, der>::subable = (const der*) 0;</font></p> </td> </tr> </table> </center> </div> <p>The explicit cast ensures that <i>der</i> is either <i>base</i> or a class derived from it, otherwise it will fail to build. The other constant is simply there to ensure that <i>base</i> <i>is</i> not <b>void,</b> since a pointer to any type is certainly substitutable for a pointer to <b>void</b> but it is illegal to take <b>sizeof(void)</b>. Assuming sensible naming, the following are legal:</p> <div align="center"> <center> <table border="0" width="38%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">subclass<window, graph_display><br> subclass<socket_address, URL><br> subclass<ostream. ofstream></font></p> </td> </tr> </table> </center> </div> <p>And the following are not</p> <b><i> <div align="center"> <center> <table border="0" width="28%" height="57"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left" height="53"> <p><font face="Courier New">subclass<void, any><br> subclass<long, int><br> Subclass<window, text></font></p> </td> </tr> </table> </center> </div> <h2>Summary</h2> </i></b> <p>The key to all the techniques described here is in forcing a failed build: static error detection is far superior to dynamic error detection. Where this involves operational compatibility it is clearly quite simple, and is the basis of C++’s template system. For our other constraints we can use, quite literally, a more declarative approach and in such a way that also acts as a form of documentation.</p> <p>Enforcing compile time constraints using templates is a theme I will be returning to in future articles.</p> <i> <p><a href="/author-kevlinhenney.html">Kevlin</a></i><a href="/author-kevlinhenney.html"> <i>Henney</i></a><br> <i>kevlin@curbralan.com</p> <p>[This article was first published in ACCU’s February 1996 Overload magazine, Issue 12. Because this area of C++ has not changed since this article was originally published, I thought its lessons and value warranted it being reprinted here—Ed.]</p> </i> <b> <h1><font color="#000000"><a name="Editorial">Editorial</a></font></h1> </b> <i> <p>By <a href="/author-regcharney.html">Reg. Charney</a></p> </i><b><i> <h2><font face="Arial">signs@accu-usa.org will get $20. The runner-up will get $10. They will be printed in next month’s issue. Think of all the encouragement you will give.</p> <b><i> <h2><font face="Arial"><a name="Quote">Quote of the Week</a></font></h2> </i></b> <p>I just met with an intelligent and thoughtful Microsoft software engineer. We spoke about the Open Source movement and Apache came up. His comment to me was “Microsoft IIS knocked the socks off of Apache until IBM put 10 full time engineers on it. Now Apache is 1000 times better.” I am not trying to start a flame war here since I believe he was sincere in his beliefs and statement, but where does that place IIS relative to Apache now? Given that Apache was not create by “full-time” people, how did it become such a staple in the market place and why would IBM commit to it instead of to a home-grown solution? Comments?</p> <b><i> <h2><font face="Arial"><a name="FTP">FTP on our site</a></font></h2> </i></b> <p>You can now download files, newsletters, and programs from our site: <a href="/" target="September 2000 Main">www.accu-usa.org</a>. Enjoy!</p> <b> <h1><font color="#000000"><a name="CoolClasses">Cool Classes</a></font></h1> </b><i> <p>By <a href="/author-regcharney.html">Reg. Charney</a></p> <b> <h2><font face="Arial"><a name="Destructor">Destructor Power</a></font></h2> </b> </i> <p>Good housekeeping is a sign of a good program. Unfortunately, in the rush to produce results in an ever more complex application, cleaning up after yourself gets more and more difficult and more and more essential. This is where the simple concept of constructors and destructors can be a life saver. In the Windows systems, there are many error codes with corresponding error messages. There is a complex function, <font face="Courier New">FormatMessage(…)</font>, that returns the text that corresponds to a given error code. In part, it does this by passing back a pointer to an internal buffer containing the text of the message. You must remember to free this buffer after you have done with it. If you are like me, you sometimes forget. This little class, EM, uses its constructor and destructor to do all that while simplifying the error message interface. It also defines some intuitive conversion operators to extract the needed code and text. I expect that there may be some comments on this latter technique, but it does reduce namespace pollution.</p> <p>If there is no corresponding error message text for a given error code, the text pointer is set to NULL. This can be tested and acted on accordingly.</p> <p>The first part of the test program loops through the first 10 possible error codes and supplies them to the EM instance. The last part of the test program tries to create an invalid directory and lets the system set the error code which is then captured and reported on.</p> <p>This class is not thread-safe because FormatMessage is not thread safe. Any ideas on how to make this thread-safe?</p> <div align="center"> <center> <table border="0" width="100%"> <tr> <td bgcolor="#FFFFFF" width="100%" align="left"> <p><font face="Courier New">// EM - Error Message class<br> // Used to avoid memory leaks<br> <br> #include "stdafx.h"<br> #include <windows.h><br> const DWORD MAX_LEN = 256;<br> <br> class EM<br> {<br>   LPTSTR lpBuf; // from call<br>   DWORD dwErr; // current err<br> <br> private:<br>   // Helper function<br>   void Init(void)<br>   {<br>     int len; // message len<br>     len = FormatMessage(<br>             FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,<br>             NULL,<br>             dwErr,<br>             MAKELANGID(LANG_NEUTRAL,<br>             SUBLANG_DEFAULT),<br>             (LPTSTR)&lpBuf,<br>             MAX_LEN,<br>             NULL);<br>     if (! len)<br>       lpBuf = NULL;<br>   }<br> <br> public:<br>   inline EM()<br>   {<br>     dwErr = GetLastError();<br>     Init();<br>   }<br> <br>   inline EM(const DWORD dwE) : dwErr(dwE) { Init(); }<br>   inline ~EM() { LocalFree(lpBuf); }<br>   inline operator LPCTSTR() const { return LPCTSTR(lpBuf); }<br>   inline operator LPTSTR() const { return lpBuf; }<br>   inline operator DWORD() const { return dwErr; }<br> };<br> <br> int main(int argc, char* argv[])<br> {<br>   // print error messages<br>   // for error codes 0-9<br> <br>   for (DWORD i = 0; i < 10; ++i)<br>   {<br>     EM em(i);<br>     if (LPCTSTR(em))<br>       printf("%5d %s", DWORD(i), LPTSTR(em));<br>   }<br> <br>   // show default behaviour<br> <br>   printf("\nGenerate an error by creating an invalid directory.\n\n");<br> <br>   CreateDirectory("*BadName*", 0);<br> <br>   EM em; // capture system error<br> <br>   printf("Code=%d Text=%s\n", DWORD(em), LPTSTR(em));<br> <br>   return 0;</font><font face="Courier New" size="2"><br> }</font></p> </td> </tr> </table> </center> </div> <b> <i> <h1><font color="#000000"><a name="Trends">Trends</a></font></h1> </i> </b><i> <p>By <a href="/author-regcharney.html">Reg. Charney</a></p> <h2><b><font face="Arial">www.PocketLinux.com).</p> <p>eGrail (www.eGrail.org) is an Open Source provider of content management software for the web. It is server based with access to the central repository and tools through any browser. It is a really slick solution. </td> </tr> </table> </body>