Don't let OOP fool you. It's pointer intensive. The approach taken here is to stop the program at the slightest problem. This conservative approach results from several years experience with rogue strings, dangling pointers to freed space, and jumping to execution of the heap because a stray bit of data landed in my interrupt vector table. These are some of the less benign things that can happen when using pointers.
Two error detection routines are provided for a graceful exit from the program. These routines print a message of which routine was active when the program failed. Nrerror() prints an error message and exits to the system with error code 1. Note that it is declared to return a double. This is so Nrerror() can be placed in the ternary operator '?:' where a double is to be returned. For instance, suppose x= -1.0, then the statement
double y = ( x>0 ) ? log(x) : Nrerror("LOG: negative value");will compile correctly since the compiler thinks Nrerror() will return a double. The compiler does not know that the program will exit before the return. Nrerror() provides a similar function in Press[#!Pr:nrc!#] which is an excellent source for code to translate to VMatrix functions.
There are two functions called Garbage(). They test the integrity of the matrix arguments in function calls. It prints the routine where a garbage matrix was found, then calls Nrerror(). A good example of this function is found in the assignment function for VMatrix:
void VMatrix::operator= (VMatrix &ROp) { Garbage("operator ="); ROp.Garbage("operator ="); . . . }First the member function of the VMatrix *this is called. Next the ROp member function is called. The signature is checked for validity. If it is wrong, the program stops. You should make a habit of checking for incoming matrices that could cause the program to bomb by using the Garbage() functions.