Why doesn't this work on my compiler?

The files you downloaded from Wiley's ftp site are intended merely to save you the effort of typing the examples that appear in the book. They are not represented to be a complete software package. With that said, however, probably your difficulties are due to differences in desktop environment, rather than core language. Your choice of directory/file structure and what libraries to include is up to you. I am a minimalist in this regard. It is your right, of course, to bring in additional features (such as STL) that I chose not to deal with. However, doing so may cause problems I have not had to deal with.

The file update.txt contains links to versions of the example code modified by readers to work in a variety of other environments. I would encourage you similarly to share your modified code when you get it working.

Why don't you include more features of the latest C++ Standard?

My objective was to find a minimal subset of C++ to augment C so that the result would be attractive to engineers and scientists experienced in FORTRAN programming. (My original title for this book was "C++ for Native FORTRAN Writers.") It is my view that including more of C++ would be wasteful, because so little of it is relevant to scientific programming. This small subset of C++ adds some needed enhancements to C, which then decisively surpasses the capabilities of FORTRAN.

Why are you still using that old Borland compiler?

I believe it is still the most user-friendly one available in the MS DOS environment. I understand that the Borland compiler will soon be available free of charge for Linux. I hope they haven't dumbed it down.

Don't you know the difference between delete[] and delete?

The distinction between delete and delete[] was introduced long after the new method of dynamic allocation was in general use. Borland apparently chose not to obsolete users' code that had been developed under earlier versions of their compiler. You realize that the examples in the book execute thousands of dynamic allocations, deallocations, and reallocations without any problem, and that I have verified this in detail. Surely, the standard does not require a compiler to generate bad code, without warning, when this restriction is ignored?

The delete vs delete[] distinction is a case where the C++ standard reflects a poor decision. The compiler already has been told what is an array and what is not, when the object was allocated. Bjarne Stroustrup writes, "The special destruction operator for arrays, delete[], isn't logically necessary. However, suppose the implementation of the free store had been required to hold sufficient information for every object to tell if it was an individual or an array. The user could have been relieved of a burden, but that obligation would have imposed significant time and space overheads on some C++ implementations." [The C++ Programming Language, 3rd Edition, page 251.] He is saying that users should be burdened for the sake of compiler vendors! I would be embarassed to defend this reasoning to readers coming from FORTRAN.