En fait je voudrais juste que dans le cas ou le resultat depasse la valeur max possible une execption soit generee.

long a,b;
a= a + b;
if(a > sizeof(long))
//lancer l'exception

 
on me l'a jamais faite celle là...
 
if( a > sizeof(long) )
 
équivaut à
 
if( a > 4 )

la meilleure solution serait, à froid, mais je suis pas sûr fodra que j'essayes:
 
int secured_add(long a, long b)
{
   long value;
 
   asm {
     mov eax,a
     add eax,b
     jno good
   }
 
   throw(...);
good:
   return value;
}

yep ça marche (t'as de la chance je t'ai fait un truc qui marche, passke je me suis jamais pris la tête à tester si j'avais des dépassements non désirés, vu qu'en général il sont désirés )
 

 
donnera:
 

merci bcp. je n aurais jamais pensé a utiliser de l assembleur pour resoudre le probleme.

eu... suffit pas tout simplement que a>(a+b) ? enfin pour un unsigned au moin

bon ça y est vous avez fini vos conneries de merde là ?
non mais vous avez complètement pété un plomb là
et je parle de vos conneries en matière d'exception ...
 
la seule solution est  
http://www.enseeiht.fr/~boyer/Tools.html

à la place de "jno xxxx" tu peux faire "mov ebx, 0 ; seto bl" dans ebx tu auras 1 si dépassement.

C'est drole qd même de marier C++ avec asm

euh y a une solution en pure C++ ....
ou est l'interet de cette affreuse bidouille ??

J'ai jeté un oeil au lien de Taz, le template est implémenté dans un fichier tpp. Comment ça se fait, je croyais que le stemplates devaient être implémentés dans le .h ?
 
Pour "l'algo" utilisé pour l"incrémentation, il est là:
On vaut additionner B à A :

 
min et max valent std::numeric_limits<numType>::min() et std::numeric_limits<numType>::max()

A la fin du hpp y a ca :
 
#include "CheckedNumeric.tpp"
#include "CheckedNumericNumericLimits.tpp"
 
.... ^^

"I can see clearly now"...

la mienne elle est ptet crade, mais elle passe pas par 30 comparaisons et branchement.... (et en même temps elle mais en évidence une certaine forme de lacune du langage puisque le hardware expose le dépassement, alors qu'avec le langage on doit faire un hack dégueulasse pour émuler les capacitées du hardware)
 
concernant l'exception, c'est un exemple Tazeuuuuuuuuu.....

le hack dégeux, c'est justement ton assembleur non-portable et en pkus difficile à utiliser dans du code alors qu'avec mon lien, tu peux invertir code normal avec des types de entiers et CN<type entiers> sans problème

j'ai précisé "pour émuler les capacitées du hardware". (c'est vrai que c'est assez variable)
 
mais si dans le C++ on déinierai un truc comme ça:
 
try (check_for_overflow)
{
  a=(b+c)/d;
}
 
catch( add_overflow e)
{
   ...
}
 
catch( div_overflow e )
{
 ...
}
 
je n'ai pas de solution miracle, mais il est vrai qu'une solution asm est un hack dégueu non portable, mais qu'une solution par bricolage de langage alors que la hardware offre potentiellement la chose est aussi un hack dégueu d'un autre point de vue.
 
ce qui serait bien c'est qu'au niveau ISO/ANSI/IEEE, une extension soit proposé pour le C++, afin d'utiliser les capacitées hardware, voir de les améliorer (il y a bien une exception pour les divisions par zéro, on peut très bien ajouter une exception à l'archi x86 quand le bit d'overflow est déclenché dans le registre des flags)
 
enfin ce que j'en dit.... (je fais juste que proposer hein)

Si on est ingénieur chez Intel peut être, sinon...

Le code officiel de dépassement :
OverFlow = Carry0(MSB)^Carry0(MSB-1)
 
source : intel

Questions bêtes au hasard...  
a) si a est signé il suffirait de comparer le signe de a avant et après l'opération, non (attention au cas du passage par zéro) ? Ou s'il est non signé, vérifier que le résultat est supérieur (ou égal) à la valeur d'origine (pour une addition).
b) pour quelle utilisation particulière a-t'on besoin de faire une telle vérification ?

Dans les 2 cas il suffit de vérifier que a1 > a0 après opération.

Pas si tu sommes deux entiers négatifs. On est obligé de distinguer le cas où b est < 0, d'où le code un peu tordu que tu as donné plus haut.