I see that Randall Bart has raised the question of C++ vs. ++C. My own understanding is that the language is so named because every time you think you've finished learning it Bjarne adds a new feature.

Yours faithfully,

Scott Wheeler
BMT Research, Orlando House
1 Waldegrave Rd.,
Teddington, Middx
UK TW11 8L2

Wish I'd said that first. — pjp

Gentlemen;

It seemed good to take this opportunity to thank you for the work your staff has done this past year, and the appreciation many of us have (who don't write) for the quality of The C Users Journal. As a CPA, and accounting software developer, each new monthly issue frequently discusses and answers a current concern of mine. I can't tell you the number of times an article appeared at exactly the moment I needed the information. True, many articles are over my head and I marvel at how so much can be written about something I know so little about.

It also seemed good to nominate Mr. Leor Zolman as CUJ Writer of the Year. This in no way slights the efforts of the others, but my vote is based on the following criteria:

Appropriateness and general usefulness of subject: A.

Scope and technical considerations covered: A.

Ability to adapt subject material to other applications [portability]: A.

Tutorial content of material and usefulness in teaching C language concepts and capabilities: A

Humor and 'tongue in cheek' writing style (a spoonful of honey makes the medicine go down): A

Future subjects that would be of interest to me and perhaps others are suggested for your consideration, and include:

DOS TSRs: For example, how would one adapt Mr. Robert Bybee's article "A Portable VMS-Style Input Line Routine" to function as a TSR, similar to Peter Norton's NDE referenced in the article.

Keyboard I/O: A routine for polling the keyboard buffer. CUJ had an article on this subject some time ago, but it either did not go far enough or was beyond my ability to understand. The scope of the routine would be in two parts: (1) the ability to capture user keystrokes from an application and log them into an ASCII script file (perhaps subsequently edited by the user), and (2) the ability to call this routine and load the named script file into the keyboard buffer. In this way, users should be able to run repetitive applications or set up a series of applications (reports) to be chained together and run as a batch.

Batch File Compilers: Sometime ago I downloaded a batch file compiler from CompuServe, written by Douglas Boling (PC Magazine Ziff Communications). The language concepts I think that are required should make an interesting article. (I would love to know how this program works.) The input file consists of a standard W S batch file which is then compiled on the fly and a .COM file written to disk. How is this done?

Help Compilers: Beginning with standard documentation files (ASCII) as might be produced by a word processor, how would one build a compiler to translate ASCII files into an indexed binary format. The help utility program would access a file name passed on the command line, display an index for user selection, then handle paging and text display with keyboard control. Based on Leor's current article, this should be a piece of cake for him to take on as his next project. (You're welcome, Leor.)

Enclosed with this letter is my subscription renewal and disk order for processing.

Thanks again for your quality work in past years and may this year generate even more success for R&D Publications.

William C. Moench, CPA
North Gate Software
29204 Knickerbocker Rd.
Bay Village, Ohio 44140

It's always nice to hear when we do something right. Thanks for writing. — pjp

Leor responds:

Gee, if they'd given me report cards like that when I was a student at MIT, perhaps I wouldn't have dropped out! On the other hand, this kind of feedback probably means more to me than any real report card I've ever received. Thank you much.

I find it difficult these days to sit down and write a program just as an intellectual exercise; usually, I have to have an actual need for the program before I'm motivated to write it (that's partially why I have resisted getting into into programming Windows; the other reason, a lack of elegant development tools, however, seems to finally be lifting...) Most of the material for Illustrated C derives from applications I've written and put into service pretty much as they appear in the column and, now, the book as well.

Incidentally, when bugs pop up, it's usually because the program hadn't gotten enough use yet. I'm too scatterbrained to debug by inspection; I have to debug by "using" — yes, otherwise known as trial-and-error. Plus, I'm a perfectionist. If nothing else, that makes for an entertaining development cycle. Well, in the immortal words of our distinguished publisher, "OK, I'm done."

Dear Mr. Phillips:

I very much enjoyed Part 5 of your series on Image Processing. It has stimulated some creative thought processes in me and for that I thank you. I did notice one problem with your examples which caused me to write this letter. The discussion below will clarify the situation.

The Kirsch, Prewitt, and Sobel transform sets are designed to detect edges in only one of the eight compass directions. As such, they can only be applied to the original image and can not be cascaded. The reason for this is that each individual transform is designed to REJECT and REMOVE information from its output which does not correspond to a gradient in the direction of interest. I noticed in the photo examples that the images had a distinct bias in favor of one gradient over the other. For example, the right edges of dark objects are shown but the left edges of dark objects are missing. This is due to the fact that you have applied the transforms in cascade. The correct use of these transforms dictates that they each be applied to the input image and then the results analyzed.

