Using SoftBench CodeAdvisor

freeing the memory would be an error.

SoftBench CodeAdvisor can detect this sort of logic error. It scans your program, looking for operator= definitions, and makes sure you check for the classA = classA case. If not, it warns you to fix your code.

SoftBench CodeAdvisor rules focus on finding actual or potential defects in your code. Other rules check for maintenance, performance, and future problems or porting issues. These example rules show how to check for potential problems:

If any member of a class is virtual, the destructor should be virtual.

When a class contains a non-virtual destructor, there is a danger that a class instance of a derived class may be deleted by one of its base class destructors instead of by its own destructor. This can cause a memory leak, or worse problems. For example, some static or global data should have been modified by the derived class destructor.

The problem doesn't actually occur unless a derived class instance with a non-empty destructor is deleted through a pointer to one of its base classes. However, non-virtual destructors can result in maintenance problems, since new derived classes can be added at any time. Nothing prevents the new derived object from being deleted through a base class pointer.

Provide an operator= for classes that dynamically allocate memory or declare a copy constructor.

The default operator= simply copies the fields of one instance to another. If the instance contains pointers to memory allocated by new, the default operator= makes two copies of the pointers. When one of the instances is deleted, it deallocates the memory using delete, and the other instance contains a dangling pointer.

Refer to SoftBench Online Help for a complete list of rules shipped with SoftBench CodeAdvisor.

146

Chapter 6

Page 146
Image 146
HP UX SoftBench Software manual Using SoftBench CodeAdvisor, 146