September 2000 Frame Page

<body stylesrc="index.html" 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="index.html" 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="#TechTalk"><b>Tech Talk</b></a><br> <a href="#Constraining">Constraining Template Parameter Types</a><p><a href="#Editorial"><b>Editorial</b></a><br> <a href="#LJWelcome">Linux Journal Welcome</a><br> <a href="#Dilbert-esque">Dilbert-esque</a><br> <a href="#Quote">Quote of the Week</a><br> <a href="#FTP">FTP on our site</a> </p> <p><a href="#CoolClasses"><b>Cool Classes<br> </b>Destructor Power</a> </p> <p> <a href="#Trends"><b>Trends</b></a><br> <a href="#Languages">Languages</a><br> <a href="#Platforms">Platforms</a><a href="#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> <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><a href="mailto:kevlin@curbralan.com">kevlin@curbralan.com</a></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"><a name="LJWelcome">Linux Journal Welcome</a></font></h2> </i></b> <p>We are delighted to welcome Linux Journal as one of our sponsors. They are the premier magazine covering the Open Source movement, and Linux in particular. They are an excellent source for all things related to Linux, particularly commercial vendors and products.</p> <b><i> <h2><font FACE="Arial"><a name="Dilbert-esque">Dilbert-esque</a></font></h2> </i></b> <p>A major Valley company has found a unique way of energizing its people. It is posting “Don’t waste your time” signs everywhere. From a marketing perspective, this message is a disaster: it suggested no remedy, no solution, no product nor a course of action. The sign makers are implying its employees are time-wasters or worse. It was tempting to scrawl on one or more signs, addendums like: “… by reading this message” or “… by writing on this sign.” or “… - Go fishing”. I am sure you can come up with better responses than mine. The best one that I receive at <a href="mailto:signs@accu-usa.org">signs@accu-usa.org</a> 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="http://www.accu-usa.org" 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"><a name="Languages">Languages</a></font></h2> </b> </i> <p>Over the last fifteen months, the major growth in languages has been those directly related to the Internet. Thus, XML, Perl, HTML, and Java have flourished as shown in Chart #1. However, even these high-flyers have suffered reverses in the last few months as shown in Chart #2. It is interesting to note that the highest flyers are also showing the most deceleration in demand.</p> <b><i> <h2><font face="Arial"><a name="Platforms">Platforms</a></font></h2> </i></b> <p>In this issue, you may have noticed some platform omissions including Oracle 2000 and AIX. While there are many users on these platforms, their growth on a month by month basis and over the last fifteen months has been so minimal that they will no longer be included. I will let you interpret that as you see fit.</p> <font SIZE="2"> <p align="center"><img border="0" src="images/2000-09-Fig01.gif" width="342" height="233"> <img border="0" src="images/2000-09-Fig02.gif" width="331" height="234"></p> </font> <p>One of the major changes in the demand deceleration of platforms is that Windows 2000 has now joined the other platforms in a decreased demand. If you recall, last month, Windows 2000 was the only platform to buck the downward trend. Interestingly enough, while individual flavors of Windows have decreased in demand, overall demand for Windows is still growing, albeit slowly. This includes all dialects of Windows.</p> <font SIZE="2"> <p align="center"><img border="0" src="images/2000-09-Fig03.gif" width="342" height="209"> <img border="0" src="images/2000-09-Fig04.gif" width="331" height="210"></font></p> <h2><b><i><font face="Arial"><a name="WhatsHot">What’s is Hot, What is Not</a></font></h2> </i></b> <p>You must have been on an island not to know that LinuxWorld was in San Jose in August. It had so many exhibitors that some of them overflowed the exhibits hall and ended up out in the hall ways. Rumor has it that the next year’s West Coast LinuxWorld will move to San Francisco’s Moscone Centre to handle the larger crowds expected next year. There was also a lot of big names there: IBM, Dell, Compaq SGI, HP, Sun, as well as the usual Linux crowd like our own VA Linux and all the major Linux distributors. The BSD folks also had an interesting presence.</p> <p>If anything could be said about future trends, it had to be “Linux for embedded systems”. In contrast, last year’s theme was Linux in the business world. This year delivered on a lot of that promise. Most of the software exhibitors were providers of B2B solutions. Two products caught my eye.</p> <p>PocketLinux’s Linux on a Compaq iPaq is a color PDA running Linux and can be Internet enabled. It will give Palm a real run for its money. Cost about $500. There is also a B&W Helio for about $200 (<a href="http://www.PocketLinux.com" target="September 2000 Main">www.PocketLinux.com</a>).</p> <p>eGrail (<a href="http://www.eGrail.org" target="September 2000 Main">www.eGrail.org</a>) 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>