Departments

We Have Mail

Letters to the editor may be sent via email to cujed@mfi.com, or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.

Special Event: C/C++ Users Forum

The Association of C/C++ Users (ACCU) of the United Kingdom invites CUJ readers to attend a C/C++ Users Forum, to be held on the 18th and 19th of July in Oxford, England. This forum will be a user-orientated event, aimed at programmers and developers, ranging from novices to members of the standards committees.

The first day will be a seminar day. In-depth presentations of advanced programming techniques for programmers will be presented. Presenters include Dr.Bjarne Stroustrup, inventor of C++. The second day is the main conference day, and will feature Dan Saks and P.J. Plauger (both of CUJ), as well as Dr. Bjarne Stroustrup.

The ACCU expects over 500 developers to attend (maximum capacity: 750). All attendees are C/C++ developers, invited from the membership of the ACCU's C++ Users' Group and from a wide range of European software developers, as well as from the readership of this magazine.

The forum will also include a number of product demos by software vendors, many of which have already verbally given their support.

The conference and exhibition is cosponsored by the ACCU, a non-profit organization, and Parkway Research Ltd.

Synopsis:
Title: C/C++ User Forum
Venue: Oxford Town Hall, Oxford, OX1 1BX, U.K.
Date: 18th & 19th July 1997
Start: 9:00 a.m. till 6:00 p.m.

For more details contact Parkway Research Ltd. +44 1491 875386. FAX: +44 1 491 875524. e-mail: parkway@rmplc.co.uk

Dear CUJ:

I enjoyed Harry Cheng's article on CGI programming ("CGI Programming in C," CUJ, November 1996). However, I had a problem with his code.

First, I presume that he omitted error checking in the interest of brevity. For example, the code assumes that malloc never fails.

More importantly, the unescape function as shown in Listing 3 of that article is flawed. The line reading:


if(url[x] == '+')

should refer to url[y], not url[x]. A similar problem occurs two lines later, where the original reads:


else if(url[x] == '%') {

which should likewise refer to url[y].

The problem shows up most clearly when the string to be unescaped contains more than one escaped character. The code as published mangles the string; with the corrections noted above it appears to work correctly.

For the sake of his users, I hope this mistake reflects a typo in CUJ rather than a bug in Mr. Cheng's code.

(I am sending a copy of this email to Mr Cheng.)

Scott McKellar
jm407a@multi.sbc.com
(314) 235-3595
Opinions expressed are my own, not my employer's.

Harry H. Cheng replies:

Dear Scott:

Thank you for your comments about my article. The CGI code presented in the article has been tested mainly using my C interpreter under different web servers. As in Perl, these CGI programs do not need to be compiled to run. My C interpreter has features such as nested functions. The unescape function is handled as a nested function inside a getnamevalue function. I created separate programs without nested functions for ANSI C users. The problem in the unescape function pointed out in your comments had been fixed more than one year ago. But, unfortunately, the fix has not been updated in these ANSI C modules.

The CGI code in the article reflects the implementation of the intrinsic function malloc in my C interpreter with a check on the availability of memory. An updated version of CGI C code with a check on memory is available on the WWW at the URL address http://iel.ucdavis.edu/code/cgi/. [We also make it available on the CUJ ftp site, ftp.mfi.com, directory pub/cuj, and on this month's code disk. — mb]

Regards,
Harry

Editor,

Topic: Error in Sept. 1996 CUJ article on a timer class.

The timer-class article was very useful. I'm using it to debug some real-time processing. I did find a bug in it though. All functions return a double but in reality it is only a double truncated to an integer, giving accuracy to only one second, not to the precision of the OS. This is because in the diff function the CLOCKS_PER_SEC should be cast to a double so that the compiler does floating divide not an integer divide!

After doing this things work fine, with resolution down to 1 ms using VC++ and NT.

Thanks,
Dan Bay
dan@bay.nrl.navy.mil

Good point. I don't have the code handy from that article, but I'd guess that the Standard C library function difftime might prove more robust here. — pjp

To Ian Simpson:

I saw your letter to the editor in C/C++ Users Journal (July 1996). You were concerned that using <complex.h> was syntactically interesting but that the usage was slower.

You noted that using the complex objects was causing two function calls. I happened to open Scott Meyers' most excellent book, More Effectve C++, to Item 20, "Facilitate the return value optimization." This is supposition, but it may give you some place to look.

Operator overloading in C++ requires that new objects get created. The second function call is an assignment operator. For example:

Complex a(1,2);
Complex b(3,4);
Complex c;

c = a + b;

This operator call translates into:


Complex temp = operator+(a,b);
operator=(c,temp);

Scott Meyers goes on to explain that this extra copy can be eliminated using the "return Value Optimization." The idea is that operator+ must return a constructor result. The compiler can then entirely eliminate the assignment and construct the object directly into the new value.

Two things must occur:
1. The operator must return the result of a constructor.
2. The compiler must support the return value optimization.

Like I mentioned before, this is only supposition, but it seems to line up. You can read a better explanation in Scott Meyer's book (highly recommended).

We who use C++ keep trying to say that the overhead of C++ is negligible. It mostly is if implementors pay attention. C++ really allows you to write your own language much more than just program.

I hope this information helps,
Duane Murphy
murphy@community.net

Dear Mr. Plauger,

I am a recent subscriber of your magazine.

Due to the very nature of the kind of things I do research on (semiotics, linguistics), I need to work with massive amount of ASCII text and bit-mapped files, looking for patterns and correlations among them. As a freelance C programmer I have written some code, but it only works for files of small length. As soon as I try something a little larger, the program fails, and I get "Array size too large" as a compiler error message.

I set OPTIONS/COMPILER/CODE GENERATION to huge, inserted huge in the declaration of the array, like this:


char huge txt[nrbytes];

and I've got the message "Conflicting type modifiers."

I went then to Barnes & Noble and unsuccessfully looked through each computer book, looking for a rescuing code regarding C/C++ and huge memory model.

Here is the sensitive part of the code I wrote for Turbo C++ 3.0. In addition to this huge file, I use two other huge integer and character files as buffers for the results of my investigation. See Listing 1.

The lengths of these ASCII texts differ from the number of bytes I get with this program through the end of file. And the difference are not the same for different files. Some explanation of that?

Please, help me. Thank you very much.
Camilo Lopez
New York, NY

P.S. Is there a detailed book with plenty of code and little parlance regarding "memory models in C/C++?" Is there something else I should know?

Your first problem is that you store the value returned from getc in a char. That generally ruins the test for end of file, because the int value EOF changes value when you stuff it into a char. You are thus probably overwriting the array. How the program behaves from then on is hard to predict. Your second problem is storing an entire file in storage to begin with. It is generally best to avoid the need for doing so, given that files can be much bigger than the storage available to programs, even with today's computers. As for a good book on C/C++, check out our "Essential Reading List" for C/C++ programmers on our web site, as compiled by our roving Consulting Editor and former columnist, Chuck Allison. The URL is: http://www.cuj.com/readlist.htm. Beyond that, you'll have to keep browsing until you find one that suits your particular needs. Good luck. — pjp

Dear Dr. Plauger,

Years ago, I read an article of yours in Computer Language (now Software Development) about criticism. You made the very excellent points that positive feedback is important and that programmers tend to naturally be vicious in their criticism of other programmers.

Having said that, allow me to start with some positive feedback before I register my whine.

Your book, The C Standard Library is one of my basic C references (by basic I mean vital, not simple). I bought a copy when I was first learning C, and it was a godsend both to me and to the instructor in my C class at university — almost every program I turned in used library functions he hadn't seen!

It is the second book (after K&RII) that I recommend to anyone attempting to become a C programmer.

Elements of Programming Style is another gem.

I am always delighted to find any of your writings anywhere — your writing style is an example that I attempt to follow, and your facts are always, well, factual.

Your columns in The C/C++ User's Journal are always entertaining, at the least. They're often encouraging on a philosophical level that one rarely sees in a technically-oriented publication.

It is the Journal to which my gripe relates.

I allowed my subscription to lapse last year because a) I felt that the emphasis was too much in the realm of C++ for my tastes, b) too many articles were PC-specific (again, for my taste), and c) the editorial stance seems to obscure the differences between C and C++.

