Reader I/O Circuit Cellar has always invited readers to send in their comments about the magazine, the Web site, current contests, or whatever it is we're doing at the time. Rather than have the Reader I/O page in the print magazine, we've moved that feature to our Web site in order to expedite the posting process. We hope you'll stop by to drop off your comments, see what other readers are saying, or get any updated Editor's Notes that may pertain to articles in past issues. January 3, 2007 During the final proofing stage of the editorial process, the editorial staff inadvertently inserted three typos into Tom Cantrell’s January 2007 article, “Hot Chips 18” (Circuit Cellar 198). Please note the following corrections: Page 78, column 2, paragraph 3: “10 Kbps” should be “10 KBps” Page 78, column 3, paragraph 1: “12.5 Mbps versus 10 Kbps” should be “12.5 MBps versus 10 KBps” Editor’s note: According to IBM, the RAMAC transfer rate was “8.8 Kbytes/s” (http://www.research.ibm.com/journal/rd/255/ibmrd2505ZC.pdf). Page 83, Table 2: "Xilinx Vertex-4" should be "Xilinx Virtex-4. Our apologies go out to our readers and Tom Cantrell. April 27, 2006 Correction: In the caption for Figure 2, "10-kW" should be "10-kW," (Carlos Cossio, "Mobile Phone Book: M16C/62P-Based Data Backup System," Circuit Cellar 190, May 2006, 15). February 13, 2006 Correction: In the following sentence, "Motorola" should be "Freescale": "Notably, the new chips allow Motorola to compete in the low-pin-count (8- and 16-pin parts in a variety of packages) and low-price (less than $1) space." And, "It was a competitive part way back when, and the latest incarnations and competitive today" should read "It was a competitive part way back when, and the latest incarnations remain competitive today" (T. Cantrell, "Something Old, Something New," Circuit Cellar 187, February 2006, 41, 42). Letter to the Editor February 5, 2006 In Chris Cantrell’s article, “Embedded Object-Oriented Programming,” [Circuit Cellar 187, February 2006] there are a few issues presented that may be misleading. C++ has an “inline” keyword that allows functions to be defined in shared header files and act like C-preprocessor macros. Class member functions which are defined within the class definition are automatically “inline” as per ISO C++. In the article, Chris states that the “getX()” function takes more execution time than simply accessing the member data directly. A properly optimizing compiler would not distinguish between these cases. The delay is likely due to issues with his use of virtualism in other portions of his code. In C++, member functions which are non-virtual needn’t be in the vtable for any given object because the address of the function-to-call is known at compile-time. It is because Chris’ demo program has set “getX()” to be virtual unnecessarily (but used to make his point) that there is run-time overhead for calling this function. The most egregious error of the article is that the system heap must be used in order to reap the benefits of polymorphism; this is not so. The only restriction on polymorphism is that the object-to-be-used is given as a pointer or reference. The program could easily create objects on the stack, and then pass them to a function that takes a reference to the objects’ common base class. This is how many aspects of the C++ STL are implemented. Chris refers to pass-by-value as “pass[ing] on the stack,” and pass-by-reference as “pass[ing] by a pointer.” He also does not mention references at all, which is itself a reason to use C++ over C. This shows a lack of understanding of C++ data-flow and polymorphism. The article has many good points, but because of its errors or omissions it would likely be misleading to a programmer unfamiliar with details of C++. Brian Sipos Editor’s note: The following letter to the editor from Chris Cantrell is a response to the letter to the editor from Brian Sipos (February 5, 2006) regarding Chris’s article, “Embedded Object-Oriented Programming” (Circuit Cellar 187, February 2006). Letter to the Editor February 7, 2006 There are way too many features in C++ to cover with a single article. My goal here was to discuss the bare fundamentals of a handful of major topics in Object Oriented Programming and show how they evolved from C beginnings. Brian points out several useful C++ features that spring naturally from the article’s discussions. I purposefully avoided the optimizer (and “inline”) in this article in order to compare/contrast: 1) directly accessing data, 2) accessing data through a regular function, and 3) accessing data through a virtual function. I purposefully used virtual functions and abstractions to measure the effects on the run-time as discussed. Let the reader beware: the demo program is not intended to be an example of good C++ programming but rather a learning tool to distil and examine the OO features discussed in the article. Thanks Brian: I stand corrected on the sentence, “You also have to use the heap if you want to use polymorphism.” I should have said: “You also have to pass by pointer if you want to use polymorphism.” The remainder of the discussion (and the code) is correct. Brian points out that you can pass pointers to objects that live on the stack, though you must really be careful doing so since the objects get destroyed with the stack frame. True composition designs (as championed by the “Gang of Four” in their book Design Patterns [E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Boston: Addison-Wesley Professional, January 1995]) involve long-lived objects with lots of connections among themselves that seem to insist on living in the permanent heap. But this discussion is beyond the scope of the article, and thus I avoided it. The point of this section of the article was that no matter where an object lives, you have to pass by pointer for polymorphism to work. Brian also brings up “references,” which are still passing by pointer instead of value, though with a different syntax. The Scott Meyers books Effective C++ [S. Meyers, Effective C++: 55 Specific Ways to Improve Your Programs and Designs, 3rd ed., Boston: Addison-Wesley Professional, May 2005] and More Effective C++ [S. Meyers, More Effective C++: 35 New Ways to Improve Your Programs and Designs, 1st ed., Boston: Addison-Wesley Professional, December 1995] give a good discussion of when to use references and when to use pointers, but at run-time there is no difference. They both result in the same binary executable. As Brian alludes to, however, there are subtle advantages to using “references” you should explore. I definitely think the STL is beyond the scope of this article! In fact, the STL is not even an OO framework. For interested readers, the book C++ Primer Plus Fourth Edition by Stephen Prata [S. Prata, C++ Primer Plus, 4th ed., Indianapolis: Sams Publishing, December 2001] discusses the difference between OO approaches and Generics (the “GoF” hold a similar discussion in their Design Patterns book). For instance, even though an object is passed by pointer (er, reference) to an STL container, it is copied into the collection’s memory using the container type’s copy constructor, which is exactly what this article discusses. Find-operations in the containers use the equals-operator, which is definitely not polymorphic even if you tag it “virtual” (that’s an interesting OO discussion in itself). In my own defense, I do have a firm grasp on C++ and polymorphism; I just chose to keep the examples and discussions in this article narrowly focused on the details of a few key OO features and their impact on limited (embedded) platforms. What I failed to do in this article, and what Brian has done with his comments, is point out that there is a rich universe of C++ features out there waiting to be explored. Chris Cantrell November 16, 2005 Editor’s Note: Lindsay Meek's #180 July 2005 article—The microcontroller in Figure 3 should be labeled CY8C27443 not CY8C2644.