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.
Dear CUJ,
(In response to Richard Smith's letter in CUJ, July 1999):
Mr. Smith, if you don't like C++, then why use it? I call myself a C++ programmer, but I only use C++ because C++ is the language I feel most comfortable with. This is the language which allows me to work within the tight deadlines of the project.
This is not to say that if I could find a language that allowed me to get the job done in a similar fashion, I wouldn't use it. In my normal day to day work, I already use a mixture of tools — perhaps Delphi for the GUI calling a C++ DLL for the grunt work (although Delphi less and less now I have CBuilder). I am currently investigating Java and CORBA for projects in the future. I don't use VC++ and MFC, because I don't like the environment (what happened to the visual bit?), so I went and found something that suits me better.
Mr. Smith, if you are such a fan of Cobol and dislike C++ so much, check out http://www.casegen.co.uk/casegen.htm, a 32-bit COBOL RAD environment for Windows. There are many others, point your browser at your favourite search engine and try "Cobol for Windows."
Glenn Eisenhut
Thomson Financial Securites DataIn Mr. Smith's defense, developers don't always have such freedom of choice concerning which language or environment they use in their place of work. "Cobol for Windows" may not be an option. I'm holding out for Object-Oriented PL/1, myself. — mb
Hi there!
Pertaining to your article on Assertions in the June 1999 issue ("Better Assertions For MFC," by Giovanni Bavestrelli): I liked it a lot! But I have a different fix for issues 2 and 3 that you mention in your article (preventing a message box and logging the assert to a file). My fix has the additional advantage that it also works for other non-assert messages that also pop up as message boxes from time to time (run-time errors, etc.). Message boxes are extremely annoying when you are writing ActiveX controls that are being used from ASP. (IUSR_MYMACHINE, the bastard, refuses to press OK, so of course it locks up inetinfo and there's no way to figure out when it happens except by attaching to the process with the debugger.) Some message boxes come up even if you are not in debug mode! Anyway, without further ado, here's what I do:
When we are running inside a service (i.e., IIS inetinfo) we don't want any message boxes breaking the IIS system, even if we are indeed running debugging code. Therefore we insert this hook function to do reporting for us and allow us to go on. You could even send an email to the programmer inside this function if you wanted! See Figure 1.
timestamp is a useful little manipulator I wrote that outputs the date and time of the call.
Roberto Leibman
Talaria Research, Inc.
roberto.leibman@talaria.com
http://www.talaria.comThanks. — mb
Dear CUJ,
Having already implemented a templated fixed-length vector class myself, I took some interest in reading Fred Persi's "A Vector Class For Geometric Computations" (CUJ, August 1999). I was quite gratified to find that our implementations have much in common. However, considering that the main emphasis of Mr. Persi's article was on optimal code execution, there is one detail I think he (and other readers) might find important.
Nearly all of the arithmetic methods in the tnVector class use for loops to perform their operations. Unfortunately, many (if not all) compilers, unintuitively refuse to unroll loops of less than four iterations no matter what the optimization level. I presume this is due to the fact that 3 div 4 = 0, remainder 3, and the compiler never unrolls the "remainder" loop even though it knows exactly how many times it's going to be executed. Some compilers provide command-line switches to change the unroll limit, but then again some do not.
Therefore, considering that most 3-D geometric operations involve vectors of length three, it might be a good idea to provide "unrolled" specializations for tnVector<3> methods (and tnVector<2> if you like). If you're feeling pedantic, specializing tnVector<1> can even be helpful. (Compilers will add the conditional branch instruction even in for loops of length one.)
Michael McCarty
mikem@eai.comFred Persi replies:
Dear Mr. McCarty,
Thank you very much for your comments. I agree completely that unrolling loops is absolutely necessary to achieve optimal performance. My presumption was that a good optimizing compiler should indeed unroll all the loops, but as you point out that may not be the case.
I did not provide these "unrolled" specializations because of the substantial increase in the code base, and, more importantly, because some compilers not yet up to the Standard have difficulty with certain template specializations.
If you or other readers have any further information on why compilers typically do not unroll these loops, I'd be glad to hear it.
Sincerely,
Fred Persi
Hi,
Being a regular reader and subscriber to your excellent magazine, I find it interesting to see the boom in articles regarding multithreading, especially on Windows platforms. In Thomas Becker's otherwise great article on semaphores with priorities (CUJ, August 1999), I would like to add a few comments.
First of all, the solution relies on the WaitForMultipleObjects function, which limits the number of priorities available for the semaphore to MAXIMUM_WAIT_OBJECTS, which in WinNT 4.0 is 64. The implementation of CPrioritySemaphore::Create validates and makes sure that you do not exceed MAXIMUM_WAIT_OBJECTS, so the implementation is sound, as long as you do not need more than 64 priority levels.
Secondly, all events are created at once, which is needed when using WaitForMultipleObjects. Creating all events takes time, and also consumes system resources that might be needed elsewhere.
WaitForMultipleObjects is a nice function if used with care. I recently wrote a thread-pooling framework, and started out using WaitForMultipleObjects, but had to rewrite everything, mainly due to the 64-object limit. This rewrite also eliminated the need for creating all events from the beginning, and in the process I also got rid of my CriticalSections, which benefited performance a lot.
Regards,
Henrik Wivel
henrik@mijada.seThanks for the information. — pjp
Hi,
In Bobby Schmidt's column ("Decl Heckled," CUJ, June 1999), the scope of for-loop variables was discussed, and it was noted the MSVC V6.0 doesn't comply with Ansi C++ spec Section 6.5.3. I see it is still an active topic. MSDN News (Vol7, Num6, Dr. GUI column) gives the following workaround:
#define for if(0) ; else forwhich will curtail the scope of a variable declared inside the for control parens. Not being an MSVC user I have never tried it myself.
Respectfully Yours,
Craig Hicks
KGK Ltd.
Tokyo, JapanThanks — I think. Here's a brief review for readers who don't know what you're referring to. The C++ Standard says that when you declare a variable within the for-init-statement of a for loop, as in:
for(int i = 0; i < 10; ++i) ...that the variable will be in scope only from the beginning of the for loop to the end of the loop's body. So you should be able to write code like this:
for(int i = 0; i < 10; ++i) cout << "i is " << i << endl; for(int i = 0; i < 10; ++i) cout << "i is " << i << endl;The two is don't conflict with each other because they each go out of scope at the end of their respective for loops.
Unfortunately, VC++ 5.0 and 6.0 (and most likely previous versions as well) do not implement this rule correctly. If you try to compile the above code, you'll get redefinition errors, because VC++ thinks that each i is at the scope enclosing the for statements.
I tried the macro hack you provided, and it does seem to work, at least for simple loops. But yuck. I'd like to hear from readers if they discover any hidden problems with this trick. I really wish Microsoft would fix their compiler. — mb
[Well they did, kinda. But the compiler option that turns on proper scoping of for loops seems to be buggy. And at best, it breaks too much existing Microsoft code to be used safely. Sigh. — pjp] o