Dear DDJ,
Thanks to Phil Mitchell for his "Programmers Bookshelf" review of my book Beyond Programming (DDJ, August 1996). I was very much impressed with his description of my work with TEDIUM. He clearly understood what I was (am?) doing; I'm not sure I could have described it better myself. I'm sorry he didn't like the first eight chapters, but I'm not surprised. They were written for an academic audience, which -- in my experience at least -- seems to have a limited understanding of these ideas beyond the buzz-word level. Thus, I plead guilty to "arid," but I hope not "superficial."
Regarding Phil's comments on SEE, I elected not to comment on what I consider to be software development in the old paradigm. The thrust of the book was to be [focused] on how we ought to develop software in the future. My impressions of much of the SEE work is that the concern here is on improving how we do it now. Therefore, evaluations of other people's work would be unfair in that I believe that they are addressing a different problem.
Bruce I. Blum
Columbia, Maryland
Dear DDJ,
I was sitting here "training" (that is, perusing the January 1997 DDJ while chewing lunch) and, upon reading Jonathan Erickson's editorial, wondered if ISDN "alters communication by breaking information into packets for transmission" as the SPA's remarkably self-serving explanation would have it of TCP/IP. ISDN digitizes voice; so, if I get a nasty phone call on my ISDN line, I can sue Bell Atlantic as the "publisher," right? Yeah, right.
Christopher C. Reed
Christopher.C.Reed@m1.irs.gov
Dear DDJ,
If, as Jonathan Erickson says in his January 1997 editorial, the SPA bases its stance on the fact that ISPs (and the Internet) break data into packets and reassemble it for presentation, then I think the SPA should receive some quick education on how the current "analog" telephone system works in this country. In a nutshell, at the central-office switch (the one on the other end of the wires coming out the back of your phone) your phone conversation is converted from an analog signal into a stream of digital packets which are (likely) intermixed with packets from other, concurrent users of the system, transmitted digitally across a wide-area network, and reassembled into an analog signal at the receiving end. Remarkable similarity to the SPA's characterization of the Internet, no?
Theodore A. Jump
tjump@spgs.com
Dear DDJ,
After reading Edward Sitarski's September 1996 "Algorithm Alley" on hashed array trees, I'd like to say there is good news -- it's possible to use malloc/realloc/free routines in C++ and still have a constructor/destructor called. It's 100 percent portable, legal, and exhibits good style. The trick is that it's possible to call the constructor/destructor of an already allocated memory block. Example 1, for instance, has zero overhead and is simple and portable. So, this HAT class is absolutely obsolete.
Poul A. Costinsky
poul@wizsoft.com
Ed responds: Poul, Thanks for your feedback. I have to admit that I was not aware of the trick that you brought up in your letter. However, I would like to bring a counter example to your attention where your method will not work. This counter-example would make it inappropriate to use your method in a general-purpose C++ template toolkit, as it can cause dangling pointers and memory corruption.
The root of the problem is that the call to realloc will eventually move your array of objects in memory. This is a violation of encapsulation that some objects may never recover from, especially objects that have pointers to internal fields. Consider the class in Example 2, which uses a sentinal element to avoid special-case comparisons to speed up doubly linked list manipulations.
Clearly, if realloc moves this object in memory by byte copying, there is no way that the values of "head" and "tail" will be updated, and they will now be "dangling." At the very least, this means that the isEmpty() member function will no longer work properly, since the address of the sentinal field has changed. Worse, a modification to head or tail will now corrupt memory.
This problem will happen anytime an object has a pointer to an internal field. True, this is not an extremely common case, but it does show that your method is unfortunately not 100 percent portable, legal, and in good programming style. Isn't it always time bombs like this that seem to show up just before a release?
Perhaps HATs are a useful and 100 percent reliable alternative to variable length arrays after all.
Poul then responds: Ed, you're right that realloc can move the memory chunk. The immediate solution I use isn't portable, but Win32 specific -- I'm using local heaps, and LocalHeapRealloc has a flag preventing moving memory.
Another point: I never use things like a pointer to an internal field. I think it's a dirty trick, so my personal definition of good style remains consistent.
You're right that HATs support this approach, so they may be useful for somebody.
Inventing the Computer
Dear DDJ,
I would like to comment on the letter from Phil Mitchell in the July 1996 DDJ concerning the invention of the computer.
I think it is unfair to bend historical facts only because they happened in the wrong land at the wrong time. Konrad Zuse was the creator of the world's first fully automatic, program-controlled, and freely programmable -- with binary floating-point arithmetic -- working computer. This machine, the Z3, was in operation in 1941. Zuse's diaries from 1937 already contain advanced ideas as stored programs and parallel execution of operations, although these concepts were not realized. The Z3 was destroyed during the Second World War, but a reconstruction is shown in the Deutsche Museum in Munich. I don't think that anybody who has actually seen the machine would call it a "calculator" (in a discriminating way) instead of a "computer."
Bernd Warmer
Aachen, Germany
100621.263@compuserve.com
Year 2000
Dear DDJ,
I am maintaining a list of articles about the year-2000 or century problem in CompuServe's PCPROG forum (YR2000.TXT, library 13). In addition to your "Tick, Tick, Tick" editorial (DDJ, June 1996), which I am including in the next revision of the file, I have thus far found 17 articles on the problem in major newspapers, computer magazines, and business journals.
I disagree that the cost of modifying programs to be "year-2000 compliant" can be measured in terms of the number of lines in a program. Instead, notice that year data do not appear randomly throughout a program. They can only enter at fixed points (user input, data files, and the like) and then flow from these lines to other lines. A programmer can trace year-data flow to a subset of program lines and then needs to check or modify only those lines. (The only complication is that some languages allow aliases that are hard to detect. For example, variables can be renamed when Fortran common blocks are included into other routines.) As a result, a million-line program may require no more effort to fix than a thousand-line program.
As for solving the century problem, one must, of course, decide to represent years using either two or four digits. If four digits are used, the task is done once input years are converted to four-digit numbers. If, instead, two-digit years are used, then the program must convert years to four digits for each year-related calculation and change these calculations so that they expect four-digit inputs. More details are in YR2000.TXT.
David Wincelberg
71573.1023@compuserve.com
DDJ