2002-07

<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">July 2002 - Vol. 3 No. 7</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="2002-08.html" target="_top">[Next]</a> <a href="2002-06.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="#Append Utility">Append Utility</a> </p> <p><a href="#Editorial"><b>Editorial</b></a><br> <a href="#Hammers, Nails and Technology">Hammers, Nails and Technology<br> Preserving Your Rights with Art</a><a href="#Call for articles"><br> Call for Articles</a> </p> <p><a href="#Book Reviews"><b>Book Reviews</b></a><br> <a href="#Standard C++ IOStreams and Locales">Standard C++ IOStreams and Locales</a> </p> <p><b><a href="#Humor">Humor</a></b><a href="#eMail Signatures"><br> eMail Signatures</a></p> <p><a href="#Trends"><b>Trends</b></a><br> <a href="#Behind the rest of the country">Behind the rest of the country</a></font></p> </td> <td height="277" bgcolor="#FFCC99" width="612"> <b> <h1><a name="TechTalk"><font color="#000000">Tech Talk</font></a></h1> <h2><font face="Arial"><a name="Append Utility Critique"><font color="#000000">Append Utility Critique</font></a></font></h2> </b> <i> <p>By <a href="Author-AliCehreli.html">Ali Çehreli</a></p> <p><font FACE="Arial">[Last month, I published an Append utility that had some interesting properties. It also had some flaws. In an email, Ali did an excellent critique of my code. My responses are in italics - Reg. Charney]</font></p> </i><b> <h3><font FACE="Arial">Critique</font></h3> </b> <p>I've read the Tech-Talk column in June 2002 issue of ACCent. I enjoyed reading the article and understand it's usefulness. However, I see a number of places where we can make the code better, and sometimes even <b>correct</b>.</p> <p>While some of the notes below are unimportant and sometimes reflect only style preferences, I think some are very important. I will go through the lines of the code in the order they were listed in the article.</p> <p>There is a smaller program at the very end that attempts to do the same thing. I wonder if it has the scaling problems that you were referring to.</p> <table border="1" width="34%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">#include <stdio.h><br> #include <fstream.h></font></td> </tr> </table> <p>The standard C++ versions of the above files are:</p> <table border="1" width="34%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">#include <cstdio><br> #include <fstream></font></td> </tr> </table> <p>The versions used in the original article are pre-standard and at least not aware of namespaces.</p> <i> <p><font FACE="Arial">This is correct. Unfortunately, not all vendors have done this correctly.</font></p> </i> <table border="1" width="38%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">const int MAXBUF = 1024;</font></td> </tr> </table> <p>Some programmers prefer reserving identifiers with all capital letters for macros. Following their advice, I would have introduced the constant as:</p> <table border="1" width="38%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">const int maxBuf = 1024;</font></td> </tr> </table> <i> <p><font FACE="Arial">The original idea was so that manifest constant values would be readily apparent. For that reason, I continue to capitalize all my manifest constants.</font></p> </i> <p>Next,</p> <table border="1" width="38%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">class OFile : public Fbuf</font><br> <font FACE="Courier New">{ /* ... */ };</font></td> </tr> </table> <p>Public inheritance is used as an <i>is-a</i> relationship where the derived class <i>is a </i>type of the base class. I think <font FACE="Courier New">OFile </font>is not an <font FACE="Courier New">FBuf </font>but “is implemented in terms of” <font FACE="Courier New">Fbuf</font>. That type of <i><font FACE="Arial">relationship </font></i>is modeled either by a “has-a” relationship or by private inheritance. Besides, <font FACE="Courier New">FBuf </font>has no public interface that would warrant its public inheritance. Adding the advice of preferring containment of inheritance, I think a better design would be</p> <table border="1" width="38%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">class Ofile<br> {<br>   FBuf buffer_;<br>   /* ... */<br> };</font></td> </tr> </table> <i> <p><font FACE="Arial">I agree that private inheritance is more appropriate here than public inheritance. However, I was trying to illustrate the concept of using static base class members as a way of sharing data, so I did not want a “has a” relationship.</font></p> </i> <p>Next</p> <table border="1" width="45%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">class OFile : public FBuf {<br>   ofstream oF;<br>   char* oFN;<br> public:<br>   OFile(char* oFN_) : oFN(oFN_)<br>   {<br>     /* ... */<br>     throw oFN;<br>   }<br>   /* ... */<br> };</font></td> </tr> </table> <p>The member variable <font FACE="Courier New">oFN </font>is used to hold the name of the file to be thrown in an error condition. This design relies on the fact that the character buffer that holds the name of the file is still available at the point where the exception is caught.</p> <p>Even though <font FACE="Courier New">argv </font>will live longer than any object defined in <font FACE="Courier New">main</font>, throwing a <font FACE="Courier New">char *</font> may not work in general. A better approach is to throw <font FACE="Courier New">std::string and </font>catch with <font FACE="Courier New">std::string const &. std::string</font> always owns its buffer and need not rely on external data.</p> <i> <p><font FACE="Arial">Agreed</font></i>.</p> <p>Additionally, the exception thrown in the <font FACE="Courier New">OFile </font>constructor will never be caught in the program, because the <font FACE="Courier New">variable oF </font>in main, is not constructed within a <font FACE="Courier New">try </font>block.</p> <i> <p><font FACE="Arial">This was intentional. If I couldn’t create the output file, there was no reason to go on and I wanted to end the program.</font></p> </i> <p>Next,</p> <table border="1" width="82%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">oF.open(oFN, ios::app|ios::binary/*,filebuf::sh_none*/);</font></td> </tr> </table> <p>Unfortunately there is no standard way of locking a file for single access. <font FACE="Courier New">filebuf::sh_none </font>is an extension provided by some of the compilers.</p> <i> <p><font FACE="Arial">This is true, but all the systems that I know of have a similar mechanism to open files exclusively for output.</font></p> </i> <p>Next,</p> <table border="1" width="23%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">~OFile()<br> {<br>   oF.close();<br> }</font></td> </tr> </table> <p>It is not necessary to call <font FACE="Courier New">close </font>in this case since the <font FACE="Courier New">ofstream </font>destructor will be called for <font FACE="Courier New">oF </font>member anyway. In fact, it is not necessary to define the destructor for <font FACE="Courier New">OFile </font>because it does not own any explicit resources.</p> <table border="1" width="31%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">void write()<br> {<br>   if (oF.is_open())<br>   {<br>     /* ... */<br>   }</font></td> </tr> </table> <p>The check for the file being open in <font FACE="Courier New">write </font>is unnecessary, because the object would never have existed if the file could not be opened in the constructor. The reason for throwing an exception in the constructor is to avoid having incomplete <font FACE="Courier New">OFile </font>objects around. If we ever enter <font FACE="Courier New">write</font>, it must be for a valid object.</p> <table border="1" width="22%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">delete [] bp;</font></td> </tr> </table> <p>There is not an explicit <font FACE="Courier New">new[] </font>call in <font FACE="Courier New">OFile</font>, which corresponds to the line above. This fact points to the possibility that there is an ownership transfer somewhere in the code; but that transfer is not easily visible.</p> <i> <p><font FACE="Arial">The pointer bp is part of the base class Fbuf. Normally, I always clean up after myself. However, it would have been better to do this in Fbuf’s destructor.</font></p> </i> <table border="1" width="15%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">bp = 0;</font></td> </tr> </table> <p>Needing to clear a pointer that points to memory that has just been released is almost always a sign of a buggy program. Why did we need to clear the pointer? Is it because we've realized that we were calling <font FACE="Courier New">delete[] </font>more than once without an intervening <font FACE="Courier New">new[] </font>(double-delete)? If so, the bug that causes the double-delete must be identified and fixed.</p> <i> <p><font FACE="Arial">I strongly disagree here. This is defensive programming. There is no chance that this released memory will be used if the pointer to it is set to null. I always assume that someone else will maintain my code and I don’t want him to trip over this potentially very nasty bug. Think of it as protective redundancy.</font></p> </i> <table border="1" width="26%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">operator bool()</font></td> </tr> </table> <p>The reason for this operator is to check for more bytes in the input file. The standard idiom for such operations is to define an <font FACE="Courier New">operator void *</font> which provides the same functionality without the possibility of silly errors like using the object in arithmetic operations: A <font FACE="Courier New">bool </font>can be used in arithmetic operations but a <font FACE="Courier New">void *</font> cannot be.</p> <i> <p><font FACE="Arial">Agreed. You have a very valid point.</font></p> </i> <table border="1" width="38%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">bp = new char[bSZ];<br> if (!bp)<br>   throw iFN;</font></td> </tr> </table> <p>It is not the standard behavior for <font FACE="Courier New">new </font>to return 0 in case it fails to allocate memory. The standard behavior is to <font FACE="Courier New">throw std::bad_alloc</font>. For this reason, the program will never reach the line <font FACE="Courier New">throw iFN</font>: <font FACE="Courier New">new </font>will either succeed and the <font FACE="Courier New">if (!bp)</font> block will never be executed, or fail and <font FACE="Courier New">if (!bp)</font> will never be executed.</p> <p>There is a no-throw version of new though, but this behavior must be explicitly specified:</p> <table border="1" width="38%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">bp = new(nothrow) char[bSZ];<br> if (!bp)<br>   throw iFN;</font></td> </tr> </table> <i> <p><font FACE="Arial">Agreed, but not all vendors do it right.</font></p> </i> <table border="1" width="84%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">printf("\n\nUsage: append in-file1 [ , in-file2 ]...");</font></td> </tr> </table> <p>It may be better to use <font FACE="Courier New">argv[0] </font>as the name of the program in the message above. This would be more general, in case someone built the application under a different name than <font FACE="Courier New">append</font>.</p> <p>A smaller version that might be useful:</p> <table border="1" width="99%" bgcolor="#FFFFFF"> <tr> <td width="100%"><font FACE="Courier New">#include <fstream><br> #include <iostream></font> <p><font FACE="Courier New">int main(int argc, char * argv[])<br> {<br>   //* check cmd line args<br>   if (argc < 3)<br>   {<br>     std::cerr << "\n\nUsage: " << argv[0] <<"in-file1 "<br>                              "[ , in-file2 ]..."<br>                              "output-file\n\n";<br>     return 1;<br>   }<br>   std::ofstream oF(argv[argc-1], ios::out | ios::binary | ios:append);<br>   // loop over each argument,<br>   // except the last argument<br>   for (int i=1; i != argc-1; ++i)<br>   {<br>     ifstream iF(argv[i],ios::in | ios::binary)<br>     oF << iF.rdbuf();<br>   }<br>   return 0;</font><br> }</p> <p> </td> </tr> </table> <i> <p><font FACE="Arial">Without the </font><font FACE="Courier New">try...catch </font><font FACE="Arial">block, there seems to be a savings of one line. However, I believe your use of the </font><font FACE="Courier New">rdbuf() </font><font FACE="Arial">function is problematic here. You are writing from the input buffer without first reading anything. Some implementations read some portion of the file into an internal buffer when the file is first opened for input, but this is not “standard” behavior. </font><font face="Courier New">rdbuf() </font><font FACE="Arial">may actually return a dummy until the first read is executed successfully. Also, a failure to open any input file terminates the program, while using the try...catch block handles this situation and allows the remaining input files to be read.</font></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> <h2><font face="Arial"><a name="Code Critiques">Code Critiques</a></font></h2> </b> <p>When operating as a “lone wolf”, one of the things I miss most is someone to critique my work. For that reason, I like the idea of Code Reviews, Extreme Programming, and Agile Methodology. Ali Çehreli has done me the kindness of reviewing my code from last month any pointing up a number of issues. Many of them are valid and extremely valuable. My responses (excuses ;-) are included in the article.</p> <p>Amongst our ACCU members, we also have small book review groups. They meet to discuss the latest thinking in programming and design methodology. Much of what Ali has written is reflected in his keeping up-to-date in the current thinking on C++ programming. I must own up to being older and of writing in the “old” style with a sprinkling of some of the new paradigms, like exception handling.</p> <p>There are two things worth noting here. I have tried to use a variety of compilers to test the code I wrote and I am still having trouble with cross-compiler compatibility for standard C++ code. Second, even such a seemingly small and simple program taught me a lot when I had someone else look at my code.</p> <p>Thus, if you are interested in increasing your programming and design skills, set up a programming skills group and also actively seek out peer review.</p> <h2><b><font face="Arial"><a name="Welcome to Accent Technology!">Welcome to Accent Technology!</a></font></b></h2> <p>It is with great pleasure that I am able to welcome Accent Technology (www.accent-tech.com) as a sponsor for this newsletter. They provide professional grade IT training to the Silicon Valley. Also, some of you may already know that Accent Technology provides both the ACCU with space for our monthly meetings and the SVLUG with space for their monthly InstallFest. Again, thanks to the terrific folks there and their President, Tom Currier.</p> <h1><a name="Book Reviews"> <b> <font color="#000000">Book Reviews</font> </b> </a></h1> <p><b><i><a name="Metadata Solutions">Metadata Solutions</a>: Using Metamodels, Repositories, XML, and Enterprise Portals to Generate Information on Demand</i></b> by Adrienne Tannenbaum,Addison Wesley, ISBN 0-201-71976-2</p> <p>Recommendation: This is an excellent book and is well worth reading.</p> <p>As this book's subtitle accurately indicates, this well-written book ranges over considerable topical territory. (However this book generally avoids the commonly related syndromes of useless superficial coverage or endless disjointed details). The central theme and big picture involves using a systematic metalevel conceptual framework for designing, fixing, and managing internet accessible data warehousing systems. (However this book also deals with many other less demanding applications along the way.) This structure leads to a well-organized treatment of many related subtopics that are illustrated with many useful examples. Technical issues are usefully oriented within the context of the business aims (and related concerns) that they ultimately serve, and due diligence is given to people-ware issues.</p> <p>An adequate technical review of this book requires a long article, which is beyond the scope of this brief review. This book may be regarded as something of a course concerning pragmatic principles of (for lack of better words) "advanced self-describing dynamic data structures". This book contains much information that should be useful for many common types of data centric program development in general and it could also serve as a handbook for dealing with various problems involving metamodels, repositories, XML, and enterprise portals.</p> <p>Before getting into some of the other topics covered, here is a severely condensed description of the key buzzwords (derived from the book's handy glossary). Metadata describes the formats and characteristics of the base level data; meta-metadata similarly describes meta data (which is useful for generic tool-based processing and accessing). Metamodels are graphic representations of a system of metadata requirements, organized variously according to the perspectives of metadata source, classification, or usage. Meta-metamodels are the counterparts of metamodels for meta-metadata, and these represent metadata solution views for integrating various tools or application-specific metamodels. Everything in the book revolves around this conceptual framework, and many examples and diagrams explain and demonstrate the nature and utility of this framework.</p> <p>To attract wider interest beyond the apparent target audience suggested by the title, I can summarize some of the topics covered although, I don't think I can do better than the publisher's excellent summary from the back cover, so my heavily edited version of it follows.) The topics include:</p> <ul> <li>The benefits and drawbacks of various metadata-based technologies and standards.</li> <li>How to implement and maintain various metadata solutions.</li> <li>Comparative reviews of conventional approaches to modeling, databases, and data warehousing.</li> <li>Examination of vendor, standard, and custom metamodels.</li> <li>The meta-metamodel and the impact of extensibility.</li> <li>Types of metadata solutions, including repositories, XML-based exchange, and enterprise portals.</li> <li>Metadata security. * Organizational structures for creating, managing, and maintaining metadata solutions.</li> <li>Ways of expanding existing metadata solutions.</li> </ul> <p>While some of the terminology used above may have a "silver bullet" ring to it, the practical issues of metadata solutions for database and data-integration issues are repeatedly emphasized and elaborated.</p> <p><i>— Conrad Schneiker</i></p> <i> <b> <h1><font color="#000000"><a name="Humor">Humor</a></font></h1> </b> </i> <b> <h2><font FACE="Arial"><a name="eMail Signatures">eMail Signatures</a></font></h2> </b> <p>C++ haters point out that even the name of the language contains a bug: "After all, it really should be called ++C, since we only want to use a language after it's been improved." -- Cay Horstmann & Gary Cornell, “Core Java”, Sun Press</p> <p>—Nate Campi email signature</p> <i> <p>[Ed. If you come across signatures that you think are humorous, send me (</i><a href="mailto://editor@accu-usa.org">editor@accu-usa.org</a>) <i>a line. Other readers may enjoy them too.]</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></p> </i> <b> <h2><font face="Arial"><a name="A Small Positive Bounce">A Small Positive Bounce</a></font></h2> </b> <p>We have all heard about the Enron, WorldCom and Xerox scandals recently and the massive layoffs these entail. However, the overall picture in the last six months looks more positive than the bad news seems to imply. Figure #1 shows that more jobs have become available since last month and is the most positive it has been, both locally and nationwide.</p> <p align="center"><img border="0" src="images/2002-07-Fig01.gif" width="466" height="291"></p> </td> </tr> </table> </body>