I read Bob van der Poel's letter in the CUJ, August 1991 and can appreciate the define versus declare problem he mentions. A simple solution is to let the preprocessor handle the details. First, suppose there are two source files. The first contains main, which we will call the main module, and the second contains various support functions. A header file named globals.h holds the global data. If there is only one global variable (maclevel), the globals.h looks like

#ifndef MAIN
   extern
#endif
   char maclevel;

#define MAIN 1
#include "globals.h"

char maclevel; /* In module with main() */

extern char maclevel; /* Modules without main() */

Sincerely,

Jack Purdum, Ph.D.
President, Ecosoft Inc.
8295 Indy Court
Indianapolis, IN 46214

I find this running debate about how to declare global data objects puzzling. I have always declared such data with the extern keyword (and no initializer, of course) in a header file. I include that header file in every C source file that cares about the name, even the one that defines it. The defining instance simply redeclares the data object without the extern keyword and with an initializer. This scheme is blessed by the C Standard and works on every C compiler I have ever used.

We all know you're a smart guy, Jack. Am I missing something? — pjp

Dear Mr. Plauger,

I am a long-time programmer. I have recently taught myself C, and your magazine has been quite useful in my education. The articles are mostly excellent. But I have found a bug. It is a bug found in numerous articles and advertisements in your magazine and in others. The bug is "C++."

When I first heard of C++, I thought it was an odd name, but not knowing the C language, I didn't know the origin. Now that I know C, I understand the intended meaning of the name. The increment operator, ++, is intended to denote that C++ is an incremental improvement of C; that C++ does C one better. But as I said, there's a bug.

By using the post-increment form, "C++" says (figuratively) "enhance the C language, and then use the unenhanced language." Clearly the intent is to use the enhancements; the language is enhanced before it is used. This should be denoted by the pre-increment operator, thus the language name should properly be "++C."

Changing the established name of a language is a major undertaking, but clearly the current name is erroneous. With your influence in the C community, you could change the name from "There's something better than this" to "This is something better."

Randall Bart
9950 Reseda Blvd. #13
Northridge, CA 91324

You've rediscovered one of my favorite snarky observations. I am often asked in public seminars how C++ differs from C. I explain that the notation C++ means that you have added to the content of C after you have extracted its useful value. Neither sticks nor stones nor ill-chosen names will stop C++ if it truly is an improvement, however. Sit back and enjoy the ride. — pjp

Dear Editor:

Your comments in the September 1991 Editor's Forum concern me. I'm not really sure what you are trying to say...I hope you're not saying "Ok, we'll run more PC- and Mac-oriented articles." I also hope you are not saying "We will tone down the content of our articles."

This is my second season with CUJ, and so far I'm very pleased. I spend my time in UNIXland, so I skip just about every article that is specific to some other platform/OS. Up until now, I think CUJ has done a fair job of balancing the articles for various specific platforms/OSs. Everyone deserves to be served. What I'm afraid of is that CUJ will change the balance, or reduce the number of platform/OS independent articles. In my opinion, there are already too many PC, Mac, and UNIX 'rags.' Also, I recently subscribed to some IEEE publications — CUJ is definitely not academic! Again, there are plenty of mags for beginners as well.

I hope, as you stated in a previous editorial, that CUJ will continue to focus on the state and future of C. As far as I know, there isn't another magazine of this kind. Keep up the good work.

Thanks,

Sean

Don't worry. I certainly do NOT intend to water down CUJ. All I meant to say was that we need more articles of the kind that Leor Zolman likes to write. Nobody can accuse him of watering down ANYTHING. He just has a pragmatic slant that appeals to many of the old timers who read CUJ. I have a different pragmatic slant.

The balancing act is never-ending. My editorial was merely a comment on the latest concern gleaned from letters written by concerned readers. Thanks for your input. — pjp

Dear Editor,

As a long-time reader of CUJ, I would like to applaud Nick Busigin for his excellent article concerning the QNX operating system (CUJ, September 1991). But I want to amplify his comments. More than a server-oriented architecture, QNX is a peer-to-peer system. The term 'server-oriented' suggest that a dedicated server is always needed, as in many MS-DOS network systems. QNX needs no server — the whole network is one system tied together by virtual circuits, a natural extension to the message passing mechanism. Distributed processing is possible, proved par example by the free MandelbroT package running parallel on several nodes of the network. Shared memory and shared files are themselves leading to shared libraries and dynalibs or DLLs. For any given software packet the code of individual tasks can be very small.

