License

lti::object

In the LTI-Lib 1.9.x the lti::object only defined the virtual method getTypeName(). The interface for lti::object in the CVR-Lib is stronger and specifies the "clonable" interface. Two methods have to be defined in all classes inherited from lti::object: clone() and newInstance(). The former creates an instance with a replicated internal state while the latter creates a new instance with the default constructor. The main reason for this change is that now, all lti::objects can potentially exist in factories, and for this fact the clone() methods are required

A relatively new feature of C++ is used for clone() and newInstance(), which is not supported by GCC 2.95.x or VC++ 6.0: the return type of clone() is a pointer to the current class, and not a pointer to the parent class, as previously expected. This saves some unnecessary casting when working at the same level in the class hierarchy.

The old method getTypeName() has been replaced by name().

Since there are many objects for which is does not make sense to clone, then many old lti::objects are now independent from the hierarchy (e.g. lti::mutex, lti::factory, etc.)

lti::className, getTypeName() and name()

The LTI-Lib 1.9.x produced simple const char* with the method getTypeName(), which was not necessarily unique (especially for template classes).

The CVR-Lib has replaced the method getTypeName() with name(), which returns a fully qualified class name (generated with lti::className). This way, the name() method can be directly used with factories.

To simplify the manual generation of class names that are independent of the used C++ compiler or OS platform, all spaces are eliminated from the names.

Names of template classes

The names of many template classes in the LTI-Lib 1.9.x began with a 't', so for example there were types lti::tpoint<T>, lti::tpointList<T>, lti::trectangle<T> among others. To be consistent with the lti::vector and lti::matrix types, all those types has been renamed to lti::point<T>, lti::pointList<T>, lti::rectangle<T>. Similarly to the shortcuts of vectors and matrices, there are now several shortcuts like lti::ipoint for lti::point<int>, or lti::fpoint for lti::point<float>.

Underscores in protected and private attributes

The use of underscore is now not only allowed, but mandatory in the CVR-Lib for protected or private attributes. This is necessary to simplify the identification of local variables from class attributes. The attribute name has to have a trailing underscore (e.g. vectorSize_)

lti::point

Member Functions

• The function distanceTo() no longer exists. Use sqrt(p.distanceSqr()) if p is your point

lti::genericVector

The generic vectors and matrices and all inherited classes have changed the initialization interface to a more intuitive, efficient one, even though it is more dangerous.

Construction and Initialization

Old LTI-Lib 1.9.x

Previously, if you wrote:

vector oldVct(5);

a vector with 5 elements initialized with T() was created. There are many cases in which you know you don't want to initialize anything to save some time. Therefore an alternative constructor was created:

vector oldVct(false,5);

to avoid the initialization. This is however not so intuitive while reading.

New CVR-Lib

In C++ you know that if you write something like:

int i;

then the content of i is not defined. Therefore in the CVR-Lib this approach has been followed and the container objects are only initialized if you explicitely indicate that:

vector aVct(5); // uninitialized vector with 5 elements, i.e. only
                   // memory allocation

vector aVct(5,T()); // vector initialized with default value of T

Resize and Initialization

The same applies to the resize method:

Old LTI-Lib 1.9.x

vector vct;

vct.resize(10); // 10 new elements initialized with T()
vct.resize(15); // 5 new elements initialized with T(), keeping the first 10
vct.resize(18,T(6)); // 3 new elements initialized with "6", keeping the first
                     // 15 elements

New CVR-Lib

vector vct;

vct.resize(10); // 10 new uninitialized elements
vct.resize(15); // 5 new uninitialized elements, keeping the first 10,
                // whatsoever they were.
vct.resize(18,T(6)); // 3 new elements initialized with "6", keeping the first
                     // 15 elements
vct.assign(5,T(3));  // resize to 5 elements and set all of them to a value of 3
vct.allocate(20);    // change the size to 20, but do not touch the memory

The complete interface of the resize method in the LTI-Lib was resize(int,T,bool,bool), where the boolean arguments indicate copy-data and initialize-data, respectively. The default values for these booleans were set both to true. In the CVR-Lib these booleans were replaced by enumerations with meaningful values for the copy data and initialization settings. Note, however, that this interface is unnecessary, since you can use allocate or assign instead.

lti::genericMatrix

Access as vector

In the LTI-Lib was allowed to access a connected matrix as vector, using an at() method which expected just an integer. Since with this method it is quite dangerous to make a not intended access to a matrix as vector, the method has been renamed in the CVR-Lib to elem(), this way there is no possible misunderstanding that you want to do what you're saying (the problem caused several hours debugging in some functors!).

Submatrices

The dual behaviour of a matrix as lined or connected matrix has been removed from the CVR-Lib. A clearer concept with separate submatrix classes allows better interface definitions. All matrices are now connected and all submatrices are lined. The functors that support working on the same memory can now explicity implement the methods for submatrices.

lti::location, lti::rectLocation

Member Functions

• getArea() renamed to calculateArea() since there is a multiplication involved. (Being a bit picky maybe)