|Changes from LTI-Lib 1.9.x to CVR-Lib 1.x|
LicenseOne of the most important changes is that the CVR-Lib comes with the BSD License instead of the LGPL. The reason? Simple. We want the library to be used everywhere. This new license helps us searching for funds, since is more probable that the CVR-Lib will be employed in the industry.
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.
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:
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:
to avoid the initialization. This is however not so intuitive while reading.
In C++ you know that if you write something like:
then the content of
Resize and Initialization
The same applies to the
Old LTI-Lib 1.9.x
The complete interface of the resize method in the LTI-Lib was
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!).
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.