Taking into account that such a powerful operating system like QNX is not as easy to understand, the originator, Quantum Software Systems, Ltd. Canada, distribute for free an excellent demo-diskette running on all 8080 and 80x86 systems, starting under MS-DOS, QNX not needed. You simply will miss the fun by not seeing this very plausible demonstration.

QUICS, Quantum's Update and Interactive Conference System, operating 24 hours per day may be reached by modem via phone lines. Canada 613-591-0934, -0935, -0940 and x25 address 3020 85701416. For all C fans there is a very interesting library of all sorts of C programs and applications not only for QNX, partly a delight for real real-time hackers.

Hans G. W.Mueller
Consultant Real Time Systems
Hamburg, Germany

Thanks for the information. — pjp

Dr. Plauger:

This letter concerns your articles in March and April 1991 on The LOCALE header.

I am an experienced analyst and programmer of 20 years working on DEC pdp 11-01 to 11-70s, Vaxen, Intelbased PCs and IBM mvs and VM mainframes. However I am currently a C beginner/novice.

I was looking for a good tool to allow me to format a string to allow me to display a readable number in a Microsoft Windows application. To learn C and C++ and Windows, I purchased the BORLAND C++ compiler. I found your article seemed to fit the bill so I tried it out. I scanned in the code and hand-verified it. Then with the default C Locale.h from Borland executed it. This worked fine, however as we know it does not format anything since the parameters are essentially set to a simple default set.

I created from scratch what I thought was the Locale.h function for locale conv. The standard as show in the March issue of The C Users Journal was not clear to me. I seem to run into trouble around both the grouping and mon_grouping pointers. I do not really understand the contents. With the aid of the Borland debug facility I was able to get the p structure in your program Fmtval to be populated. However as soon as it started to process the second memmove statement in the V case the screen on my DEL 333D cleared and the machine hung.

So much for my "sob" story. What I learn from most is examples. Could you mail me a Locale.h file that works with the code I was hoping to have the ability to have comma'd thousands as well as $ processing? Since the US and Canadian formats are so close, your help would be appreciated.

This is my first connect through Internet so hope all works out. I left phone and home addresses at the top in case you have any trouble returning mail to me.

Sincerely

John D. Nourse
Oakville, Ontario

You are taking quite a few risks in mixing code so freely between two library implementations. The statement that is bombing assumes that p->decimal_point[0] (from the locale) *must* be present in the converted field. That's true only if you initialized that field properly in the locale structure so that it matches the decimal point generated by Borland's conversion function. My bet is that you have an error here, given your uncertainty over how to construct a locale.

You will find a reasonable "USA" locale on page 114 of The Standard C Library. That should serve as a good starting point for a Canada locale. It won't do you much good, however, unless you pick up much more machinery from the book. I don't see how you can get very far just mucking with locale.h.

The code diskette for this book is available from The C Users' Group. If you still want to pursue the matter, you might want to start with that. It should save you considerable typing and debugging. On the other hand, you might be better off altering _Fmtval so it doesn't mess with the locale machinery. You can, for example, pass the locale structure to use as an additional argument.

Good luck. — pip

Dear Editor:

First, I'd like to say that I'm pleased at the amount of reader feedback present in The C Users Journal; this is, I think, one of the things that distinguishes a good magazine from the rest.

Second, I'd like to propose yet another possibility for distribution of program sources: the Usenet. As one of the largest and most widely-distributed (and definitely world-wide) networks around, it could serve as an excellent way to get the source out. In addition, though there are commercial providers of Usenet access, one can get access to it for the price of an often local phone call. While access to the Usenet generally requires special software (at a minimum, the ability to receive e-mail), all of the requisite software is available in freely-distributable form.

If the idea seems reasonable but you lack the resources to do this yourself, it might be possible for me to post the sources to the Usenet on your behalf.

A couple of minor nits: you indicate that the code disk for your standard C library can be found by looking for an ad near the middle of the magazine; I was unable to find the appropriate ad. (Unless it was hidden in the CUG ad. I didn't see it there.) Since I'm rather interested in such a library I was a bit disappointed. No doubt I'll clear this up with a phone call, but....

Also, one page (99) of the magazine had several parts of the text faded to illegibility, apparently from a printer problem. Smaller areas were faded on some other pages. It isn't a big deal since the unreadable text was not in something. I was interested in but I thought you'd want to know.

T. William Wells
239B Willow Turn
Mt. Laurel, NJ 08054
bill@twwells. com