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.

Editor,

I was wondering if any C/C++ Users Journal articles have been written about error handling in C. The current software development project I am involved in uses the technique shown in Listing 1.

I've simplified things somewhat so as not to include too much code, but the general idea is that GPm_ERROR hides a goto to ERROR_HANDLE.

Is there a more elegant way to handle errors in C? In the past when I would work on my personal programming projects I would generally just recover from errors (close files) on the spot and then call a global error print function. Most books and articles presenting small programs commonly use this approach as well, but many times it is only appropriate for fatal errors.

I am interested in hearing about the different approaches to error handling you have encountered.

Thanks,
Rick C. de Baca

I assume you've left out a few braces, in your zeal to compress the code, but I think I get the basic design. Error handling is a subject with endless complexities. Perhaps the most ``modern'' approach is exception handling, as built into C++, Java, and other languages. But almost any orderly approach has to be better than the ad hoc techniques that many programmers apply. -- pjp

---

Dear Mr. Plauger:

I have a program in two files: x.c (a C file), and y.C (a C++ file). I compile the individual files:

 gcc -c x.c g++ -c y.C

and then link the resulting object files:

 ld x.o y.o

Executing the resulting a.out results in a core dump. Is this the behavior one should expect? Is there a different way of doing this? (For context, this is an attempt at supplementing an old and very large piece of code, written in C, with new code that could use the flexibility of C++ to good advantage.) For reference, I'm including the files used in the example above. (See Listing 2. )

Sincerely,
Julio Kuplinsky

Mixing code from two programming languages, even C and C++, is always a tricky business. How to do so depends strongly on the particular compiler and linker you're using -- there are few real standards in this area. In this particular case, I see two problems with any C/C++ compilers I know about. First, you really should write main in C++ if the program contains any C++ code at all. That gives the program a chance to do the magic initialization of statics that C++ requires. Second, you have to declare as extern "C", in a C++ source file, any function that must follow C calling conventions and external naming rules. But these rules represent just the tip of a large iceberg. Start small, with a mixed program, and work your way up, testing as you go. -- pjp

---

Dear Mr. Plauger:

My question about overloaded operators which you kindly published in the July CUJ created some interesting responses. I think Motti Shimoni tracked down the reason. He developed better coded complex operators. The following is a concluding comment resulting from his efforts:

Motti Shimoni tracked down the reason for the slower performance using overloaded operators when multiplying and dividing complex numbers. It seems the compiler makers have directly implemented the AT&T complex library functions, which is not the most efficient way to do it because they use calls to the conj and norm functions in operator/.

My problem was slow performance when many complex multiply and divide operations occurred while solving a 5,000 x 5,000 sparse matrix in a power system network analysis, over and over again for different cases. The calculations took many hours (90 MHz Pentium) and the saving in using my own fuctions was quite significant.

The letter following is a message from Motti Shimoni. I had supplied him with a small test program (which he modified) that does 2 million multiply and divides and measures the time taken. It seems if you want the best performance, you better make your own complex library for overloaded operators, particularly the divide operator.

Many thanks for your interest in this problem.
Ian Simpson

Hi Ian,

Look at the two files in Listing 3:

cmplxtst.cpp -- this is essentially your original sample, slightly edited to allow both tests simultaneously. Note my additions. It is very briefly annotated.

complex.cpp -- I found finally Borland's code, and that is extracted from it detailing how they divide. It is more elegant, however it involves some constructions and destructions of temporary objects that take their performance toll. My explicit formula is much more efficient, as demonstrated.

If you have a problem detaching the files let me know and I'll embed them in the mail body.

Good luck,
Motti Shimoni