In hindsight, I think that as a faithful CUJ reader for several years, I should have made my feeling known before my sub ran out. Oh, well.

It is issue (c) that I wish to address.

In my current job, I often am assigned students as temporary programming help. It seems that many of these people don't understand the difference between C and C++. In reading the Usenet groups comp.lang.c and comp.lang.c.moderated (I am a backup moderator for the latter), I see that many people are fuzzy about the difference between the two languages.

There is much discussion these days of a mythical language called "C/C++." Much of this discussion takes place in the pages of CUJ. I agree that programmers need to learn both languages in order to be effective (and employable), but I would like to see them treated in a somewhat more distinct way. I see programmers asking questions that show that they are confused about the two languages, and in fact, I have read articles in CUJ that seemed to muddy the waters.

While I'm not blaming CUJ exclusively(or even primarily) for the confusion, I think it could help to lessen the confusion somewhat. CUJ is, in fact, the only magazine I've seen that addresses the need to use both languages. I'd just like to see the line between the two drawn more clearly for the benefit of those of us attempting to learn one and/or the other.

Thank you for taking the time to read this.

Billy Chambless

Point taken. We'll try to be a bit clearer editorially in future articles. Nevertheless, I must also point out in our defense that the line between C and C++ is growing fuzzier. Blame compiler writers for that. They tend to combine the two languages in one compiler, then allow varying amounts of C++ to leak down into C. More accurately, blame their customers for demanding, or at least tolerating, such blendings. — pjp

Editor,

Congratulations once again on an outstanding publication! I'm still fairly new to the world of C++ and programming in general, so most of your articles go right over my head. Neverless, I still look forward to each issue, and hope to be writing for you someday. And now, a few comments about your current issue:

Thanks once again, and I hope I haven't taken up too much of your time,

Phil Haney

Thanks for the comments. — pjp

Phil, I'm not sure why you were unable to get to me through our web site, but you can send flattering comments such as the above directly to mbriand@mfi.com. Send complaints to — er, what was that e-mail address? Had it here somewhere... — mb