Departments

We Have Mail

Dear Mr. Plauger,

Since purchasing Turbo C++ in the middle of this year, I have had a love-hate relationship with it. The qsort function is one of those. I first found this when playing around with Leor Zolman's Mini Data Base article.

My solution in this case was different than that of Mr. Irani. (See mdbedit. c in Listing 1. ) I passed the parameters exactly as Turbo C++ required, then "changed" them with casts inside the function. It would appear to me that the problem here has to do with the way Borland handles void. Turbo C seems to avoid this with a very loose prototype in <stdlib.h>.

Other problems with Turbo C++ have been its handling of arrays and a somewhat buggy IDE.

The IDE on occasion fails to restore the mouse cursor properly, leaving a black square on the screen where it was last clicked. (If you use an old, or nonMicrosoft driver, the mouse cursor may disappear completely, while the mouse remains active.) When debugging, the IDE sometimes becomes lost, requiring exiting, and restarting. Part of it seem to think the program is still executing, while part of it rightly knows it has successfully finished.

I do not like the editor defaults on the IDE. Thankfully most of them are changeable. However, some must be changed from TCINST while others must be changed from within the IDE.

Overall I like the Turbo C++ product, but don't think it is as perfect as much of the press out there has implied.

I am not a professional programmer so I do not claim to be any expert. However I hope some of this may give some insight to others.

I am a self-taught electronics technician of 20 plus years, now working on becoming a self-taught programmer. I program in C, Assembly, QuickBASIC, and Pascal (in that order).

Sincerely,

W. Paul Mills
4638 N.W. 35th St.
Topeka, KS 66618-3609

Thanks for the information. I haven't researched this, so I'm mostly just rattling, but I wonder if the qsort problem isn't just one manifestation of the significant difference between C++'s and C's attitudes toward types and type checking. C++ strives to be a strictly typed language — C doesn't even pretend. The end result must be that many common C practices won't be acceptable C++ code.

— rlw

Dear Mr. Ward:

I recall seeing in a back issue of The C Users Journal that the yacc/bison and lex/flex disks were the most often requested from your disk library. Since this seems to be what many of your readers want, I was wondering if you are planning any more articles on lex and yacc? It seems to me that you could have articles showing ANSI-C and C++ grammars, for instance. Or how about something on HOC7, which was mentioned on page 77 of the July 1989 Journal.

By the way, where can I find HOC7? I couldn t find it on Compuserve, nor on any of the local BBS s around here. Do you have it in your disk library or on any of your mayazine code disks that I could order? Thanks in advance for any assistance you can offer.

Sincerely,

William Pierpoint
Pierpoint Software
P.O. Box 2198
Camarillo, CA 93011

Of course I'm willing to publish some more articles about lex and yacc. I suspect a full blown ANSI or C++ grammar would be a little beyond the scope of a single magazine article, but we might find a way to publish it anyway.

I suspect you'll need to contact Victor Volkman directly to get a copy of HOC7. In case you aren't familiar with it, I strongly recommend Kernighan and Pike's The Unix Programming Environment. The book develops six increasingly sophisticated implementations of HOC (a High Order Calculator) as lex and yacc case studies.

— rlw

Dear CUJ:

The December issue of CUJ arrived today. I opened it to the table of contents, and turned eagerly to the article by Art Shipman, "Debugging with two monitors." After scanning the article two or three times, I asked, "Where is the hardware info on how to connect the second monitor?" Listening closely, I heard no answer.

Reading the author's bio, I noticed he is a consultant, and his address was given. Does this mean I am to contact him and enlist his professional services to find out how to connect the second monitor?

I also scanned the sidebar "Utilities for a second monitor" on page 31, and again found no mention of hardware add-on requirements; a new board? a connector into a printer port? does my PC already have a second monitor port which I just plug into? if so, why? ...

Can you help me out? (Which way did I come in, you ask?)

Yours in frustration,

Homer B. Tilton
8401 Desert Steppes Drive
Tucson, Arizona 85710

As Art Shipman says in the opening paragraph of that story, you must pick up a second video card to run a second monitor. You must, however, be careful to select a combination of cards that can be configured to reside at separate memory and port addresses and that can be placed on independent interrupts. Since the second monitor is always a "non-standard" system addition, this configuration must be customized to your particluar system. The documentation with more sophisticated and special purpose video systems will often explain how to configure these cards.

I hope this helps.

— rlw

Don Libes,

Thanks for the article about software timers in the November 1990 CUJ. I enjoyed it. A couple of observations:

In Listing 3 and Listing 5, you disable interrupts while accessing the timers[] array. But each function has an early return that, if taken, will leave interrupts disabled. For example, in listing 3, the line