It should be noted that it is not possible to merely sum the outputs from the eight transforms of the Kirsch and Sobel sets since this would result in values of zero. With these sets however, it is possible to accumulate the absolute value of the transform output. Since the transforms with opposite compass directions create symmetrical output, it is only necessary to use the absolute value of four patterns. The strong negative output of the one direction matrix provides the detection capability previously provided by the opposite transform. The output of the eight Prewitt transforms may be summed to non-zero values but it may be advantageous to use the same feature of symmetry to avoid redundant calculation.

I hope that this comment is not too brief and that you find the information useful. Again thanks, and I look forward to your next article.

Sincerely,

Frank Evans
Intelledex Vision Products

Dwayne Phillips replies: Thanks for the comments.

Gentlemen;

I have just gone through the process of learning how to use TLIB, including 15 minutes on "hold" in a telephone call to Borland. As an ex-professor (of a technical subject), and as a novice C user, I feel it is necessary to make two comments and to editorialize on Mr. Pugh's answer to Mr. Sam LeFevre, of Idaho Falls, as presented in the October 1991 C Users Journal.

Mr. LeFevre introduced himself as a "novice Turbo C user," and asked for guidance in setting up his own library of functions. Mr. Pugh correctly advised him to use the TLIB program supplied with Turbo C. But then,

1) went on to hide the really important advice (global variables) in typical and unnecessarily complicated C (for a "novice") programming, and

2) omitted the bookkeeping: how does TURBO C access this new library?.

Comment 1: (Probably brought on by some 30 years of teaching) Why not keep it simple? Give the questioner a simple "Hello World" example that stresses library use by itself?

Comment 2: This second comment is much more important and is the result of my telephone call to Borland: Where does one put his library so that Turbo C can find the functions contained in it? The ease with which one can write and save header files (in the same directory as other header files are saved in) would imply that personal libraries could be saved in the library directory. This is not the case. Turbo C is "hard wired" to search only the Borland-supplied libraries. Path(s) to users' libraries must be supplied in make, or project files.

(TLIB does allow you to add functions to (or modify) a current Borland library, but this could prove a dangerous thing to do.)

Thus, when using the very convenient IDE, every program that uses a non-Borland library must be a project, and a project file must be written!

Access to your own library is not explained where it should be (not in the Borland manuals, nor in the two classic Turbo C Bibles by Barkakati), nor can I find it in any of the many Turbo C books that I have compulsively bought. Only H. Schildt, in his Turbo C, The Complete Reference, Borland-Osborn/McGraw-Hill, gives this little gem of information. Even here, a confusing (and extraneous?) "T" is introduced.

Indeed, this omission on the part of many authors who glibly write of generating one's own library makes me wonder how many have ever done so?

Owen Gailar
Professor Emeritus, (Purdue University)
345 W. San Carlos
Fresno, CA 93704

I have, and I had to learn all the things you and Ken summarized here. Thanks for the clarifications. — pjp

Dear Mr. Plauger,

I would like to respond to two items in the December CUJ.

First, with regard to C. Skelly's fascinating article, "Creating C++-Like Objects in C." I believe Mr. Skelly made two important points that are worth reiterating.

One, callback functions are the foundation of polymorphic behavior. Understanding this point makes it easier to design flexible systems in C. This point also clarifies a common misconception about C++. The virtual keyword is not free. There is an overhead associated with using virtual functions, which is exactly the overhead of the call by address mechanism.

Two well-constructed C libraries use subject-predicate naming conventions, instead of the more natural seeming predicate-subject. For example, Circle-Draw() is correct, DrawCircle() is incorrect. Having our function names sort on the object name Circle allows us to associate the functionality of the Circle structure with those functions that begin with that name. This system also has the nice property of sorting well in the symbol tables.

The second point I wish to address refers to Jack Purdum's letter on the define versus declare problem. I am surprised you don't get it. Stating a thing twice doubles the amount of work needed to maintain it. Any symbol addition in Mr. Purdum's example requires one source code modification, as opposed to the usual two. This problem occurs in a lot of places. Preprocessor tricks, which are all variations on the one given, can save days of hard boring labor in the course of a large project.

Sincerely,

Adam Greissman, President
Hermeios, Inc.
853 Broadway, Suite 1104
New York, NY 10003

I see both advantages and disadvantages in SubjectPredicate naming. I see both advantages and disadvantages in macros that let you declare a data object just once. That makes it hard for me to characterize any of these approaches as "right" or "wrong.," — pjp

Dear Mr. Plauger:

I would like to request an article discussing the NCEG extensions to Standard C be published. In addition, perhaps several articles discussing issues regarding their use.

As an avid reader of your column, I would like to know your opinions regarding text formatting packages, especially regarding nroff/troff versus the current crop of desktop publishing packages. Would you care to clarify it in an upcoming column?

Thanks for your help.

Sincerely,

Wen J. Chen
143-25 41st Avenue, #340
Flushing, NY 11355

I haven't discussed NCEG issues in my column yet for two reasons. First, I still have a few more installments on the Standard C library. Second, the NCEG folk are still settling down on the content of their technical report. I fully expect to devote some space to their work at the appropriate time. — pjp