[SofaCore] FIX: enable ExtVecXf mappings with double floating type

[marques-bruno]

Compiling sofa with SOFA_FLOATING_POINT_TYPE=double (no float) leads to a series of compile errors in Mapping and MultiMapping

I believe the bug has been introduced in PR #738

The reason for this crash is that some Mappings double->float are necessary for some applications (usually for visual models, CUDA, etc.).
Thus ExtVecXfTypes are always compiled, even when #ifndef SOFA_FLOAT

This PR fixes the bug, but also raises an important underlying point:
Having ifndefs everywhere in the code is very intrusive, source of errors, and most importantly, prevents having a full code coverage in the CI in a single build. Floats are slower, and much less precise than Doubles. We do not support XBox / PS3 code, thus we have one less reason to keep this code smell in the core of sofa.
If the only reason we still need floats is for Cuda compatibility and other visual rendering stuff, shouldn't the conversions be done in those components / plugins, instead of having this FLOAT things affecting the whole codebase of SOFA?

I dream of a sofa without all these ifdefs lying around polluting the code.
@courtecuisse @fredroy , you worked the most on CUDA stuff and visual rendering respectively, do you have an opinion on the subject?

---

This PR:

• builds with SUCCESS for all platforms on the CI.
• does not generate new warnings.
• does not generate new unit test failures.
• does not generate new scene test failures.
• does not break API compatibility.
• is more than 1 week old (or has fast-merge label).

Reviewers will merge only if all these checks are true.

[jnbrunet]

I agree that maintaining those ifdef are quite cumbersome and there are probably easier ways to manage this.

Just a small remark, while arithmetic operations on double are probably faster than float (well, at least on most of our hardware), using float might minimize cache misses and might, with the help of compiler optimisations, produce faster execution times on memory intensive application (like SOFA) .

I think we should test this before removing floats from everywhere. If we got different results, maybe we could set a default floating type for the entire Sofa, and allow modules to change this default value for their components.

[damienmarchal]

IMO the complexity price we are paying right know in term of maintainability, code uglyness, bugs and weird issues it far bigger than the "un-measure" performance gain we expect. An our engineering time should be more useful in fixing all the crash/segfaul or performance issues because of n^2 algorithm (as in) than trying to get a totally minor (if any) performance increase because of switching from double to float.

So I recommand to only use Vec3Type in sofa instead of having both Vec3dType / Vec3fType, it will save thousand of man-month to invest more intelligent things.

As said by @jnbrunet, using Vec3Type allows to switch from float/double.

[marques-bruno]

Thanks for your feedback @jnbrunet @damienmarchal .

Meanwhile, this PR is ready, and I suggest reviewing it as a fast-merge since it's not much and fixes a compile-time issue for quite a few people.

[guparan]

If SOFA_FLOATING_POINT_TYPE=double, then SOFA_WITH_DOUBLE is defined so line 341 is activated.
Why this block?

[guparan]

I think this block should be just before the closing #endif //SOFA_WITH_FLOAT line 436 and the similar block line 341 should be deleted.

[marques-bruno]

Sorry, that was a duplicated bloc that I didn't remove after moving it in SOFA_WITH_DOUBLE:
VecXd -> ExtVecXf are required both when compiling in SOFA_WITH_DOUBLE and in SOFA_WITH_DOUBLE + SOFA_WITH_FLOAT. So technically, they could either be in the SOFA_WITH_DOUBLE bloc or in the combination of both, it would be the same.
Stupid logic. can't wait to see it dissapear...