doc: Update README with info about types

README.md

@@ -47,12 +47,20 @@ on how to achieve this.
 Both the `python` module and the tests need compilation. Finally, one can install
 the headers and, when applies, the `python` module in a given directory.
 
-The pivotal part of the configuration step is the choice of the types used by
-CoMMA: one for indices (e.g., cell IDs), one for standard integers (e.g.,
-cardinality of the coarse cells), and one for reals (e.g., graph weights). They
-can be chosen with configuration options, respectively, `INDEX_T`, `INT_T`, and
-`REAL_T`. If not set, the default values are, respectively, `unsigned long`,
-`int`, and `double`.
+At configuration level, the user can also choose the types: one for indices (e.g., cell
+IDs), one for standard integers (e.g., cardinality of the coarse cells), and one for
+reals (e.g., graph weights). They can be chosen with configuration options,
+respectively, `INDEX_T`, `INT_T`, and `REAL_T`. If not set, the default values are,
+respectively, `unsigned long`, `int`, and `double`.
+
+> [!NOTE]
+> Types are meaningful only when using the `python` binding. Indeed, CoMMA is fully
+> templated and in its `C++` version it can work with whatever types the user ask: the
+> only limitation is that the types for indices and integers should be integer types. The
+> types provided at configurations times are used for testing purposes. Only the one
+> identified by `INT_T` is actually used in CoMMA core code: that's the one from which
+> enumerations inherit. On the contrary, the `python` bindings are generated by
+> instantiating the `C++` code with the types provided at configuration time.
 
 A typical flow for the configuration and installation of CoMMA usually relies on
 a standard out-of-source build and look like this: