Discussion :

[mickael9]

Bonjour, j'ai un problème assez ennuyeux lorsque je convertit un double en int, voilà un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
double tmp = 123.456;
tmp *= 10;
tmp *= 10;
tmp *= 10;
cout << (int) tmp << endl;

Bizarrement, cela affiche 123455 et non 123456
Encore plus bizarre, si je fais directement (int) 123456.0, j'obtiens bien 123456, et ça donne bien 123456 avec (int) (123.456 * 1000) aussi
Comment résoudre ce problème ?

[Florian Goo]

Bonjour,

Ce phénomène est expliqué par la façon dont est codé un nombre réel : http://fr.wikipedia.org/wiki/Nombre_flottant

[mickael9]

Comment faire alors ? :/
En fait, mon but est de transformer un double en int + multiplicateur, par exemple : 123.456 = 123456 / 1000 (il me faut 123456 et 1000)
Pour l'instant ma méthode est de multiplier par 10 le double jusqu'a ce qu'il soit entier en comparant (int) tmp et tmp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
double tmp = 123.456;
int multi = 1;
while (tmp != (int) tmp)
{
    tmp *= 10;
    multi *= 10;
}

Mais bien sûr, il part en boucle inifinie pour 123.456 car lorsque tmp = 123456.0, (int) tmp vaut 12345

[Florian Goo]

Eh bien, par exemple, au lieu de tester l'égalité exacte entre tmp et (int)tmp¹, tu devrais plutôt admettre une petite marge d'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int tmp_plus_delta = tmp + 5;
int tmp_moins_delta = tmp - 5;

et le test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
tmp > tmp_plus_delta || tmp < tmp_moins_delta

(¹) au passage, en C++, on écrit plutôt ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
static_cast<int>(tmp)

[mickael9]

Eh bien, par exemple, au lieu de tester l'égalité exacte entre tmp et (int)tmp¹, tu devrais plutôt admettre une petite marge d'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int tmp_plus_delta = tmp + 5;
int tmp_moins_delta = tmp - 5;

et le test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
tmp > tmp_plus_delta || tmp < tmp_moins_delta

Heu, la marge d'erreur me parait un peu trop grosse non ?
Car entre 123.456 et 123 il y a beaucoup moins de 5 de différence

(¹) au passage, en C++, on écrit plutôt ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
static_cast<int>(tmp)

Je vois vraiment pas l'intêret d'écrire un truc aussi long alors que ça fait la même chose

[Florian Goo]

Heu, la marge d'erreur me parait un peu trop grosse non ?
Car entre 123.456 et 123 il y a beaucoup moins de 5 de différence

Désolé, j'ai lu ton code de travers… oui, un double inférieur à 1 serait bien mieux, bien sûr !

Je vois vraiment pas l'intêret d'écrire un truc aussi long alors que ça fait la même chose

En C, le seul cast possible est celui-ci (sans parler du cast au constructeur). En C++, tu as static_cast, dynamic_cast, reinterpret_cast et const_cast qui font chacun une partie de ce que fait le cast à la C.
Cela rend l'expression d'un cast plus expressive, donc plus sécurisée.

Tu peux faire un static_cast les yeux fermés. Par contre, si tu fais, par exemple, un const_cast, tu t'exposes à des risques sérieux. Cependant tu y feras attention puisque tu sais que tu fais un const_cast.
Avec un cast à la C, s'il se trouve que tu réalises l'équivalent d'un const_cast, cette fois-ci tu n'en seras pas conscient, puisque tu penseras avoir écrit un cast comme les autres.

Écrire static_cast est une bonne habitude à prendre. Utilise ça à la place des casts à la C sans te poser de questions, cela t'éviteras bien des bugs très difficiles à détecter.

[mickael9]

Bon, j'ai un truc qui marche à peu près (ça se chie dessus sur les nombres genre 123.456789012345), ça donne une approximation (relativement correcte)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int multi = 1;
 
while (fabs((nbr * multi) - (int) (nbr * multi)) > 0.1)
    multi *= 10;

Bizarrement, le fait de multiplier par 1000 plutôt que de multiplier par 10 trois fois fait gagner de la précision
Je ferais avec, tant pis

Ah, et pour le cast, dans ce cas précis, est-ce que faire static_cast<int>(...) est vraiment différent que de faire (int) (...) ? Je suis pas sûr d'avoir vraiment compris ce que tu voulais dire

[droggo]

Hai,

Bizarrement, le fait de multiplier par 1000 plutôt que de multiplier par 10 trois fois fait gagner de la précision

Ça n'a rien de bizarre : 1 seule multiplication au lieu de trois, on évite donc les approximations successives de 2 multiplications.

[Florian Goo]

Ah, et pour le cast, dans ce cas précis, est-ce que faire static_cast<int>(...) est vraiment différent que de faire (int) (...) ? Je suis pas sûr d'avoir vraiment compris ce que tu voulais dire

Ouais, je dois bien avouer que j'ai expliqué comme un pied
Je n'ai pas d'exemple probant avec des nombres, mais en voici un avec des pointeurs de classes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
class Cannard
{
//...
};
 
class Chaise
{
//...
};

Avec un cast à la C, tu vas pouvoir compiler une horreur comme celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Cannard* c = new Cannard();
//beaucoup plus loin
Chaise* c2 = (Chaise*)c;

À un moment dans ton code, tu vas te mettre à caster un cannard en chaise en supposant qu'il y ait un rapport d'héritage entre les deux, et le compilateur va joyeusement te laisser te planter.
Alors qu'avec un cast C++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Cannard* c = new Cannard();
//beaucoup plus loin
Chaise* c2 = dynamic_cast<Chaise*>(c);

Tu écris ici explicitement que tu fais une conversion en pensant qu'il y a un rapport d'héritage.
C'est là qu'est l'avantage de l'accroissement de l'expressivité. Tu dis clairement au compilateur ce que tu penses faire en faisant ton cast. Dans ce cas précis cela va lui permettre de se rendre compte que tu fais effectivement quelque chose qui n'a pas de sens et va refuser de compiler.
Pour pouvoir caster un pointeur de Cannard en pointeur de Chaise, tu devras écrire un reinterpret_cast. Et lorsque tu écris un reinterpret_cast, tu sais que tu fais quelque chose de très dangereux et que tu vas prendre un maximum de précautions pour que ça ne parte pas en sucette.

Je pourrais te trouver tout un tas d'autres succulents exemples à base de static_cast, const_cast ou reinterpret_cast qui font que c'est une excellente idée de proscrire totalement les casts à la C et de prendre l'habitude d'écrire des *_cast du C++.


@tous> Si quelque chose à ce sujet dans la FAQ m'a échappé, je veux bien connaître le lien pour la prochaine fois !

[mickael9]

Ok, merci pour tes explications

[koala01]

Salut, et bienvenue sur le forum.

Il y a un autre avantage à l'utilisation de static_/dynamic_/autre_ cast: ca facilite énormément la recherche dans le code.

En effet, les parenthèses et autre symboles (allant même jusqu'à & ou * ) sont utilisées à toutes les sauces dans un code: cela va simplement de la modification de priorité des opérations mathématique et/ou logique, à la déclaration d'une liste d'argument dans le prototype d'une fonction, en passant par la création de callbacks et plein d'autre chose encore.

De ce fait, quand tu as un fichier volumineux (et dieu sait que cela risque de t'arriver bien souvent), si tu fais une recherche sur "(int" en espérant retomber sur les rare transtypages que tu a effectué, tu va tomber, successivement, bien que ce ne soit pas forcément dans cet ordre sur:

• les prototypes des fonctions prenant un entier en premier argument
• l'appel de fonction auquel tu transmet n'importe quelle variable dont le nom commence par int
• n'importe quelle opération mathématique et / ou logique modifiant la priorité des opérations et dont le premier opérande est une variable commencant par int
• différentes structures de controles (tests et boucles)
• j'en passe et de meilleures.

Alors que si tu prend l'habitude d'utiliser les transtypages fournis par le C++, tu va gagner sur tous les tableaux:

Hormis en ce qui concerne le reinterprete_cast, tu auras au minimum un controle, lors de la compilation (c'est à dire bien avant que l'erreur commise ne puisse enclancher la troisième guerre mondiale), un controle sur la possibilité de transtyper quelque chose en quelque chose d'autre, sur le fait que tu n'essaye pas de transtyper une référence en un pointeur (ou l'inverse), ou que tu n'essaye pas de transformer un pointeur (qui, pourtant, est le plus souvent représenté en mémoire comme l'est un entier long non signé) en... une valeur entière longue non signée utilisée pour faire un calcul.

Mais, de plus, si tu sais que tu as transtypé quelque chose en autre chose, une recherche sur dynamic_cast<type_de_destination ne te renverra que... là où tu as fait ce transtypage