Si j'ai bien compris, la norme ISO/IEC 14882:2003 voudrait que les compilateurs lancent
une exception dès qu'il y a un dépassement de capacité lors d'une opération arithmétique,
ce qui est contraire à une norme IEEE plus ancienne qui prévoyait le calcul avec l'infini
(peut-être pour C ?).
Quelqu'un peut-il confirmer le caractère obligatoire de ce lancement d'exception ?
En pratique, je viens de constater que
ni icpc (compilateur d'Intel)
ni g++ (compilateur GNU), même avec l'option -pedantic
ne le font.
Avec ces deux compilateurs :
+ Sur un résultat nombre flottant, un overflow renvoie l'infini ("inf").
+ Sur un entier, c'est plus inquiétant car un dépassement vers plus l'infini renvoie
un entier négatif si l'entier n'est pas signé,
0 s'il n'est pas signé.
Quelqu'un connait-il une bibliothèque (avec sources) qui permette les calculs avec l'infini?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
kanze
Henri de Solages wrote:
Si j'ai bien compris, la norme ISO/IEC 14882:2003 voudrait que les compilateurs lancent une exception dès qu'il y a un dépassement de capacité lors d'une opération arithmétique, ce qui est contraire à une norme IEEE plus ancienne qui prévoyait le calcul avec l'infini (peut-être pour C ?). Quelqu'un peut-il confirmer le caractère obligatoire de ce lancement d'exception ?
Je ne sais pas d'où tu as ces informations. Selon la norme, « If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression, in which case the program is ill-formed. » En gros, l'implémentation est libre de faire ce que bon lui semble.
Note aussi que les opérateurs habituels n'ont pas les définitions attendues sur des types entiers non-signés. Ou plutôt, que l'abstraction des types entiers non-signés n'est pas un intervale sur des cardinaux, comme on pourrait s'y attendre, des nombres « modulo ». Du coup, quelque soit l'expression, le resultat se trouve dans l'intervale représentable.
En pratique, je viens de constater que ni icpc (compilateur d'Intel) ni g++ (compilateur GNU), même avec l'option -pedantic ne le font.
Avec ces deux compilateurs : + Sur un résultat nombre flottant, un overflow renvoie l'infini ("inf").
C'est un comportement indéfini selon la norme, mais du point de vue qualité de l'implémentation, ça me semble un bon choix pour les implémentations avec des flottants IEEE.
+ Sur un entier, c'est plus inquiétant car un dépassement vers plus l'infini renvoie un entier négatif si l'entier n'est pas signé,
Pour les entiers signés, c'est encore un comportement indéfini. Ici, le bon choix selon la qualité d'implémentation est moins évident. Logiquement, dans l'absense d'un infini, on s'attendrait à un signal, ou quelque chose du genre. Mais sur des hardware courant, ça imposerait un coût supplémentaire non negligeable en temps d'exécution. Historiquement, la solution (en C et en C++) a toujours été de donner ce que le hardware donne. Aujourd'hui, étant donné la prévalence des machines à complément à deux, sans vérification automatique du débordement, certains arguent même que c'est le comportement « attendu » -- c'est en tout cas le comportement exigé par Java. Et si c'est vrai que personnellement, je préfère de loin de lever un signal, si j'écrivais un compilateur, je ne manquerais pas d'offrir ce comportement attendu, au moins en option.
0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte comme si 0 n'est pas signé, y compris pour les flottants.
Quelqu'un connait-il une bibliothèque (avec sources) qui permette les calculs avec l'infini?
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà. C99 a ajouté une section optionelle qui est peut-être supportée par ton compilateur C++ ; sinon, il y a certainement du support non standard en extension. Pour l'extension C, il suffit de tester si __STDC_IEC_559__ est défini. Mais en général, si le hardware utilise IEEE, tu as les calculs avec les infinités par défaut. (Parmi les machines actuellement sur le marché, je crois que les IBM AS/400 et les Unisys 2200 sont à peu près les seuls qui n'utilisent pas IEEE, et les IBM le supporte aussi en option, même si ce n'est pas le format par défaut.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Henri de Solages wrote:
Si j'ai bien compris, la norme ISO/IEC 14882:2003 voudrait que
les compilateurs lancent une exception dès qu'il y a un
dépassement de capacité lors d'une opération arithmétique, ce
qui est contraire à une norme IEEE plus ancienne qui prévoyait
le calcul avec l'infini (peut-être pour C ?). Quelqu'un
peut-il confirmer le caractère obligatoire de ce lancement
d'exception ?
Je ne sais pas d'où tu as ces informations. Selon la norme, « If
during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable
values for its type, the behavior is undefined, unless such an
expression is a constant expression, in which case the program
is ill-formed. » En gros, l'implémentation est libre de faire ce
que bon lui semble.
Note aussi que les opérateurs habituels n'ont pas les
définitions attendues sur des types entiers non-signés. Ou
plutôt, que l'abstraction des types entiers non-signés n'est pas
un intervale sur des cardinaux, comme on pourrait s'y attendre,
des nombres « modulo ». Du coup, quelque soit l'expression, le
resultat se trouve dans l'intervale représentable.
En pratique, je viens de constater que
ni icpc (compilateur d'Intel)
ni g++ (compilateur GNU), même avec l'option -pedantic
ne le font.
Avec ces deux compilateurs :
+ Sur un résultat nombre flottant, un overflow renvoie
l'infini ("inf").
C'est un comportement indéfini selon la norme, mais du point de
vue qualité de l'implémentation, ça me semble un bon choix pour
les implémentations avec des flottants IEEE.
+ Sur un entier, c'est plus inquiétant car un dépassement vers
plus l'infini renvoie un entier négatif si l'entier n'est pas
signé,
Pour les entiers signés, c'est encore un comportement indéfini.
Ici, le bon choix selon la qualité d'implémentation est moins
évident. Logiquement, dans l'absense d'un infini, on
s'attendrait à un signal, ou quelque chose du genre. Mais sur
des hardware courant, ça imposerait un coût supplémentaire non
negligeable en temps d'exécution. Historiquement, la solution
(en C et en C++) a toujours été de donner ce que le hardware
donne. Aujourd'hui, étant donné la prévalence des machines à
complément à deux, sans vérification automatique du débordement,
certains arguent même que c'est le comportement « attendu » --
c'est en tout cas le comportement exigé par Java. Et si c'est
vrai que personnellement, je préfère de loin de lever un signal,
si j'écrivais un compilateur, je ne manquerais pas d'offrir ce
comportement attendu, au moins en option.
0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte
comme si 0 n'est pas signé, y compris pour les flottants.
Quelqu'un connait-il une bibliothèque (avec sources) qui
permette les calculs avec l'infini?
Si ta machine supporte les flottants IEEE, c'est probable que tu
as des fonctions nécessaires déjà. C99 a ajouté une section
optionelle qui est peut-être supportée par ton compilateur C++ ;
sinon, il y a certainement du support non standard en extension.
Pour l'extension C, il suffit de tester si __STDC_IEC_559__ est
défini. Mais en général, si le hardware utilise IEEE, tu as les
calculs avec les infinités par défaut. (Parmi les machines
actuellement sur le marché, je crois que les IBM AS/400 et les
Unisys 2200 sont à peu près les seuls qui n'utilisent pas IEEE,
et les IBM le supporte aussi en option, même si ce n'est pas le
format par défaut.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Si j'ai bien compris, la norme ISO/IEC 14882:2003 voudrait que les compilateurs lancent une exception dès qu'il y a un dépassement de capacité lors d'une opération arithmétique, ce qui est contraire à une norme IEEE plus ancienne qui prévoyait le calcul avec l'infini (peut-être pour C ?). Quelqu'un peut-il confirmer le caractère obligatoire de ce lancement d'exception ?
Je ne sais pas d'où tu as ces informations. Selon la norme, « If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression, in which case the program is ill-formed. » En gros, l'implémentation est libre de faire ce que bon lui semble.
Note aussi que les opérateurs habituels n'ont pas les définitions attendues sur des types entiers non-signés. Ou plutôt, que l'abstraction des types entiers non-signés n'est pas un intervale sur des cardinaux, comme on pourrait s'y attendre, des nombres « modulo ». Du coup, quelque soit l'expression, le resultat se trouve dans l'intervale représentable.
En pratique, je viens de constater que ni icpc (compilateur d'Intel) ni g++ (compilateur GNU), même avec l'option -pedantic ne le font.
Avec ces deux compilateurs : + Sur un résultat nombre flottant, un overflow renvoie l'infini ("inf").
C'est un comportement indéfini selon la norme, mais du point de vue qualité de l'implémentation, ça me semble un bon choix pour les implémentations avec des flottants IEEE.
+ Sur un entier, c'est plus inquiétant car un dépassement vers plus l'infini renvoie un entier négatif si l'entier n'est pas signé,
Pour les entiers signés, c'est encore un comportement indéfini. Ici, le bon choix selon la qualité d'implémentation est moins évident. Logiquement, dans l'absense d'un infini, on s'attendrait à un signal, ou quelque chose du genre. Mais sur des hardware courant, ça imposerait un coût supplémentaire non negligeable en temps d'exécution. Historiquement, la solution (en C et en C++) a toujours été de donner ce que le hardware donne. Aujourd'hui, étant donné la prévalence des machines à complément à deux, sans vérification automatique du débordement, certains arguent même que c'est le comportement « attendu » -- c'est en tout cas le comportement exigé par Java. Et si c'est vrai que personnellement, je préfère de loin de lever un signal, si j'écrivais un compilateur, je ne manquerais pas d'offrir ce comportement attendu, au moins en option.
0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte comme si 0 n'est pas signé, y compris pour les flottants.
Quelqu'un connait-il une bibliothèque (avec sources) qui permette les calculs avec l'infini?
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà. C99 a ajouté une section optionelle qui est peut-être supportée par ton compilateur C++ ; sinon, il y a certainement du support non standard en extension. Pour l'extension C, il suffit de tester si __STDC_IEC_559__ est défini. Mais en général, si le hardware utilise IEEE, tu as les calculs avec les infinités par défaut. (Parmi les machines actuellement sur le marché, je crois que les IBM AS/400 et les Unisys 2200 sont à peu près les seuls qui n'utilisent pas IEEE, et les IBM le supporte aussi en option, même si ce n'est pas le format par défaut.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Henri de Solages
Merci beaucoup.
wrote:
Je ne sais pas d'où tu as ces informations.
J'ai dû confondre avec le comportement attendu de new.
En gros, l'implémentation est libre de faire ce que bon lui semble.
Super pour la portabilité !
Ou plutôt, que l'abstraction des types entiers non-signés n'est pas un intervale sur des cardinaux, comme on pourrait s'y attendre, des nombres « modulo ».
Je ne comprends pas cette phrase. Ne manque-t-il pas quelque chose avec << des nombres "modulo">>.
+ Sur un entier, c'est plus inquiétant car un dépassement vers plus l'infini renvoie un entier négatif si l'entier n'est pas signé, 0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte comme si 0 n'est pas signé, y compris pour les flottants.
Mon "il" ne remplaçait pas "0" mais "l'entier" : si je fais unsigned int grand = ... ; unsigned int trop_grand = grand * grand ; trop_grand vaudra 0 chez moi. Si je comprends bien, ce comportement n'est pas normé non plus.
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ? Et pour les entiers, existe-t-il une bibliothèque ?
James Kanze GABI Software
Merci beaucoup.
kanze@gabi-soft.fr wrote:
Je ne sais pas d'où tu as ces informations.
J'ai dû confondre avec le comportement attendu de new.
En gros, l'implémentation est libre de faire ce
que bon lui semble.
Super pour la portabilité !
Ou
plutôt, que l'abstraction des types entiers non-signés n'est pas
un intervale sur des cardinaux, comme on pourrait s'y attendre,
des nombres « modulo ».
Je ne comprends pas cette phrase.
Ne manque-t-il pas quelque chose avec << des nombres "modulo">>.
+ Sur un entier, c'est plus inquiétant car un dépassement vers
plus l'infini renvoie un entier négatif si l'entier n'est pas
signé,
0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte
comme si 0 n'est pas signé, y compris pour les flottants.
Mon "il" ne remplaçait pas "0" mais "l'entier" :
si je fais
unsigned int grand = ... ;
unsigned int trop_grand = grand * grand ;
trop_grand vaudra 0 chez moi.
Si je comprends bien, ce comportement n'est pas normé non plus.
Si ta machine supporte les flottants IEEE, c'est probable que tu
as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ?
Et pour les entiers, existe-t-il une bibliothèque ?
J'ai dû confondre avec le comportement attendu de new.
En gros, l'implémentation est libre de faire ce que bon lui semble.
Super pour la portabilité !
Ou plutôt, que l'abstraction des types entiers non-signés n'est pas un intervale sur des cardinaux, comme on pourrait s'y attendre, des nombres « modulo ».
Je ne comprends pas cette phrase. Ne manque-t-il pas quelque chose avec << des nombres "modulo">>.
+ Sur un entier, c'est plus inquiétant car un dépassement vers plus l'infini renvoie un entier négatif si l'entier n'est pas signé, 0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte comme si 0 n'est pas signé, y compris pour les flottants.
Mon "il" ne remplaçait pas "0" mais "l'entier" : si je fais unsigned int grand = ... ; unsigned int trop_grand = grand * grand ; trop_grand vaudra 0 chez moi. Si je comprends bien, ce comportement n'est pas normé non plus.
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ? Et pour les entiers, existe-t-il une bibliothèque ?
James Kanze GABI Software
kanze
Henri de Solages wrote:
wrote:
[...]
En gros, l'implémentation est libre de faire ce que bon lui semble.
Super pour la portabilité !
En gros, quand tu as affaire à des flottants, il n'y a pas de portabilité. La raison, évidemment, c'est qu'on veut se baser sur ce que fait le hardware (sinon, les performances risquent d'en rendre l'utilisation impossible).
Ou plutôt, que l'abstraction des types entiers non-signés n'est pas un intervale sur des cardinaux, comme on pourrait s'y attendre, des nombres « modulo ».
Je ne comprends pas cette phrase. Ne manque-t-il pas quelque chose avec << des nombres "modulo">>.
Je ne crois pas, mais je ne suis pas particulièrement fort en vocabulaire mathématique. L'abstraction derrière les types entiers non-signés en C++, c'est l'arithmétique modulo ; si le type a n bits significatifs, l'arithmétique sur le type se fait modulo 2^n. Il ne peut donc jamais avoir un résultat qui n'est pas représentable.
+ Sur un entier, c'est plus inquiétant car un dépassement vers plus l'infini renvoie un entier négatif si l'entier n'est pas signé,
0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte comme si 0 n'est pas signé, y compris pour les flottants.
Mon "il" ne remplaçait pas "0" mais "l'entier" : si je fais unsigned int grand = ... ; unsigned int trop_grand = grand * grand ; trop_grand vaudra 0 chez moi.
Ça n'est pas normal. Il doit valoir le resultat réel modulo 2^n, où n est le nombre de bits.
Note bien que si pour tester, tu prends des nombres du genre 0x80000000 (pour une machine de 32 bits), le résultat modulo 2^32 serait bien 0.
Si je comprends bien, ce comportement n'est pas normé non plus.
Le comportement des entiers non-signés est normé. Les autres non.
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ? Et pour les entiers, existe-t-il une bibliothèque ?
Pour les entiers, je ne connais pas de machine qui traite les infinis. Ni de bibliothèque, d'ailleurs. Typiquement, quand on a besoin des infinis, on a un problème mathématique, ce qui veut dire des flottants.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Henri de Solages wrote:
kanze@gabi-soft.fr wrote:
[...]
En gros, l'implémentation est libre de faire ce que bon lui
semble.
Super pour la portabilité !
En gros, quand tu as affaire à des flottants, il n'y a pas de
portabilité. La raison, évidemment, c'est qu'on veut se baser
sur ce que fait le hardware (sinon, les performances risquent
d'en rendre l'utilisation impossible).
Ou plutôt, que l'abstraction des types entiers non-signés
n'est pas un intervale sur des cardinaux, comme on pourrait
s'y attendre, des nombres « modulo ».
Je ne comprends pas cette phrase. Ne manque-t-il pas quelque
chose avec << des nombres "modulo">>.
Je ne crois pas, mais je ne suis pas particulièrement fort en
vocabulaire mathématique. L'abstraction derrière les types
entiers non-signés en C++, c'est l'arithmétique modulo ; si le
type a n bits significatifs, l'arithmétique sur le type se fait
modulo 2^n. Il ne peut donc jamais avoir un résultat qui n'est
pas représentable.
+ Sur un entier, c'est plus inquiétant car un dépassement
vers plus l'infini renvoie un entier négatif si l'entier
n'est pas signé,
0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se
comporte comme si 0 n'est pas signé, y compris pour les
flottants.
Mon "il" ne remplaçait pas "0" mais "l'entier" :
si je fais
unsigned int grand = ... ;
unsigned int trop_grand = grand * grand ;
trop_grand vaudra 0 chez moi.
Ça n'est pas normal. Il doit valoir le resultat réel modulo 2^n,
où n est le nombre de bits.
Note bien que si pour tester, tu prends des nombres du genre
0x80000000 (pour une machine de 32 bits), le résultat modulo
2^32 serait bien 0.
Si je comprends bien, ce comportement n'est pas normé non
plus.
Le comportement des entiers non-signés est normé. Les autres
non.
Si ta machine supporte les flottants IEEE, c'est probable
que tu as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ? Et
pour les entiers, existe-t-il une bibliothèque ?
Pour les entiers, je ne connais pas de machine qui traite les
infinis. Ni de bibliothèque, d'ailleurs. Typiquement, quand on a
besoin des infinis, on a un problème mathématique, ce qui veut
dire des flottants.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
En gros, l'implémentation est libre de faire ce que bon lui semble.
Super pour la portabilité !
En gros, quand tu as affaire à des flottants, il n'y a pas de portabilité. La raison, évidemment, c'est qu'on veut se baser sur ce que fait le hardware (sinon, les performances risquent d'en rendre l'utilisation impossible).
Ou plutôt, que l'abstraction des types entiers non-signés n'est pas un intervale sur des cardinaux, comme on pourrait s'y attendre, des nombres « modulo ».
Je ne comprends pas cette phrase. Ne manque-t-il pas quelque chose avec << des nombres "modulo">>.
Je ne crois pas, mais je ne suis pas particulièrement fort en vocabulaire mathématique. L'abstraction derrière les types entiers non-signés en C++, c'est l'arithmétique modulo ; si le type a n bits significatifs, l'arithmétique sur le type se fait modulo 2^n. Il ne peut donc jamais avoir un résultat qui n'est pas représentable.
+ Sur un entier, c'est plus inquiétant car un dépassement vers plus l'infini renvoie un entier négatif si l'entier n'est pas signé,
0 s'il n'est pas signé.
Encore, c'est selon. La norme exige que le programme se comporte comme si 0 n'est pas signé, y compris pour les flottants.
Mon "il" ne remplaçait pas "0" mais "l'entier" : si je fais unsigned int grand = ... ; unsigned int trop_grand = grand * grand ; trop_grand vaudra 0 chez moi.
Ça n'est pas normal. Il doit valoir le resultat réel modulo 2^n, où n est le nombre de bits.
Note bien que si pour tester, tu prends des nombres du genre 0x80000000 (pour une machine de 32 bits), le résultat modulo 2^32 serait bien 0.
Si je comprends bien, ce comportement n'est pas normé non plus.
Le comportement des entiers non-signés est normé. Les autres non.
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ? Et pour les entiers, existe-t-il une bibliothèque ?
Pour les entiers, je ne connais pas de machine qui traite les infinis. Ni de bibliothèque, d'ailleurs. Typiquement, quand on a besoin des infinis, on a un problème mathématique, ce qui veut dire des flottants.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
marc.boyer.news
Henri de Solages wrote in message
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ? Et pour les entiers, existe-t-il une bibliothèque ?
On peut tout de même avec C++ faire "assez facilement" sa propre gestion des entiers avec dépassement (à un cout CPU bien sur non négligeable).
Sur ma page WEB, tu pourras trouver une classe qui provoque une exception en cas de débordement. Il ne devrait pas être trop difficile d'en faire une version qui particularise limits<T>::max() et limits<T>:min() en +oo et -oo.
http://www.enseeiht.fr/~boyer/Tools.html
Marc Boyer
Henri de Solages <solages@CICT.FR> wrote in message
Si ta machine supporte les flottants IEEE, c'est probable que tu
as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ?
Et pour les entiers, existe-t-il une bibliothèque ?
On peut tout de même avec C++ faire "assez facilement" sa propre
gestion des entiers avec dépassement (à un cout CPU bien sur non
négligeable).
Sur ma page WEB, tu pourras trouver une classe qui provoque une
exception en cas de débordement. Il ne devrait pas être trop difficile
d'en faire une version qui particularise limits<T>::max() et
limits<T>:min() en +oo et -oo.
Si ta machine supporte les flottants IEEE, c'est probable que tu as des fonctions nécessaires déjà.
Mais uniquement pour les nombres flottant, n'est-ce pas ? Et pour les entiers, existe-t-il une bibliothèque ?
On peut tout de même avec C++ faire "assez facilement" sa propre gestion des entiers avec dépassement (à un cout CPU bien sur non négligeable).
Sur ma page WEB, tu pourras trouver une classe qui provoque une exception en cas de débordement. Il ne devrait pas être trop difficile d'en faire une version qui particularise limits<T>::max() et limits<T>:min() en +oo et -oo.
http://www.enseeiht.fr/~boyer/Tools.html
Marc Boyer
Henri de Solages
Merci beaucoup, mais il semble manquer au moins 2 fichiers dans ton package : #include "CheckedNumeric.h" #include "unitaryTests.hpp"
del yahoo wrote:
Sur ma page WEB, tu pourras trouver une classe qui provoque une exception en cas de débordement. Il ne devrait pas être trop difficile d'en faire une version qui particularise limits<T>::max() et limits<T>:min() en +oo et -oo.
http://www.enseeiht.fr/~boyer/Tools.html
Marc Boyer
Merci beaucoup, mais il semble manquer au moins 2 fichiers dans ton package :
#include "CheckedNumeric.h"
#include "unitaryTests.hpp"
marc.boyer@enseeiht.yahoo.fr.invalid del yahoo wrote:
Sur ma page WEB, tu pourras trouver une classe qui provoque une
exception en cas de débordement. Il ne devrait pas être trop difficile
d'en faire une version qui particularise limits<T>::max() et
limits<T>:min() en +oo et -oo.
Merci beaucoup, mais il semble manquer au moins 2 fichiers dans ton package : #include "CheckedNumeric.h" #include "unitaryTests.hpp"
del yahoo wrote:
Sur ma page WEB, tu pourras trouver une classe qui provoque une exception en cas de débordement. Il ne devrait pas être trop difficile d'en faire une version qui particularise limits<T>::max() et limits<T>:min() en +oo et -oo.
http://www.enseeiht.fr/~boyer/Tools.html
Marc Boyer
marc.boyer.news
Henri de Solages wrote in message news:<d0k44s$lvl$...
Merci beaucoup, mais il semble manquer au moins 2 fichiers dans ton package : #include "CheckedNumeric.h" #include "unitaryTests.hpp"
Il manquait même beaucoup plus. Mais ça devrait etre nettement mieux maintenant.
Marc Boyer
Henri de Solages <solages@CICT.fr_> wrote in message news:<d0k44s$lvl$1@news.cict.fr>...
Merci beaucoup, mais il semble manquer au moins 2 fichiers dans ton package :
#include "CheckedNumeric.h"
#include "unitaryTests.hpp"
Il manquait même beaucoup plus.
Mais ça devrait etre nettement mieux maintenant.
