Part Two
eyeGT is written in C++ thus its logic and operations are heavily based on the Object Oriented (OO) paradigm. Unlike most other graphic libraries, eyeGT provides a monolithic access to the whole library, the application doesn’t have to deal with objects allocation and freeing, saving pointers etc. as eyeGT itself will perform these operations when needed. The advantages of such architecture are multifold:
- Reduced memory fragmentation: eyeGT allocates a chunk of memory and uses it as a pool to allocate objects in it, performing housekeeping (garbage collection) when required. This alone guarantees that your application will never experience memory leakages owing to unreleased objects.
- Better control over memory allocation: objects are instantiated only when required and released when no longer needed. The application doesn’t have to worry about when to release memory, eyeGT will do it when most appropriate, without degrading the performance of the application.
- Reduce time to develop: programmer doesn’t need to debug the graphic library, Barefoot Software using the latest technologies in problem tracking and solving did the job already, so you can concentrate on the architecture of your application instead of solving other libraries’ problems.
- Portability: whatever the platform, processor and quantity of memory are, eyeGT can be ported to it; a C++ compiler is the only needed tool. eyeGT doesn’t uses RTTI and exceptions, as most embedded systems C++ compilers do not support them; extensive error description is returned by each API to allow for problems easy pinpointing. In case of any error, the application will never crash owing to eyeGT inability to handle an error; this is a very stringent and at the same time basic requirement for any technology that is mean to use in a production environment that can put life at risk like: airplanes displays, life maintenance machines or nuclear facilities.
