## Intègre

### From LRDE

**Resources**

## Contents

- 1 Frequently Asked Questions
- 2 What is Intègre ?
- 3 Why int_u/sfloat and not a more unified syntax like u_int/s_float ?
- 4 Why completely rewrite a vector type and not just use STL ones ?
- 5 Why not use the standard complex numbers implementation ?
- 6 Is the number of bits limited for int_u ?
- 7 Why not use unlimited integers ?
- 8 Why cycle<T, Interval> and not range<T, Interval, cycle> ?

## Frequently Asked Questions

## What is Intègre ?

Intègre is a secure data type library in C++. It implements safe basic types, including integers, complexes and static vectors. It also provides useful tools to write data type generic algorithms. The project was originally a part of Olena, but was quite independant, so we extracted it into a standalone library.

## Why int_u/sfloat and not a more unified syntax like u_int/s_float ?

Mostly for historical reasons. Names will certainly be unified, so this is likely to change in a future release.

## Why completely rewrite a vector type and not just use STL ones ?

Our vectors are entriely statics. They are a more limited power than STL ones, but are faster. When you do not need dynamic sizes, use our static vectors.

## Why not use the standard complex numbers implementation ?

Our complex are specialized for both carthesian and polar representation. Standard ones are implemented using only carthesian representation, so they need high cost conversion functions when returning polar coordinates. It should be possible to rely on optimized C++ complex type for the carthesian representation though, this may evoluate in the future.

## Is the number of bits limited for int_u ?

Up to now, you cannot use more than 32 bits. There is no real good reason to limit ourselves to 32 bits. Future releases will certainly support 64 bits integers.

## Why not use unlimited integers ?

Unlimited integers are slow and consume more memory. Intègre was originally designed for image point types, so it had to keep small and efficient. However, we can imagine conditional compilation activating or not big integers. This is in the TODO list :-)

## Why cycle<T, Interval> and not range<T, Interval, cycle> ?

The behavior parameter specifies what to do when an overflow occurs. It does not change the fundamental properties of the type. So range<..., cycle> is *not* a real cycle, it is a non sense to say that an integer becomes a cycle. cycle<T, Interval> is a real cycling type, useful to represent angles for example. It has particular arithmetic rules, limited interactions with other types, etc.