The containers included here are intended to extend the stl containers in a way that provides features not included in the stl or to provide alternatives for stl containers that have been designed for convenience, not speed. Here the emphasis is on speed first, and c++ conveniences second.
Include the following at the top of any translation unit which requires this library:
These classes are template classes, so no linking is required for these interfaces.
Arrays provide a fixed size container (enabled via a template parameter) that can be saved as contiguous memory on the stack. This is in contrast to typical stl containers that are dynamic and thus use the heap for storage, which is much slower (on my dual-core, often about 10% slower for access methods and up to 500% slower for construction).
It provides all the usual stl iterators associated with the object, as well as many of the access methods excepting the size-changing ones. There are, however a couple of features of arrays that stand out from stl containers.
This concept is brought in (with slightly modified form) from Blitz++ and Eigen. It enables initialisation via the comma operator.
Comman initialisers will throw an exception if the range is exceeded in debug mode (beware release mode!).
These provide an efficient means of instantiating array classes without a costly copy-on-the-fly slowdown. It uses a blueprint coupled with what is referred to as a blueprint factory to do this (refer to ecl_concepts for more details.). However, the construction makes the usage of this transparent.
These arrays are almost exactly the same as the former fixed arrays, however they are dynamically sizeable (though not as automatically nor flexibly as vectors) with their storage on the heap, not the stack. The lack of flexibility isn't a serious disadvantage as a control program should generally manage vector memory careful (read, manually!) anyway. Their other feature is again, like the fixed arrays, the comma initialiser.
Arrays also provide a feature to allow for buffer overflow checking - for both fixed and dynamic arrays. Often programs pull pointers to various elements on the contiguous array (especially in really low level routines like vision routines), it is important to know when the stack or heap is being under or over run. Such functionality can be enabled by declaring the ECL_MEM_CHECK_ARRAYS macro when compiling (maybe later I'll bring this in as a template parameter).
Internally, this entails pre/appending some magic characters to the underlying array and then occasionally performing manual checks to ensure that the magic chars haven't been disturbed.
Often you require a window onto a container (array) and stencils provide a safe way to do this. It avoids the use of dangerous pointers which can cause problems if the underlying container goes out of scope or is resized. It does this by including the underlying container as a reference and also includes similar out of range checks that arrays perform (exception throwing in debug mode for  and always for at()).
During the construction of fifo, typically length of buffer may be important.
An initialised buffer can be important in variaous situation. For example, if you wish to calculate a moving average, you should wait for N (length of buffer) pieces of incoming of data. However, if you initialise the whole buffer as above, you can proceed immediately.
Some converters utilising ecl::converters::FromByteArray are enabled for arrays and stencils respectively. These allow conversion to integers of any time from a corresponding, little endian filled array/stencil of chars.
and going the other way, we pass it the byte array for storage when converting (works on both arrays and stencils)...
Currently there is only formatters for the array and stencil classes classes which do: