1) Page 103, column 1, change

((-4) >=0 ? (4) : (-(4)))

((-4) >= 0 ? (-4) : (-(-4)))

#ifdef __cplusplus
#endif

#ifdef __cplusplus
}
#endif

if (x > 0)
   assert(x != y); /* semi-colon was missing */

#undef assert
#ifdef NDEBUG
#define assert(cond)
   (void) 0
#else

In December's issue, a reader Mr. Hardy asked about pcx importing in C. First, he should probably get one of the good inexpensive compilers like Turbo, Quick C, etc. But then, I have found that Genus Microprogramming's pcx toolkit is an exceptional value and the tech people are friendly and helpful. In addition, Mr. Hardy could download a handy pcx drawing program (shareware license is only $45). All in all, this would be a good budget way to get into what he wants to do.

Genus Microprogramming's number is 1 800 227 0918. Hope this helps him. :> uunet!sosc1.sosc.osshe.edu!ferrell

P.J. Plauger

Frank Campbell's letter reminds me of something I like to say: Computer Science is an oxymoron. There is no science to computers (well, there is science, but just getting a computer science degree does not make one a good practicioner). Software is like any writing: good writers are rare and hard to find. It is much more of an art than a science. And many who preach computer science cannot write very good programs. Many (SEI?) want to make writing software a "process." But I don't see how you can effectively make a process for creativity if you want high quality software (maintable, easy to use, easy to modify, efficient).

I also liked the fact you said "where C++ comes into its own is with larger programs (where 'large' is admittedly a relative term)." I like this position much better than the one you advocated several years ago where "anything over 100k lines should be written in ADA." I had an electronic conversation about "large" with Dennis Ritchie several years ago. What he discussed was that the idea behind Unix was not building large monilithic systems, but writing a number of smaller programs which communicated effectively. It is far easier to integrate independent programs into a system than have one big program lots of people work on. (They reprinted much of this letter several years ago in DDJ. I can dig it up for you if you want to republish. I wrote the letter to DDJ in response to an interview with someone who said "C is a brain-dead language" ;-) )

Manuel Lopez talked about Pc/VI. If memory serves me correctly, PC/VI was an excellent vi clone — too good, it was vi — they were sued by ATT and had to close shop (this is from recollection). I used the Manx Z briefly and wasn't thrilled by it.

What is very good is Elvis (a vi clone). It is distributed as part of the GNU project and runs on MS-DOS and Unix. A major advantage is it runs the same way on both systems. In addition, when xterm windows on unix are resized, elvis adjusts its size dynamically to the correct dimensions (a major advantage over other vi-s). Also, it sidescrolls for long lines.

One of these days, I still have to learn EMACS — and start using it.

marty
leisner@eso.mc.xerox.com leisner.henr801c@xerox.com Member of the League for Programming Freedom

As a writer myself, I can't help but agree that both programming and writing are creative processes. But as a person who endeavors to be professional about both, I also keep striving for a "process" that improves my chances of being adequately creative on demand. You should notice that picking a text editor you know, love, and are comfortable with is one of the small things you do to up the odds that you'll deliver the goods. Both of these letters underscore the importance of that choice. — pjp

Dear Mr. Plauger,

I noticed while reading "C++ Library Ground Rules" in the November issue of The C Users Journal that the C++ Standards Committee may approve using header names with no suffix added. This would ruin the logic behind the way I store files on my hard disk. The sorting scheme I use is to sort first by extension and then by name. Hence the uppermost files in any directory listing are subdirectories. The remainder of the filenames in the listing all have extensions.

If the C++ Standards Committee adopts this naming convention then all C++ header files will be intermixed with subdirectory names on my hard disk. Furthermore some vendors supply software that have a few miscellaneous files without extensions which would also be intermixed with the subdirectory names and header names. The first thing I would have to do is add my own extension to all the C++ headers.

I urge, through you, that the C++ Standards Committee adopts a naming convention for C++ headers that includes a suffix. For example *.hpp or *.hp, or even *.hxx. If this were the case then any file with an extension of hpp (or hp or hxx) would be guaranteed to be a C++ header file. I know this is a minor point but just in case others are concerned I want to add my name to the list.

Best Regards

Pete Melissakis

The final word may have only recently been spoken in the C++ standard. (An odd comment, this, on a standards effort that has entered its fifth year, for a language in use for over a decade, nicht wahr?) Tom Plum and I have already discovered similar problems in retreading C source-code control techniques for C++ code. Watch this space. — pjp

Dear Mr. Plauger;

I have been a CUG member and C Users Journal subscriber for many years, and I have enjoyed your column on the C standards as well as your books on the same subject. I have found that your books and columns have given me ample material to help me in my development efforts, especially since an important focus for me is portability.

As you delve into C++ and the integration of C constructs and libraries into the new language standard, you do an excellent job of pointing out the successes and the "gotchas" that a standards organization goes through to accomplish what must seem an insurmountable task.

It is your latest "Standard C" columns (CUJ Dec. '93) that prompts me to write, because you make a statement that is confusing and unsettling to someone who has been programming in C for many years. On the third page, you touch on the use of the NULL macro, and give some of the conversions used in many dialects of C, then you go on to say that we shouldn't be using NULL in new programs. Do you mean C++ programs? I have been using NULL explicitly for years and find it to be an excellent way to "document" what I mean in certain pointer expressions. I don't do nearly as much development now as I used to, but I'd hate to think that all the programs I've written to date share one large ignorant flaw in the use of the NULL macro. If you get a chance, it would be very helpful to get a quick clarification on this. Thanks so much for your time, and keep up the great work!

Brian Smithson
Project Manager
Workgroup Solutions, Inc.

I too have used NULL for decades as a great way to document that I am using a null pointer constant. It is also useful, in very limited circumstances, to be sure I pass a pointer-size argument in the absence of a function prototype. The only such context that is now socially acceptable is when calling a function that takes a varying-length argument list. And the risk is still great that NULL may not have exactly the right representation, since it only assuredly looks like a pointer to void, not like a pointer to function or even some complete data type.

Stronger type checking, both in C and C++, now encourages me to shelve that long-standing style rule. A bald 0 is now almost always clearly a null pointer constant, both to the translator and to the human reader, just from context:

if (p !=0)
   ...

Dear Mr. Plauger,

I have recently took on the task of teaching myself C. After graduating college with a minor in computer science, I wanted to get more information on the programming language that they did not offer at my school, but I heard so much about. The classes I got a background in is assembly, COBOL, Basic, and Pascal.

The first tasks I did was to subscribe to The C Users Journal, bought a compiler (Turbo C), and several books on the basic syntax. Out of all the information that I have accumulated since these early days, I have found no information on using C on a Novell network. Could you help me find the information I need for building functions that have record lock capabilities for the DBMS I'm trying to write. As networking, downsizing, and rightsizing continue to grow the information myself and maybe others need cannot be found. It would also be helpful if the magazine could have an article about this specific subject, or on the subject of DBMS on a network. Thanks for all the useful information over the past year.

Sincerely,

Randy Chapman
5843 Georgetown Colony
Houston, TX 77084

I was in a computer bookstore yesterday and recall seeing at least two titles that offered to teach a modicum of Novell network programming using C, but I don't recall authors or titles. We run an occasional article on the same subject, but probably not more often than once a year or so. Your request is noted. — pjp

[Two books you may want to investigate are: Netware System Interface Technical Overiew, ISBN 0-201-57027-0, and Netware 386 Programmer's Guide, ISBN 0-201-57709-7, both published by Addison-Wesley. The first book is the offical reference to Novell's C Network Compiler, and describes all of the NetWare 2.15 API. The second book focuses on NetWare Loadable Modules (NLMs) and version 1.2 of the NetWare C Interface Library. These books are available from the C Users Bookstore — contact R&D Publications at (913) 841-1631. — mb]

Dear PJ

I want to start off by commending you very highly indeed for producing such an excellent magazine. In my opinion it presents just the right balance between technical articles and advertisements, making it appealing to a wide range of audience. Being one of the few (if not the only person) trying to make a living in Cape Town as a freelance software engineer, I treat it as a lifeline in this often "turbulent" world of new software developments.

The reason for writing this letter is that I really want to throw the cat amongst the pigeons by raising a very touchy subject indeed, and that is software documentation. A colleague and myself have been using Nassi-Schenidermann structure charts for a very long time, and not only for purposes of documentation, but also for purposes of conceptualising and writing code. It is our opinion that there is no point in attempting to write code until you have got your "ducks in a row," because if you haven't, you often "bend" the code to solve what may have been a poorly conceived solution. Why should you then, once you have been through the process of conceptualisation, throw it all away by transferring your thoughts to code using your own personal programming style only?

I believe that there must be merit in what I am saying, otherwise a company like SIP Software Solutions wouldn't have a market for their GESY product today. Perhaps you could consider asking them to write a technical article for a future publications, on the benefits of using their approach to software development. Or am I perhaps seeing the world through the eyes of a software engineer as opposed to a computer scientist — scientists invent and develop the technology whereas engineers have to implement and maintain it. It worries me though that I have never seen anyone else using this technique.

There are two other aids that my colleagues and myself have also developed over the years. The first is to replace the zillions of curly braces in a piece of code with something a little more user-friendly, and that is to create a small header file called syntax.h which consists of the following:

#define FALSE     0
#define TRUE      !FALSE
               // !!! Strictly according to C
#define END_if }
#define END_while }
etc.

The other aid which I find to be tremendously useful is to prefix variables with up to three lower-case letters indicating what type of variable it is (I believe it is called Hungarian notation), much like the system used in Windows and BORLAND's Object Windows. The reason is quite simple, and that is once the variable declaration is no longer visible, it is no longer obvious what data type that variable represents. For example, t could be an integer, a pointer to a structure, or whatever, whereas psTime is clearly a pointer to a time structure. Once again, I have never seen anyone else using it to the same extent as I do, i.e. every single variable has a prefix.