Dear DDJ,
I was disappointed by Al Stevens' "C Programming" column in the January 1996 issue, at least the part that dealt with C++.
Al starts out lamenting the short comment period that the C++ Standard committee allowed. I agree with his sentiment, but unfortunately, if the rest of his comments on C++ are any indication of what the committee would have had to put up with, then I am afraid I side with the committee.
First there was ifstream::read and ofstream::write. Maybe the length parameter should be type size_t instead of int, but ifstream/ofstream are supposed to read/write "characters" from files, therefore, having the other parameter be a char* (instead of a void*) seems appropriate to me. In C++, the correct way to read/write objects to/from an fstream is to define operator>> and operator<< for the class, not just arbitrarily cast things to either void* or char*.
Then Al brings up "A New for Statement." I stood up and cheered when I read that the committee had changed the scope of a loop index declared in the first expression of the for statement. The fact that the committee had the guts to fix something that was clearly wrong--in spite of the whining about breaking code that they were undoubtedly going to get from hackers who have been exploiting this hole in the language--gave me confidence that the standardization effort was going to give us something worthwhile. For years, my own coding style guide has had a sentence that reads "If you need access to the loop index outside of the loop, then declare it OUTSIDE OF THE LOOP." The suggestion that this change breaks a lot of code does not move me. Locating all the for statements that need to be changed, and moving the declaration, is a straightforward mechanical exercise.
Finally, there is the "enum as a Type" problem. I will admit that my reading of the April 1995 draft has not always been correct, but this case seems straightforward enough. An enum is a type; it is not an arithmetic type; and the increment operator can only be applied to arithmetic types (or pointers other than void*). So I have to say that it seems that Visual C++ 4.0 has got it right. More importantly, this is logically what you would expect. In the general case, enumeration constants do not have to be monotonically increasing, uniformly spaced, or even discrete. Therefore, there is no logical meaning for increment when applied to a variable of enumeration type. Again, I am sure this breaks a lot of code since the committee went to the trouble of specifying increment for type bool (I can not understand the appeal of writing f++; instead of f = true;). Unfortunately, the code was broken anyway, all the committee has done is make the compiler vendors flag it as an error.
Maybe it was being forced to write Cobol for two years, but I just do not understand the apparent mentality of programmers who think that minimizing the number of characters used in the source somehow produces better programs. The real problem with the C++ standard is not going to be fixing all the code it breaks, but convincing all the latent C programmers that there still are enough language loopholes left in C++ that they can use to write programs.
Jack W. Reeves
76217.2354@compuserve.com
Al responds: First: So, fstream objects are meant for character input and output only? Why do you suppose the specification includes the ios::binary open mode? And, overloaded insertion/extraction operators are the only correct way to read and write data? Makes you wonder why they included the read and write member functions. Sorry, we'll have to disagree on that one. Second: I'm glad that you like the new for statement declaration rules. I'm sorry that you think I'm a whining hacker because I like the old way. We disagree on both halves of that issue. The old way worked and was okay, and, to paraphrase a former president, "I am not a whining hacker." Thirdly: I agree that enums could be a type, and do not mind that the rules might have changed, but I disagree that the specification is clear and unambiguous about it. So, you get two thumbs down and a horizontal thumb. But this exchange is about language-feature preferences--yours and mine. Programmers are expected to engage in civil disagreement about those kinds of issues. The point of the original piece, however, was to use those arguments, not merely to express my opinions about them, but also to show how the committee applies the broken code position when it suits their purposes and ignores it when it does not.
Heed these reflections from a proud "latent C programmer" and former Cobol practitioner of many more than two years. When you take a stand and "side with the committee" against anyone who calls into question their policies and decisions, remember this: There are no sides to be taken. When the air clears and the specification is set in stone, there will not be winners and losers. We will all be in this together.
Dear DDJ,
I have not programmed in Basic since I installed OS/2 almost three years ago and discovered REXX, so I am not about to comment on the algorithms Homer Tilton presented in his January 1996 letter to the editor. In addition, I have not programmed calendar conversions since my article "Calendar Conversions" was published in the late (lamented) Programmer's Journal (November/December 1990). The Basic program presented therein was for compiled Basic only, as it required long integers (not available in the interpreters then available) and used a separately compiled module of conversion subroutines. It did not require splitting the year on April Fool's Day. The program would calculate the day-of-week and Julian Day number for any date following January 1, 4713 b.c. for the Julian calendar; or following October 15, 1582 for the Gregorian calendar (the first day that calendar system was in use, anywhere), and the equivalent date in the other calendar system (if valid), starting from whichever calendar system was specified as an input parameter.
Just for the fun of it, I dug up my archived DOS-source code for that program (written for Basic PDS 7) and recompiled it to an OS/2 executable file. When I gave it the input parameter of 1/1/-4713, the program told me that Julian date January 1, 4713 b.c. was a Monday, that it was Julian Day 0, and that the equivalent Gregorian calendar date was invalid. So, Homer's calendar for January, 4713 b.c., as shown in his letter, is correct.
Murray Lesser
Murray.Lesser@f347.n109.z1.fidonet.org
Dear DDJ,
Bruce Schneier's article "Differential and Linear Cryptanalysis" (DDJ, January 1996) is the best I've read on that topic. He really has a gift for writing.
Dorothy Denning
denning@cs.cosc.georgetown.edu
Dear DDJ,
In his article "Animation Using the Netscape Browser" (Dr. Dobb's Sourcebook on Internet and Web Development, November/December 1995), Andrew Davison forgot a minor point: Netscape must be set to verify documents every time, or this will not work--Netscape will pull the documents from the cache rather than from the server.
Ed Carp
Dallas, Texas
ecarp@netcom.com
Dear DDJ,
I was interested to see the dates listed by Michael Doyle in his January 1996 DDJ letter to the editor. I too saw many demonstrations of executable content. The most memorable and vivid was an e-mail message I received from Keith Ohlfs in 1991 (he's the guy who made all those cool icons at NeXT). When I opened his e-mail message, a set of Display PostScript commands executed that:
Thor Heinrichs-Wolpert
Victoria, B.C., Canada
twolpert@ca.oracle.com
Dear DDJ,
My congratulations to Dean Clark on his well-written article, "Color Quantization Using Octrees" (DDJ, January 1996). As the author noted, the octree algorithm and Paul Heckbert's popularity and median-cut algorithms are those most commonly used for color quantization.
However, there are many other color quantization algorithms that have been presented in the computer science, image display, and photographic-sciences literature. Some offer better time or space performance, and others are optimized for quantizing color-video sequences. Interested readers can download a comprehensive bibliography of some 70 color quantization algorithm references as CQUANT95.ZIP from http://www.ledalitecom/library/cgis.html, or via anonymous ftp as /pub/doc/cquant95.Z from hobbeslbl.gov.
Ian Ashdown
iashdown@ledalite.com