2003-02

<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">February 2003 - Vol. 4 No. 2</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="2003-01.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="#Containers in Classes">Containers in Classes</a> </p> <p><a href="#Thru the Looking Glass"><b>Thru the Looking Glass</b></a><br> <a href="#Language Development —The Problem with const">Language Development - The Problem with const</a> </p> <p><a href="#Editorial"><b>Editorial</b></a><br> <a href="#Spyware and TurboTax">Spyware and TurboTax</a> </p> <p><a href="#Book Reviews"><b>Book Review</b></a><br> <a href="#Extreme Programming Perspectives">Extreme Programming Perspectives</a> </p> <p><a href="#Trends"><b>Trends</b></a><br> <a href="#Bottomed Out?">Bottomed Out?</a></font></p> </td> <td height="277" bgcolor="#FFCC99" width="612"> <b> <h1><a name="TechTalk"><font color="#000000">Tech Talk</font></a></h1> </b> <font FACE="Arial"> <h2><a name="Containers in Classes">Containers in Classes</a></h2> </font><i> <p>By <a href="Author-RegCharney.html">Reg. Charney</a></p> </i> <h3><font FACE="Arial">The Problem</font></h3> <p>Recently, I was using a powerful non-C++ class library. Within it guts, it had an important class that kept a container of items that I needed to extend. However, the design of the class precluded my doing this from outside the class itself. This meant that I had two basic choices: take ownership of the class forever; or foregoing changing the original class and designing a complete replacement. Neither choice was a very appetizing. In fact, if the original class had been properly designed, I would not have faced this decision at all and could have extended the class easily.</p> <h3><font FACE="Arial">Collection Principles</font></h3> <p>I would like to talk about avoiding this problem in future. But first, we need to discuss a few general principles. When we ask a container to hold information for us, we expect it to do that, regardless of what we do with the original copy of the data. For example, if a container is meant to hold a set of book titles, then it is safest for all concerned if it keeps copies of the titles. In that way, we can do anything we need to do with the original data and know our collection is safe as would happen if the book titles are read off a database, one title per record/row at a time. A second general principle states it is often better to keep pointers to data in a collection than to keep the data itself. The main reason is to allow for polymorphism. We will discuss that a little later. However, it is tempting to pass the pointers that you generate to your data to the collection and let it keep those copies. Great care must be exercised when doing this. Since you generate the pointers, you have nominal ownership of the data being pointed at. Thus, you have the ability to delete the data whenever you wish, even though the data is still being referenced by elements of the collection. This often causes very ugly problems at program termination.</p> <h3><font FACE="Arial">Examples</font></h3> <div align="center"> <center> <table border="1" width="649"> <tr> <td bgcolor="#FFFFFF" width="639"><i>I use some coding conventions when I am writing code in limited space like this column:</i> <p><i>I use the <font FACE="Courier New">using namespace std; </font>statement. However, it is almost always better to use explicitly qualified instances of std members. For example:</i></p> <p><font FACE="Courier New">list<X> lx; </font><i>and<br> </i><font FACE="Courier New">cout << endl<i>;</i></font><i> </i></p> <p><i>would be better written as:</i></p> <p><font FACE="Courier New">std::list<X> lx<i>; </i></font><i>and  </i><font FACE="Courier New"><br> std::cout << std::endl<i>;</i></font></p> <p><i>I have also in-lined all the member functions. Their declarations and definitions should be in different source files.</i></td> </tr> </table> </center> </div> <p>In this simple example, class A has a container of class X objects. We can add items to the container in A and to print the contents of the container that A holds. Since A will be extended, some of its member functions are virtual. Class Y is derived from X. Also, I wanted to be able to add both stack and heap variables to the collection.</p> <p>(For simplicity in this column, I have used an STL <font FACE="Courier New">std::list </font>container. While I am working from the assumption that templates are not available, as is the case in other languages like Java and Delphi, I have used the one instance of a list of X objects. Other languages have containers that can hold references to generic objects).</p> <table border="1" width="565"> <tr> <td width="555" bgcolor="#FFFFFF"><font FACE="Courier New">#include <iostream><br> #include <string><br> #include <list></font> <p><font FACE="Courier New">using namespace std;</font></p> <p><font FACE="Courier New">class X {<br>   string s;<br> public:<br>   X(const char* ss):s(ss) { }<br>   virtual string prt() { return s; }<br> };</font></p> <p><font FACE="Courier New">class Y : public X {<br>   string t;<br> public:<br>   Y(const char* ss, const char* tt) : X(ss), t(tt) { }<br>   virtual string prt() { return X::prt()+t; }<br> };</font></p> <p><font face="Courier New">class A {<br>   typedef list<X*> LXP;<br>   typedef LXP::iterator LXPI;<br> protected:<br>   LXP ls; // container of X*s<br> public:<br>   virtual void prt(const char *t)<br>   {<br>     cout << t << endl;<br>     for(LXPI i=ls.begin(); i!=ls.end();++i)<br>       cout << (*i)->prt() <<endl;<br>   }<br>   virtual void add(const X& rx)<br>   {<br>     X* xp = new X(rx); // 1<br>     ls.push_back(xp);<br>   }<br>   virtual ~A()<br>   {<br>     for(LXPI i=ls.begin(); i!=ls.end(); ++i)<br>       delete *i;<br>   }<br> };</font></p> <p><font face="Courier New">struct B : public A {<br>   virtual void add(const Y& ry) // 2<br>   {<br>     Y* yp = new Y(ry);<br>     ls.push_back(yp);<br>   }<br> };</font></p> <p><font face="Courier New">int main()<br> {<br>   A a1;<br>   {<br>     X x1("a"), x2("b"), *px;<br>     a1.add(x1);<br>     a1.add(x2);<br>     px = new X("c");<br>     if (px)<br>       a1.add(*px);<br>     delete px;<br>   } // deletes stack items<br>   a1.prt("A1 list is:");<br>   B b1;<br>   {<br>     Y y1("d","1");<br>     Y y2("e","2");<br>     Y *py;<br>     b1.add(y1);<br>     b1.add(y2);<br>     py = new Y("f","3");<br>     if (py) <br>       b1.add(*py);<br>     delete py;<br>   } // deletes stack items<br>   b1.prt("B1 list is:");<br>   return 0;<br> }</font></td> </tr> </table> <p>The add() function must be overridden (as in //2) , else derived classes will be truncated at //1 when the copy constructor is called prior to the pointer being inserted into the collection.</p> <b> <i> <h2><font face="Arial"><a name="Thru the Looking Glass">Thru the Looking Glass</a></font></h2> </i> </b> <i> <p>by <a href="Author-FrancisGlassborow.html">Francis Glassborow</a></p> </i> <b> <h2><font face="Arial"><a name="Language Development —The Problem with const">Language Development —The Problem with const</a></font></h2> </b> <p>The exact route by which things have become part of C or C++ is often shrouded in private interactions. Throughout much of the development of ISO Standard C and pre-standard versions of C++ Brian Kernighan and Bjarne Stroustrup were separated by a few feet of corridor. That means that ideas were certainly being swapped back and forth as both language designers have a high regard for each other.</p> <p>The public position has always been that <font FACE="Courier New">const</font> was an invention by Bjarne Stroustrup and that volatile was the invention of some member of J16. There were several motivations for introducing const into C++, probably the biggest was to couple it with references to allow passing of arguments that would behave much like value arguments whilst having the efficiency of a pass by pointer.</p> <p>Once the decision had been made to provide const reference parameters, the grammar of the language almost inevitably led to other uses of <font FACE="Courier New">const</font>. But the point to note is that in order to support the semantics of const references C++ also needed to require const correctness. By that I mean that use of an object via a <font FACE="Courier New">const</font> guaranteeing name must honour that promise.</p> <p><font FACE="Courier New">const</font> correctness has a hidden cost in that a return value based on a <font FACE="Courier New">const</font> qualified object must retain that qualification. The consequence is that objects can acquire <font FACE="Courier New">const</font> protection in their passage through a function. One of the classic examples is found in the Standard C Library; <font FACE="Courier New">strstr()</font>. This function takes a pointer to a <font FACE="Courier New">const</font> array of <font FACE="Courier New">char</font> and returns a pointer to an array of <font FACE="Courier New">char</font> in C. That will not do in C++ because the return value is based on the pointer provided as an argument. The function promises to prevent the data pointed to from being changed, but the return does not support that promise.</p> <p>C++ has a simple fix for that problem; it uses a pair of overloaded functions. One function takes and returns a <font FACE="Courier New">char const *</font> and the other takes and returns a <font FACE="Courier New">char *</font>. There is also a basic C++ programming idiom that effectively allows the same source code to define both functions:</p> <div align="center"> <center> <table border="1" width="100%"> <tr> <td bgcolor="#FFFFFF"><font FACE="Courier New">char const* strstr(char const*,char const*);<br> inline char* strstr(char* s1,char const* s2)<br> {<br>   return const_cast<char *>(strstr(const_cast<char const *> s1, s2));<br> }</font></td> </tr> </table> </center> </div> <p>which effectively instructs the compiler to use the implementation of the <font FACE="Courier New">const</font> version for the non-<font FACE="Courier New">const</font> one if the first argument is not <font FACE="Courier New">const</font>. but return a plain <font FACE="Courier New">char*</font>.</p> <p>The point I am making here is that C++ <font FACE="Courier New">const</font> correctness relies on function overloading in order to work. It is not immediately obvious to the casual observer that <font FACE="Courier New">const</font> correctness has anything to do with function overloading.</p> <p>Remove function overloading and you are faced with a very different set of circumstances which C programmers call <font FACE="Courier New">const</font> poisoning.</p> <p>Even implementing such potentially helpful concepts such as <font FACE="Courier New">const</font> comes at a cost. Next time you find yourself asking for some new feature to be added in the next revision of your favourite language, stop and ask yourself what hidden costs there may be. I happen to think that C would benefit for a controlled form of function overloading, but that is another story that I will leave for next month.</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> <h2><b><font face="Arial"><a name="Spyware and TurboTax">Spyware and TurboTax</a></font></b></h2> <p>Tax season is rapidly approaching. Paying taxes often involves a complex series of forms and rules that are beyond any single person’s ability to comprehend and fill out correctly. That is why many Americans need to pay an additional tax in the form of purchasing tax software or tax advice. (Think of the savings if the tax system was simpler and more equitable.)</p> <p>We now have an additional quirk in dealing with our taxes. As reported by Walter Mossberg in the Wall Street Journal on January 30, 2003, we also have spyware to contend with when we try to use the latest version of TurboTax from Intuit.</p> <p>It seems that Intuit now treats all its customers like criminals. Intuit believes that you are intent on stealing their software by handing out copies of the software to other members of your family. To prevent this criminal behavior, Intuit secretly installs a spyware program from Macrovision called SafeCast. It supposedly ensures that TurboTax is only running on the one PC on which the mandatory “activation” occurred. You activate your copy of TurboTax when you register it online. This process then secretly installs the spyware program and you are exposed. By the way, this spyware program is not uninstalled when you remove TurboTax, nor does it cease operating when tax season is over. To defend the indefensible, Intuit has since claimed that no personal information, like income and expenses, are sent anywhere—only program usage is monitored. Yea, we should believe a company that treats us like criminals and spies on us in secret. All this while handling our most confidential information.</p> <p>I agree with Walter Mossberg—get the excellent competing product TaxCut by H&R Block. It is less expensive and it does not spy on you. Also your whole household is licensed to use it.</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><a name="Extreme Programming Perspectives">Extreme Programming Perspectives</a> </b></i>by Michele Marchesi, Giancarlo Succi, Don Wells, and Laurie Williams, Addison-Wesley, 2002, ISBN 0-201-770055-9</p> <b> <p>Rating</b>: Highly Recommended<br> <b>Reading Level: </b>Easy.</p> <p>This book is a comprehensive collection of articles by many authors on various aspects of Extreme Programming.</p> <p>No specific experience in any one programming language or environment. It is assumed that the reader has significant programming and architecture experience.</p> <p>The style is very readable from all authors. This speaks well of the authors, editors, and XP in general. Bear in mind that XP considers clear communication and expression an essential component of a successful project.</p> <p>I do not have years of XP experience. I think, in general, that it is difficult to define precisely the XP "domain". The book presents a wealth of perspectives by people who understand and convey the topic well. I am pleased by the coverage.</p> <p>I found no errors worth mentioning. The content of the book was not so technical that errors in a sample algorithm would be an issue.</p> <p>Extreme Programming is an approach that I think has much merit. Its adoption, however, encounters resistance due to misconceptions about what it is and the zealous behavior of its practitioners. This book serves both the potential adopter and the practitioner by viewing XP from many angles and answering tough questions.</p> <p><i>— Al Bauer </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="Bottomed Out?">Bottomed Out?</a></font></h2> </b> <p>I have included two figures in this month’s column. I was stuck by the similarities of seemingly independent IT areas: job openings by type of computer language; and job openings by type of platform. In both cases and across most series, there seems to be a flattening out and even a slight increase in job openings. Also, this has gone on for more than three months. I also have antidotal evidence that things may be turning around. I and some of my acquaintances have been approached about job openings without explicit effort on our part.</p> <p align="center"><img border="0" src="images/2003-02-Fig01.gif" width="472" height="330"></p> <p align="center"><img border="0" src="images/2003-02-Fig02.gif" width="472" height="321"></p> </td> </tr> </table> </body>