Data

Classes
class	ArrayIteratorBacking< T, PT >
	backend multidimensional iterator More...
class	ArrayIterator< D, T, PT, SM, ORDERED >
	fast multidimensional iterator More...
class	ArrayStorage< T >
class	NormalArrayStorage< T >
class	SpecialStorage< T >
class	Array< D, T >
	multi dimensional arrays More...
class	DataClass
class	Data
class	BorgIv::Exp
	Functional expressions in C++. More...

---

Detailed Description

The data layer was written in order to solve a number of annoyances when programming in C++

• C++ does not provide automatic serialization/deserialization and data compatibility between different hosts and processes is a modern necessity when writing applications.
• There is no generic 'object' type in C++ and simply implementations (e.g: creating a library/application Object root) easily leads to inefficient representations with generic types such as Integers, Floats,... are subclassed from such a root. For instance: an array of native integers versus 'object' based integers might be twice as large.
• Many generic data formats lacks multidimensional arrays, requiring the user to wrap arrays within arrays, which in itself might make specific optimizations impossible. Traversing through multi- dimensional operations can often be optimized by properly sorting the stride, sizes and offsets before iteration. This can lead to efficient use of specialized operations for linear blocks of data. E.g MMX optimized array operations. By providing an array data type this kind of use has become feasible.
• Often, when working with generic data types in C++, downcasting is a necessity. However, downcasts themselves override compiler warnings and bypassing the type checking. Since many errors occur due to wrong downcasts, it is necessary to integrate a type checking operator into a generic data framework.
• Memory allocation of generic data types is often overlooked, leading to memory leaks or inefficient use of memory. In the data library memory allocation is performed using reference counting, which leads to one of the more efficient implementations as observed by [REF]. The requirement on the application program is not to introduce loops, but this is not a problem, since those classes are aimed to provide an efficient serialization/deserialization interface.
• Languages that provide generic data types often also include garbage collection features. Those languages are often too impractical for heavy duty operations such as image processing and sound processing. (however their 'heaviness' is not necessarily linked to the garbage collection as such)

Todo:

We should replace the template array class with the generic message class which still resides in the hatchery. There is no need to use this complicated template since it does not make programs perform much faster. Instead we seem to loose a lot of flexibility by using these templates.