int decimal(int bcd)
{
  return ((bcd>>4)*10)+bcd%16;
}

Vu les votes sur mon pebkac, et sur les deux autres, le mien semble être un flop (même si il n'y a que deux CTLP). Les gens ne votent donc pas, mais pourquoi ?

A - C'est mal expliqué ?
B - Je ne précise pas ce qu'est le BCD (Clem à rajouté la définition de l'acronyme) ?
C - C'est bidon ?
D - Obi Wan Kenobi ?

je pense juste que c'est un peu trop technique (c'est à dire pour comprendre l'algo il faut savoir précisemment quel est le codage décimal binaire), et là sans me pencher sur les détails (genre ouvrir wikipédia pour voir comment ça marche) c'est vrai que je vois pas pourquoi changer le type int en unsigned long poserait problème (enfin si un peu, du coup le chiffre est pas codé pareil, complément à 2 toussa). Je vois pas non plus l'histoire du 0 à 99.

Au final les gens, bons princes, ne te downvotent pas mais upvotent pas non plus puisqu'ils ont pas saisi l'essence du pebkac ;)

pour résumer, le public de PEBKAC est constitué de PEBKACs.

Même avec la définition, ce n'est pas forcément facile à deviner... Et si en plus le lecteur ne comprend pas la manipulation de bits, c'est du chinois ! Personnellement je connais les deux pour avoir codé en assembleur sur ma calculatrice (HP 48), mais je ne pense pas être normal ;-)

Au vu de ta fonction, tu utilises du packed-BCD : un chiffre par quartet.

Pour faire simple, cette méthode de codage permet de stoquer un nombre simplement en collant les chiffres (en décimal) dans des quartets. Ainsi, 42 sera transformé en l'octet 0x42, soit 66 en décimal. L'intérêt de ce codage est la facilité d'afficher un nombre décimal sans faire de division par 10 : seuls des décalages de quartets sont nécessaires.

Quant à la fonction, bcd >> 4 signifie un décalage de 4 bits vers la droite, et donc isole le chiffre des dizaines. Multiplié par 10, le chiffre est à sa place dans le nombre final. Pour les unités, un modulo 16 (reste de la division entière) est utilisé... Ca dépend de l'architecture derrière, mais en général un ET logique est plus performant et évite la division : bcd & 15, ou mieux bcd & 0x0F.

Ben... en effet, si on imagine que le type a besoin de décoder des valeurs >99 en BCD, la réponse du kissikoné est totalement enrageante.

D'un autre côté, s'il n'a pas besoin de valeurs >99, et qu'il cherche juste a résoudre une erreur stupide de compilation, changer le type dans la signature est en effet l'approche la plus simple.

Alors pourquoi suspecter le second cas plutôt que le premier ? parce que l'implémentation donnée, de base, aurait plus de sens avec un char qu'avec un int.

Y'a également "convertir de BCD vers décimal", qui laisse un peu penser que l'OP est un peu embrouillé dans sa tête, "convertir de BCD vers un entier natif" serait plus correct.

Sans contexte, dur de se faire une opinion.

Si jamais une "mauvaise valeur" devait arriver dans cette variable, il est préférable qu'elle soit rattrapée "manuellement" par un test qui vérifie si elle est bien inférieure à 99, plutôt que de tout faire planter...

Je dois avoir vu l'écriture BCD en première (BAC électronique), qui a son avantage pour l'affichage de nombres sur des afficheurs 7 segments.

J'ai pensé que même ceux ayant un cursus plus orienté software connaissaient aussi ce codage/écriture. A tort apparemment.

Il faudrait que je retrouve le lien, mais la personne posant la question devait travailler sur une architecture 8 bits (donc on a bien un codage BCD compris entre 0 et 99). Si sa question portait sur le simple fait de remplacer le type par un autre, tout en gardant la même plage de valeurs, c'est un pebkac encore pire que celui qui lui a répondu.

Mais même sur une arch 8 bits, un int est sensé contenir minimum 16 bits, et dans la fonction donnée, il n'y a pas de test de débordement, justement, alors soit:

1) l'auteur veut utiliser les types a bon escient, et le type original devrait être char, pas int

2) l'auteur n'en a rien à battre des types et veut juste que ça marche, la troncature étant le comportement désiré, auquel cas, si on se permet d'avoir int plutot que char, pourquoi pas long également.

Dans les deux cas, y'a donc au moins une fraction du pebkac qui revient à celui qui pose la question.

Et ça n'a pas de sens de tester la valeur de retour après coup, ça devrait être évident.

Bah disons surtout que tout le monde n'est pas développeur, ça n'en fait pas des PEBKAC pour autant.... Ok peut s'y connaitre en informatique sans savoir développer...

http://www.velocityreviews.com/forums/t315094-decimal-to-bcd-for-long-[...]
Le "kissikoné" ne donne pas une solution, mais demande de préciser quel est le problème, la question d'origine étant assez mal formulée (la fonction présenté converti des nombres sur deux digits, et fonctionne pour des unsigned long ; le vrai problème semble donc ne pas être sur le type utilisé).

Comme PEBKAC, je préfère largement la deuxième réponse:

int decimal(int bcd)
 {
    int result;
    while(bcd) {
       result += bcd % 10;
       bcd = (int) bcd / 10;
    }
    return(result);
 }
 /Note: untested code. I could be a dumbass, but it looks right./

- Variable utilisé sans être initialisée.
- Pas de décalage de pour passer des unités aux dizaines dans le résultat (e.g. 99 => 9+9 => 18).
- Modulo et division par 10, au lieu de 16.
- Transtypage explicite de int vers int.
- Utilisation de int, alors que l'OP demande une version unsigned long.

Oh c'est une belle brochette là. Effectivement je préfère cet exemple là aussi. :D

Désolé Link, mais bien qu'ayant une Licence, je n'ai jamais entendu parler de ce truc.

Justement, en lisant ton pebkac, je me suis demandé sur quelle architecture bizarre on pouvait rencontrer du BCD dans des unsigned long....

On peut aussi savoir développer, sans avoir fait d'assembleur...
Perso, j'ai compris les calculs qui étaient fait, mais comprend pourquoi c'était fait, heureusement qu'il y avait le commentaire de Acné...

j'ai pas vu d'assembleur dans son code.

Le BCD est fréquent en COBOL(Comp-3 pour les intimes). J'ai eu à créer, il ya plus de dix ans, un convertisseur nombres normaux(integer ou long VBA)==>BCD (ainsi que ASCII==>EBCDIC) en VBA pour EXCEL, pour pouvoir injecter mes cas tests sur la machine MVS. C'est un calcul un peu tordu. Le retour BCD vers nombre exploitable dans le monde réel (lire : Windows) aussi, d'ailleurs(mais je récupérais la donnée en string, et je découpais octet par octet, comme un bourrin - après tout, je ne suis pas prog' de formation).