if (!t-inuse) return;
will cause an early return without reenabling interrupts.

Also, the enable/disable of interrupts is a necessary precaution when accessing the timer data structures. But it is sufficient only if you are running on a single processor system that is not multiprocessing, or that cannot preempt execution when you are executing inside a timer function, or in any system where disable_interrupts( ) also prevents process preemption. It is not sufficient for:

In such environments, you need an additional semaphore to restrict execution of these critical areas to no more than one process at a time. For example, if locks(s)/unlocks(s) are functions that lock/unlock a critical section to one process at a time, based on the condition of the semaphore s,and if lock( ) waits indefinitely until the semaphore becomes available (a simplification), then the code could look like this:

   void
   timer_undeclare(t)
   struct timer *t;
   {
      disable_interrupts();
      lock(s);
      ....
      unlock(s);
      enable_interrupts();
   }
Looking forward to more articles from you!

Randy D. Miller

Don replies:

Oops, you are correct about the early return without re-enabling interrupts. As far as running in multiprocessing environments, I thought this was obvious. However, I don't mind if it is stated more obviously as you do in your letter. (-DL)

Dear Editor,

The "Quick Take" of Menuet in the December 1990 issue was a disaster: the review is more like a Quick Mistake! Even though my company sells a product that competes with Menuet, I have to come to the defense of the Menuet developers. The review is inaccurate in some of its comments about Menuet, and way off base in its reading of the GUI market place. Contrary to what the review states, there is plenty of need for GUIs other than MS-Windows, HP's New Wave and DRI's GEM.

I do agree with one thing about the article: Menuet and MetaWindow combined will add 200K to an application. However, that's still a lot less than the 4 megabytes of memory required for decent performance with any MS-Windows application!

The review-said: "Font support is noticeably lacking...". Wrong! Any package based on the MetaWindow toolkit, lets you have many different fonts, sizes, etc.

The review implies a three button mouse is "the cat's meow" (sorry). Our user research indicates a one button mouse is easier to use and that's what end users want! In fact, there are many end users out there who are "mouse phobic." Having to use three buttons would give them a nervous breakdown. Isn't the whole idea of a GUI to make the application easier to use for the end user?

The review said: "Since Menuet requires MetaWindow as a prerequisite, the market will be limited to those already interested in MetaWindows. Wrong! Many of our customers (about 50%) are new to graphics, and are looking for intelligent alternatives to MS-Windows. There are still many C programmers out there who like to write small, compact programs, and get them done before the turn of the century.

Most developers I talk to say MS-Windows is a pain in the tail to program in! They looked at Windows and don't want to pay the learning curve (of perhaps months!), or deal with such a memory hog. They need to develop applications that do a specific task, don't take 4MB of memory, and are easy to use. In many cases, there are better GUI development tools than Windows 3.0!

The reviewer's comment about Menuet not having intertask communication is myopic at best. Obviously, he is enamored with leading edge technologies (sometimes called bleeding edge!). However, most of the "trailing edge" (probably 90% of the DOS market) doesn't need intertask communications. This is not a "Bells and Whistles" war: developers are looking for tools that make them productive. Is that really MS-Windows in every case? I think the reviewer lost site of what developers and end users really need.

This is another example of reviewers not really understanding the market. They evaluate products based on the number of bells and whistles, not on whether it meets a need! If cars were reviewed that way, then the reviewer would recommend that everyone buy a Rolls Royce! Good development tools are not based on the number of bells and whistles, but on whether they make the developer more productive!

The statement, "there seems to be little need for another me-too GUI for DOS," I find particularly naive, close-minded, and just plain stupid! The reviewer has set up a false standard and implied all GUI development products should meet this standard. That's crazy! The reviewer also implied that MS-Windows is the ultimate development tool and that there is no reason to look at anything else. That's frightening! This review has done an incredible disservice to your readers. There is a great demand for alternative GUI development products, but you would never know it by reading reviews like this one.

Sincerely,

Tod Brannan, President
Oxford Consulting Group
1010 Oxford Street
Berkeley, CA 94707

You are right — and you will see no more "Quick Takes" in this magazine. I made the mistake of allowing what had been commissioned as a very cursory "internal guidance only" survey to be repackaged for the magazine. While cursory examinations (complete with the kinds of mistakes that accompany a hurried scan of a complex project) are useful to some of our non-technical staff, they are totally inappropriate for this magazine and violate all my own rules about reviews.

I appologize to my readers and to all the vendors who were mentioned in the December Quick Take.

And Tod, you must be one hell of a nice guy to get so upset about how a competitor was treated! I'm glad I have people like you reading my magazine.

— rlw