Re: Il faut bien lire ce qu'on lit!

Permets-moi de t'arrêter (enfin, rétrospectivement, et j'ai une bonne raison physique pour ça) sur ce point:

Dans le monde de la finance, de l’assurance, de la gestion de stock, de la gestion commerciale, des ressources humaines/paye, de la comptabilité (société ou personnelle), la quasi-totalité des calculs sont faits en utilisant le type décimal.

Je doute qu'aucune erreur ou bug ne filtre dans «l'embarqué» pour ça. Les convertisseurs analogue-digital (et vice-versa) ont une résolution, et dans leurs specs (enfin, mon souvenir remonte à y'a longtemps) leurs règles sont claires.
Pourquoi dans les CPU on en chie à avoir un calcul exact, sachant qu'au final ça serai juste des 1 et des 0? Je n'en sais trop rien, sûrement parce qu'on a voulu imposer une représentation finie sans limitations d'un truc potentiellement infini (les nombres réels. Au final, c'est un peu comme la taille maximale d'une chaîne de caractère, mais pensé sur 64 bits je crois? Diantre! Et ça semble contraire à tout ce que j'ai vu à l'école, de préciser aucune information de façon explicite et simple sur la résolution des résultats finaux des calculs...)?

Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.

Ici, je ne vois pas le problème.
Pour ce type de fonctionnalités, il me semble évident que le modèle objet prend tout son sens. Ce qui me dérange le plus, à la rigueur, c'est que le float natif, lui, ne soit pas un objet, alors que justement, il s'agit d'un type pour lequel l'opérateur == devrait être illégal. D'ailleurs, mon compilo me colle un warning, soigneusement transformé en erreur par mes réglages perso, quand je fais ça.

Tu parles de règles légales, et un des problèmes est bien là: de la même manière que les chaînes de caractères ne devraient pas être considérées comme un type natif (ben oui: quel encode qu'il veut, le bon monsieur? Et comment que le programme il doit le savoir nativement? Ben il peut pas, mon bon monsieur...) ce genre de chose nécessite (au niveau financier du moins) un système pour que le comportement change selon les LOCALES de l'utilisateur.

Alors je pousse ici le cri de désespoir partagé par tous les développeurs de la finance ou de la compta : "je veux un langage qui fait ce dont j'ai besoin !".

Alors il te faut soit cesser d'utiliser un langage généraliste, soit implémenter un jeu de classes (une lib, quoi) qui fasse ce que tu veux suffisamment bien pour que tous les comptables autour du monde puissent s'en servir.
La tâche est ardue, mais avec assez d'argent à la clé, quelqu'un le fera sûrement.

me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.

Tu lis dans mes pensées. Et pas pour de la compta & co: même pour du système, j'aimerai que mon compilo râle.
Bon, comme il est évident que ça serait hyper lent de vérifier chaque calcul, je me suis contenté de me faire un remplaçant pour static_cast<>() nommé safer_cast<>().
Ça ne gère malheureusement que le transtypage d'un entiers vers un autre, ça ne peux que faire un gros assert() de la mort qui tue en cas de dépassement en mode debug (et rien en release, mais je pense corriger ça en permettant le lancement d'exception ou un abort, le tout configurable via le template), mais ça reste nettement mieux que ce que le C++ me propose de manière native.
Cela dis, un langage comme Rust pourrait proposer mieux, vu que l'accent n'est pas mis sur les performances mais la fiabilité.

En tout cas, ne crois pas que le problème des dépassements et des arrondis est limité au tertiaire. Tous les programmes, sans exceptions, y sont soumis.