Version 1.9 Build 1556

News	FAQ
Search	Home

Next: Bibliography Up: aips++ prototype Previous: Public interfaces

Subsections

Details

This chapter is just a bag of tricks. The items may not belong in this report, but their inclusion at least ensures that they do not get lost.

Object-state checking

Brian Glendenning

It is useful, especially when the code is being debugged, to be able to check the ``state'' of an object (in Eiffel this is called checking the invariants). It is useful to write a member function int Ok() that performs such a check and returns 0 if not successful, 1 otherwise (or boolean values). This function should be virtual for obvious reasons, and a subclass that redefines Ok() should probably within it also refer to its parent classes Ok(), e.g., refer to Parent::Ok() to ensure that the parent class is also consistent.

Conceptually you want to check the state of the object after construction, and at entry to every member function. However this state checking could be computationally expensive (e.g., checking all the pointers in a complicated data structure) so it must be possible to compile it out, preferably on a class by class basis, for the production system. A way of doing this is to use the macro OK rather than the function Ok() (obviously the latter is still available). Then the macro OK can be defined to be nothing, or can be defined to be something like assert(Ok()) (the assert should be replaced with the exception handling mechanism when available). Every .h file for classes which use the Ok() mechanism should have OK default to something, e.g. if you wanted to check state by default:

#ifndef OK
#define OK assert(Ok())    // Use exceptions when available
#endif /* OK */

This can be overridden at compile time (probably in the makefile).

Efficient indexing in vectors

Bob Sault

The three vector classes RVector, DVector and CVector (for real, double precision and complex) have methods defined on them to do all the normal arithmetic operations (addition, subtraction, multiplcation, division), and functions (sin, cos, etc), as well as interconversion. They use a reference counting scheme, and a copy-on-modify policy to reduce the about of copying.

The implementation of the indexing operator which returns a data element of the array (i.e operator []) is noteworthy. Convention dictates that this should act as either an lvalue or an rvalue. Having this operator always return a reference to a data-element would have disadvantages. As the operator would not know whether it is being used as an lvalue or an rvalue, it would have to assume the worse - an lvalue - which would significantly reduce the effectiveness of the reference counting and copy-on-modify policy. The way used to avoid this loss is to have two overloaded versions of the indexing operator, defined (for the real vector class) as

  float operator[](int) const;

and

  float& operator[](int);

The first version can only appear as an rvalue, and the compiler will use this in preference whenever the vector is of const type. The second version can appear as both an lvalue and an rvalue, and the compiler will use this for non-const vectors. Provided the programmer uses the const declaration wherever possible, the effectiveness of the reference counting, etc is maintained. For a multiply-referenced, non-const vector, then a copy will have to be made sooner or later anyway, so it does not matter what this is initiated by the indexing operator (even in instances where it is used as an rvalue).

Coplien discusses an alternate scheme (pp. 50-52) which would be applicable here. Coplien's scheme is quite a bit more expensive - a very undesirable characteristic in such a common operation as indexing. It also has the disadvantage that the indexing operator would always be a non-const method.

Next: Bibliography Up: aips++ prototype Previous: Public interfaces Contents