2002-12

<body stylesrc="index.html" background="images/Bkgrnd02T2.gif"> <table border="0" cellpadding="6" cellspacing="0" width="810"> <tr> <td align="right" valign="top" height="1" width="170"> <p align="center"><img border="0" src="images/Accent03.gif" align="left" width="142" height="37"> </p> <p align="left"><b><font size="2">December 2002 - Vol. 3 No. 12</font></b></p> </td> <td height="1" width="612"> <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="2002-11.html" target="_top">[Previous]</a></td> </tr> <tr> <td valign="top" height="529" bgcolor="#FFFFCC" width="170"> <font size="2"> <p><a href="#TechTalk"><b>Tech Talk</b></a><br> <a href="#C++ Templates">C++ Templates</a> </p> <p><a href="#Editorial"><b>Editorial</b></a><br> <a href="#The Future?">The Future?</a> </p> <p><a href="#Reading for the Blind & Dyslexic">Reading for the Blind and Dyslexic</a> </p> <p><a href="#Book Reviews"><b>Book Review</b></a><br> <a href="#Real-Time UML">Realtime UML</a> </p> <p><a href="#Trends"><b>Trends</b></a><br> <a href="#Windows Weakening?">Windows Weakening</a></font></p> </td> <td height="277" bgcolor="#FFCC99" width="612"> <b> <h1><a name="TechTalk"><font color="#000000">Tech Talk</font></a></h1> <i> <h2><font face="Arial"><a name="C++ Templates">C++ Templates</a></font></h2> </i> </b> <i> <p>by <a href="Author-RegCharney.html"> Reg. Charney</a></p> </i> <p>If you wanted to know just about everything about <i>C++ templates than the book C++ Templates—The Complete Guide</i> by David Vandevoorde and Niccolai Josuttis, (ISBN 0-201-73484-2) is a readable reference book you can use. Normally, discussing a book would appear in a book review. However, since the authors have done such a good job of describing C++ templates, I though the topic and the book deserved more complete coverage. You may recall Niccolai as the author of the excellent text, <i>The C++ Standard Library</i>, ISBN 0-201-37926-0. David is the author of <i>C++ Solutions: Companion to the C++ Programming Language , Third Edition, </i>ISBN 0-201-30965-3. Both authors are also longtime members of the ANSI/ISO C++ X3J16 Standardization Committee.</p> <b> <h3><font FACE="Arial">Ordering Convention</font></h3> </b> <p>Most of us write the following <font FACE="Courier New">const</font> or <font FACE="Courier New">volatile</font> declaration thus:</p> <div align="center"> <center> <table border="1" width="233" bgcolor="#FFFFFF"> <tr> <td width="223"><font FACE="Courier New">volatile int vInt;<br> const char *pcChar;</font></td> </tr> </table> </center> </div> <p>The authors suggest that a better way is:</p> <div align="center"> <center> <table border="1" width="269" bgcolor="#FFFFFF"> <tr> <td width="259"><font FACE="Courier New">int volatile vInt;  // 1<br> char const *pcChar; // 2</font></td> </tr> </table> </center> </div> <p>Here, <font FACE="Courier New">const </font>and <font FACE="Courier New">volatile </font>appear before what they qualify. Since I read declarations from right to left, in <font FACE="Courier New">//1</font>, I get <font FACE="Courier New">vInt </font>is a <font FACE="Courier New">volatile int </font>and in <font FACE="Courier New">//2</font>, I get <font FACE="Courier New">pcChar </font>is a pointer to a <font FACE="Courier New">const char</font>. The real power comes when we use this ordering in <font FACE="Courier New">typedef </font>statements. For example,</p> <div align="center"> <center> <table border="1" width="281" bgcolor="#FFFFFF"> <tr> <td width="271"><font FACE="Courier New">typedef int  *PINT;<br> typedef PINT  const CPINT;<br> typedef const PINT  PCINT;</font></td> </tr> </table> </center> </div> <p>Here we can see that the first <font FACE="Courier New">typedef</font> (pointer to <font FACE="Courier New">int</font>) can be used in the second <font FACE="Courier New">typedef</font> (<font FACE="Courier New">const</font> pointer to <font FACE="Courier New">int</font>). The third <font FACE="Courier New">typedef</font> completely changes the meaning of the type (pointer to <font FACE="Courier New">const int</font>).</p> <b> <h3><font face="Courier New" size="5">typename</font><font face="Arial"> Keyword</font></h3> </b> <p>Historically, we have used the keyword, <font FACE="Courier New">class</font>, in template parameter lists:</p> <div align="center"> <center> <table border="1" width="287" bgcolor="#FFFFFF"> <tr> <td width="277"><font FACE="Courier New">template< class T > . . .</font></td> </tr> </table> </center> </div> <p>However, <font FACE="Courier New">T</font> could be replaced by things other than a class name, so the use of the new keyword <font FACE="Courier New">typename </font>is preferred.</p> <b> <h3><font FACE="Arial">Reducing Ambiguities</font></h3> </b> <p>Often, instantiating a template can result in an ambiguity error that is difficult to understand. Here is a simple example:</p> <div align="center"> <center> <table border="1" width="535" bgcolor="#FFFFFF"> <tr> <td width="525"><font FACE="Courier New">template< typename T > plot2D(T& x, T& y);<br> <br> plot2D(3,4);    // ok<br> plot2D(3.14,1); // err - types of arguments differ</font></td> </tr> </table> </center> </div> <p>The ambiguity occurs because all parameters are supposed to be of same type, but in the second case, it is unclear whether that type should be an <font FACE="Courier New">int</font> or a <font FACE="Courier New">double</font>.</p> <p>In this simple example (and many others like it), there are 3 ways of disambiguating the statement:</p> <div align="center"> <center> <table border="1" width="423" bgcolor="#FFFFFF"> <tr> <td width="413"><font FACE="Courier New">plot2D<int>(3.14,1);               // 3<br> plot2D(static_cast<int>(3.14), 1); // 4</font></td> </tr> </table> </center> </div> <p>In <font FACE="Courier New">//3</font>, the template type is forced to be <font FACE="Courier New">int</font>. In <font FACE="Courier New">//4</font>, casting forces all the argument types to be the same. The third way to eliminate this problem uses more sophisticate templates.</p> <b> <h3><font FACE="Arial">Overloading function template</font></h3> </b> <p>It is possible to have both template and non-template versions of the same function. Often, these non-template versions of the function are called specializations. In such situations, function overloading and its rules are used to resolve any ambiguities. Because we are talking about templates, a few added rules are needed to normal function overloading rules.</p> <ul> <li>In instantiating a template function, no type conversions are done.</li> <li>All things being equal, specialized template functions are preferred over template ones.</li> <li>If instantiating a template function results in a better match, the better match is used. By better match, we mean that things like conversions are not need to make a match.</li> <li>If the empty angle brackets notation is used, non-template functions are ignored in matching argument.</li> </ul> <p>Here are some examples:</p> <div align="center"> <center> <table border="1" width="535" bgcolor="#FFFFFF"> <tr> <td width="525"><font FACE="Courier New">int cmp(int const& a, int const& b);<br> <br> template<typename T> T cmp(T const& a, T const &b);<br> <br> cmp(1,2);        // 5<br> cmp(4.3, -1.2);  // 6<br> cmp(‘x’,’s’);    // 7<br> cmp<>(-3,2);     // 8<br> cmp<int>(4.3,4); // 9</font></td> </tr> </table> </center> </div> <p>In <font FACE="Courier New">//5</font>, the non-template function is the best match (Rule 2). In <font FACE="Courier New">//6</font>, template argument deduction instantiates the <font FACE="Courier New">cmp<double></font> function (Rule 3). In <font FACE="Courier New">//7</font>, the instantiated function is <font FACE="Courier New">cmp<char></font> (Rule 3). In <font FACE="Courier New">//8</font>, the notation forces use of the template function and results in a <font FACE="Courier New">cmp<int></font> function being instantiated and used instead of the non-template version of the <font FACE="Courier New">cmp</font> function (Rule 4).</p> <b> <h3><font FACE="Arial">Partial Specialization</font></h3> </b> <p>When a template class or function has more than one template parameter, one or more may be specified creating a partially specialized template. However, if one or more partial specializations match the same template, an ambiguity occurs. For example,</p> <div align="center"> <center> <table border="1" width="457" bgcolor="#FFFFFF"> <tr> <td width="447"><font FACE="Courier New">// partials.cpp<br> #include <typeinfo><br> #include <stdio.h><br> typedef char const CC;</font> <p><font FACE="Courier New">// general template function<br> template<typename T1,typename T2><br> void f(T1 t1, T2 t2)<br> {<br>   CC* s1=typeid(T1).name();<br>   CC* s2 = typeid(T2).name();<br>   printf("f(%s,%s)\n",s1,s2);<br> }</font></p> <p><font FACE="Courier New">// partially specialization 1<br> // both type the same<br> template<typename T><br> void f(T t1, T t2)<br> {<br>   CC* s1 = typeid(T).name();<br>   CC* s2 = typeid(T).name();<br>   printf("f1(%s,%s)\n",s1,s2);<br> }</font></p> <p><font FACE="Courier New">// partially specialization 2<br> // 2nd parameter is non-type<br> template< typename T><br> void f(T t1, int t2)<br> {<br>   CC* s1 = typeid(T).name();<br>   CC* s2 = typeid(int).name();<br>   printf("f(%s,%s)\n",s1,s2);<br> }</font></p> <p><font FACE="Courier New">// partially specialization 3<br> // parameters are all pointers<br> template< typename T1, typename T2><br> void f(T1* t1, T2* t2)<br> {<br>   CC* s1 = typeid(T1*).name();<br>   CC* s2 = typeid(T2*).name();<br>   printf("f(%s,%s)\n",s1,s2);<br> }</font></p> <p><font FACE="Courier New">int main(int argc,char* argv[])<br> {<br>   char const* s1="one";<br>   f(1,21.3);<br>   f(1.2,-3);<br>   f('a','z');<br>   f(s1,2);<br>   f(&s1,"two");<br>   return 0;<br> }</font></td> </tr> </table> </center> </div> <p>The output from this program is:</p> <div align="center"> <center> <table border="1" width="449" bgcolor="#FFFFFF"> <tr> <td width="439"><font FACE="Courier New">f(int,double)<br> f(double,int)<br> f(char,char)<br> f(CC *,int)<br> f(CC **,char *)</font></td> </tr> </table> </center> </div> <p>Note that calling <font FACE="Courier New">f(3,5)</font> is ambiguous because both <font FACE="Courier New">f(T,T)</font> and <font FACE="Courier New">f(T,int)</font> match this call.</p> <b> <h3><font FACE="Arial">Non-type Template Parameters</font></h3> </b> <p>Both classes and functions can use non-type template parameters. When used, non-type parameters become part of the classes type and functions signature. Thus,</p> <div align="center"> <center> <table border="1" width="336" bgcolor="#FFFFFF"> <tr> <td width="326"><font FACE="Courier New">template<typename T, int n><br> class C<br> {<br>   T a[n];<br>   // . . .<br> };</font> <p><font FACE="Courier New">C<char, 10> c10A;<br> C<char, 5>  c5A;<br> C<int, 10>  i10A;</font></td> </tr> </table> </center> </div> <p>Each of <font FACE="Courier New">c10A</font>, <font FACE="Courier New">c5A</font>, and <font FACE="Courier New">i10A</font> are all distinct types.</p> <p>An example of a template function using non-type parameter follows:</p> <div align="center"> <center> <table border="1" width="543" bgcolor="#FFFFFF"> <tr> <td width="533"><font FACE="Courier New">template<typename T, int n><br> T g(T t)<br> {<br>   return t+n;<br> }<br> int main()<br> {<br>   printf("g<double,5>(1.3)=%g\n", g<double,5>(1.3));<br>   printf("g<char,4>('a')=%c\n", g<char,4>('a'));<br> }</font></td> </tr> </table> </center> </div> <p>The output of this short program is:</p> <div align="center"> <center> <table border="1" width="285" bgcolor="#FFFFFF"> <tr> <td width="275"><font FACE="Courier New">g<double,5>(1.3)=6.3<br> g<char,4>('a')=e</font></td> </tr> </table> </center> </div> <p>Non-type template parameters have restrictions: they must be integral values, enumerations, or instance pointers with external linkage. They can’t be string literals nor global pointers since both have internal linkage.</p> <b> <h3><font face="Arial">Keyword </font><font face="Courier New" size="5">typename</font></h3> </b> <p>You may have wondered why we needed the new keyword <font FACE="Courier New">typename</font>. Besides being a better choice for template parameters, it is needed to disambiguate certain declarations. E.g.,</p> <div align="center"> <center> <table border="1" width="319" bgcolor="#FFFFFF"> <tr> <td width="309"><font FACE="Courier New">template<typename T, int n><br> class C<br> {<br>   typename T::X *p;<br>   // . . .<br> };</font></td> </tr> </table> </center> </div> <p>Without the keyword <font FACE="Courier New">typename</font>, the declaration for <font FACE="Courier New">p</font> becomes an expression: the value of <font FACE="Courier New">T::X</font> is multiplied by the value of <font FACE="Courier New">p</font>.</p> <p>Generally, prefix all declarations using template parameters with <font FACE="Courier New">typename</font>.</p> <b> <h3><font face="Courier New" size="5">this</font><font face="Arial"> pointer</font></h3> </b> <p>Normally derived and base classes share the value of <font FACE="Courier New">this</font>. However, lookup rules for template classes are different. Template base class members are not lookup when searching derived template class member functions.</p> <div align="center"> <center> <table border="1" width="324" bgcolor="#FFFFFF"> <tr> <td width="314"><font FACE="Courier New">template<typename T><br> class B<br> {<br>   void foo();<br> }</font> <p><font FACE="Courier New">template<typename T><br> class D: public B<T><br> {<br>   void bar() { foo(); }<br> }</font></td> </tr> </table> </center> </div> <p>In <font FACE="Courier New">bar(),</font> <font FACE="Courier New">foo()</font> would not be found. To get <font FACE="Courier New">B</font>’s <font FACE="Courier New">foo</font>, you need to say <font FACE="Courier New">this->foo()</font>. Again, the rule given in the book states that any base class member used in a derived class should be qualified by <font FACE="Courier New">this-></font> or <font FACE="Courier New">B<T>::</font>.</p> <b> <h3><font FACE="Arial">Conclusion</font></h3> </b> <p>I have not begun to cover many of the interesting aspects of templates in this short article. And I have barely covered the other fun parts of this book. Get it.</p> <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> <h2><font FACE="Arial"><a name="The Future?">The Future?</a></font></h2> </b> <p>In <a href="http://www.redherring.com">www.redherring.com</a> December’s newsletter, they listed for 2003 10 predictions from various experts . I was interested to see where it might lead for the Valley. The main predictions are:</p> <ul> <li>Wireless LAN's (WLANs), aka wi-fi or 802.11, will take off.</li> <li>“Virtualizing” the process of making big user's infrastructure seamless will dominate IT spending.</li> <li>No shake-out among the VCs, but continuing "make money or else" on part of 2+ stage firms.</li> <li>Stock options impact the bottom line. Tech firms are finally forced to include options as expenses in financial reports. Geoffrey James argues this point as inevitable.</li> <li>Telecom companies that have clawed their way out of bankruptcy will seek its protection again. However, there is still plenty of bandwidth left.</li> <li>Stephan Herrera points out that the bioterrorism effort will reduce biotech industry competition .</li> </ul> <p>If you believe these predictions, you can see that connectiveness is driving where we are going. Bioterrorism is also going to drive more biotech. The expensing of options will reduce their importance in attracting staff.</p> <b> <h2><font FACE="Arial"><a name="Reading for the Blind & Dyslexic">Reading for the Blind & Dyslexic</a></font></h2> </b> <p>I was contact early this month by Luby Aczel, a Volunteer Coordinator for the non-profit Northern California studio of Recording for the Blind and Dyslexic. They create and lend educational material on CD or four track cassette to individuals with learning or visual disabilities. They need volunteers to read the many technical and computer manuals for which they get requests. Please visit their web site at <a href="http://www.rfbd.org">www.rfbd.org</a> to find out more about them. You can also contact Luby Aczel, at 650-493-3717, ext. 13</p> <h1><a name="Book Reviews"> <b> <font color="#000000">Book Reviews</font> </b> </a></h1> <i> <p><b><font size="4"><a name="Real-Time UML">Real-Time UML</a>: Developing Efficient Objects for Embedded Systems—2nd Edition</font></b></i> by Bruce Powel Douglass, Addison-Wesley, ISBN 0-201-65784-8</p> <b> <p>Rating</b>: Recommended<br> <b>Reading Level: </b>Easy.</p> <p>I believe this book heralds the next step in system design, reliability, and effectiveness. On every page, new ideas jumped out at me.</p> <p>Real-Time UML is geared towards the beginning to intermediate level. It presents a clear and practical approach for a reader with minimal exposure to UML and embedded systems.</p> <p>The book is well organized and easy to read. It contains seven chapters. Broadly speaking, the first four chapters focus on analysis and the last three focus on design. Chapter 1 provides an introduction to objects and real-time systems concepts such as concurrency and messaging. Chapter 2 uses UML to analyze real-time systems requirements. Here, use cases are fundamental to capturing the requirements of a system. Chapters 3 and 4 focus on object analysis from two points of view. First, from a structural perspective, it explains how to identify a set of objects that is necessary to realize a set of use cases. Second, from a behavioral point of view, the author explores how do these objects communicate and relate to one another so that the system requirements can be met. Chapters 5, 6 and 7 discuss design topics. Chapter 5 emphasizes architecture, including the use of patterns appropriate for embedded systems. Chapter 6 discusses mechanistic design which involves the organization of classes to support a particular implementation strategy. Chapter 7 dives into detailed design looking at things such as data structure implementation and algorithms.</p> <p>One of the most interesting topics covered in Real-Time UML is statecharts. Statecharts are a unique modeling tool that allow for better analysis of real time systems. In Chapter 4, the author introduces statecharts and proceeds to give numerous examples of practical applications.</p> <p>The text is fairly accurate. The use of diagrams and clear examples is widespread throughout. Little code is presented as it is not really needed to introduce UML concepts. However; snippets of C++ can be found where they enhance the explanation of a concept.</p> <p>The book is very useful for several reasons. It serves as a stepping stone for further study of OO techniques applied to embedded systems. Furthermore; since it covers three broad areas: OO, UML and embedded systems, anyone with more advanced knowledge in any of these areas can use this book to see how the other areas are tied into what they already know.</p> <p><i>— Bernal A. Arroyo</i></p> <i> <b> <h1><font color="#000000"><a name="Trends">Trends</a></font></h1> </b> <p>By <a href="Author-RegCharney.html">Reg Charney</a> and <a href="Author-AliCehreli.html">Ali Çehreli</a></p> </i><b> <h2><font FACE="Arial"><a name="Windows Weakening?">Windows Weakening?</a></font></h2> </b> <p>In this month’s chart, I noticed that Windows development in the Valley seems to be weakening. That is, as a proportion of the total number of job openings offered, the percentage related to Windows has been decreasing, more so than Linux, for example.</p> <p align="center"><img border="0" src="images/2002-12-Fig01.gif" width="462" height="316"></p> <p>Also note that Windows XP is hardly making an impact. There are still more job openings asking for Windows ME skills than for XP knowledge. Also, as a proportion of all the openings advertised, Linux and individual flavors of Windows are about the same.</p> <p>Another interesting observation is that there was a noticeable up-tick in the jobs offered in August that has subsequently dipped. This also matches the consumer confidence index for the same period. </td> </tr> </table> </body>