N est une constante, apparemment, ainsi que P pendant le
calcul. Votre problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
Jamais. Il veut multiplier, non décaler.
Surtout que je déclare resultat en int (et non unsigned int). Laisser
faire le compilateur, en déclarant toutefois N const si c'est le cas.
Question subsidiaire: (je me situe pour l'exemple dans une
architecture où la multiplication serait très pénalisante par rapport
au décalage). Si N est constant dans une boucle, faut-il faire
confiance au compilateur ou est-il préférable de l'orienter par un
cast ou autre méthode ? Si oui, laquelle (en C et en C++) ?
N est une constante, apparemment, ainsi que P pendant le
calcul. Votre problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
Jamais. Il veut multiplier, non décaler.
Surtout que je déclare resultat en int (et non unsigned int). Laisser
faire le compilateur, en déclarant toutefois N const si c'est le cas.
Question subsidiaire: (je me situe pour l'exemple dans une
architecture où la multiplication serait très pénalisante par rapport
au décalage). Si N est constant dans une boucle, faut-il faire
confiance au compilateur ou est-il préférable de l'orienter par un
cast ou autre méthode ? Si oui, laquelle (en C et en C++) ?
N est une constante, apparemment, ainsi que P pendant le
calcul. Votre problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
Jamais. Il veut multiplier, non décaler.
Surtout que je déclare resultat en int (et non unsigned int). Laisser
faire le compilateur, en déclarant toutefois N const si c'est le cas.
Question subsidiaire: (je me situe pour l'exemple dans une
architecture où la multiplication serait très pénalisante par rapport
au décalage). Si N est constant dans une boucle, faut-il faire
confiance au compilateur ou est-il préférable de l'orienter par un
cast ou autre méthode ? Si oui, laquelle (en C et en C++) ?
j'imaginais mal le cas de l'appel de floor pour un int, qui n'est pas
très naturel 8-/
d'ailleurs comme dit dans un autre msg, la meileure solution ici est
de rester en int tout du long, mais en faisant la division euclidienne
comme il faut :
int n = (a*b) / c;
En passant, ces surcharges cassent du code existant pré-norme,
puisqu'avant la norme, quelque chose comme exp(3) était
légal. L'intérêt du surcharge est évident (à mon avis, en tout cas),
mais ils auraient peut-être dû ajouter des surcharges sur int, etc.,
pour ce genre de cas.
enfin, pour floor cette surcharge n'est pas un problème, vu que c'est
assez inutile de passer un nbre entier à la fonction. Sinon la norme
n'a pas du juger utile d'ajouter une surcharge sur int qui
n'apporterait rien d'autre que la compatibilité avec le code
pré-norme.
j'imaginais mal le cas de l'appel de floor pour un int, qui n'est pas
très naturel 8-/
d'ailleurs comme dit dans un autre msg, la meileure solution ici est
de rester en int tout du long, mais en faisant la division euclidienne
comme il faut :
int n = (a*b) / c;
En passant, ces surcharges cassent du code existant pré-norme,
puisqu'avant la norme, quelque chose comme exp(3) était
légal. L'intérêt du surcharge est évident (à mon avis, en tout cas),
mais ils auraient peut-être dû ajouter des surcharges sur int, etc.,
pour ce genre de cas.
enfin, pour floor cette surcharge n'est pas un problème, vu que c'est
assez inutile de passer un nbre entier à la fonction. Sinon la norme
n'a pas du juger utile d'ajouter une surcharge sur int qui
n'apporterait rien d'autre que la compatibilité avec le code
pré-norme.
j'imaginais mal le cas de l'appel de floor pour un int, qui n'est pas
très naturel 8-/
d'ailleurs comme dit dans un autre msg, la meileure solution ici est
de rester en int tout du long, mais en faisant la division euclidienne
comme il faut :
int n = (a*b) / c;
En passant, ces surcharges cassent du code existant pré-norme,
puisqu'avant la norme, quelque chose comme exp(3) était
légal. L'intérêt du surcharge est évident (à mon avis, en tout cas),
mais ils auraient peut-être dû ajouter des surcharges sur int, etc.,
pour ce genre de cas.
enfin, pour floor cette surcharge n'est pas un problème, vu que c'est
assez inutile de passer un nbre entier à la fonction. Sinon la norme
n'a pas du juger utile d'ajouter une surcharge sur int qui
n'apporterait rien d'autre que la compatibilité avec le code
pré-norme.
drkm typa:Pierre Maurette writes:
[...]Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à
dire comme un problème d'entiers.
Et qu'advient-il lorsque
a == std::numeric_limits< int >::max() ;
Oui. J'avais fait des hypothèses sur le problème qui n'étaient pas
mentionnées dans le message original (mais que le second message de
Rincevent rendent valables). En fait, le message original est un peu
étrange, je ne vois ce que vient y faire le floor() puisque a, b et c
me semblent devoir être tous positifs.
? En fait, je suis en train de me demander s'il n'y a pas conversion
du résultat de « a * c » en un long int dans ce cas, mais je ne pense
pas ; et ce ne ferait que déplacer le problème. Tandis que
int result = static_cast< int >(
static_cast< double >( a ) / b * c
) ;
gère correctement le problème.
Je trouve dommage de passer par des double si le contexte rend cette
précaution inutile, et je mettrais ma main à couper que c'est ici le
cas.
Ça dépend de l'étendue des valeurs admissibles pour a, b et c, mais
également de la fréquence du calcul.
Il est clair que si le calcul est fait une seule fois (avant une
boucle par exemple), il est inutile de trop se casser la tête. Surtout
si l'on ne sait rien sur a, b et c, auquel cas il faudrait faire
quelques tests pour choisir entre (a/b)*c, (c/b)*a et (a*c)/b, pas
nécessairement plus lent que la passage par double, mais un peu plus
prise de tête, moins lisible, etc...
Attention également, le passage par double donne un résultat qui peut
être différent (de celui exact donné par des int) si a*c est divisible
par b.
D'une façon plus générale, il me semble voir souvent des erreurs dues
à une utilisation abusive d'opérations "réelles" sur une problématique
d'entiers. Ce qui n'en disqualifie pas non plus l'usage modéré.
Pour ce qui est de la promotion en long int, je n'ai trouvé que
4.5/1. Je ne suis pas certain qu'il s'agit du bon paragraphe, mais
si c'est le cas, cette promotion en long int n'existe pas (ce que je
pense).
Il me semble également qu'il ne doit pas y avoir de promotion int ->
long int.
Mais je travaille (c'est une erreur) avec en tête des int et des long
int équivalents.
Si ce n'est pas le cas: int result = static_cast<int>(static_cast<long
int>(a)/b*c);
drkm <usenet.fclcxx@fgeorges.org> typa:
Pierre Maurette <maurette.pierre@free.fr> writes:
[...]
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à
dire comme un problème d'entiers.
Et qu'advient-il lorsque
a == std::numeric_limits< int >::max() ;
Oui. J'avais fait des hypothèses sur le problème qui n'étaient pas
mentionnées dans le message original (mais que le second message de
Rincevent rendent valables). En fait, le message original est un peu
étrange, je ne vois ce que vient y faire le floor() puisque a, b et c
me semblent devoir être tous positifs.
? En fait, je suis en train de me demander s'il n'y a pas conversion
du résultat de « a * c » en un long int dans ce cas, mais je ne pense
pas ; et ce ne ferait que déplacer le problème. Tandis que
int result = static_cast< int >(
static_cast< double >( a ) / b * c
) ;
gère correctement le problème.
Je trouve dommage de passer par des double si le contexte rend cette
précaution inutile, et je mettrais ma main à couper que c'est ici le
cas.
Ça dépend de l'étendue des valeurs admissibles pour a, b et c, mais
également de la fréquence du calcul.
Il est clair que si le calcul est fait une seule fois (avant une
boucle par exemple), il est inutile de trop se casser la tête. Surtout
si l'on ne sait rien sur a, b et c, auquel cas il faudrait faire
quelques tests pour choisir entre (a/b)*c, (c/b)*a et (a*c)/b, pas
nécessairement plus lent que la passage par double, mais un peu plus
prise de tête, moins lisible, etc...
Attention également, le passage par double donne un résultat qui peut
être différent (de celui exact donné par des int) si a*c est divisible
par b.
D'une façon plus générale, il me semble voir souvent des erreurs dues
à une utilisation abusive d'opérations "réelles" sur une problématique
d'entiers. Ce qui n'en disqualifie pas non plus l'usage modéré.
Pour ce qui est de la promotion en long int, je n'ai trouvé que
4.5/1. Je ne suis pas certain qu'il s'agit du bon paragraphe, mais
si c'est le cas, cette promotion en long int n'existe pas (ce que je
pense).
Il me semble également qu'il ne doit pas y avoir de promotion int ->
long int.
Mais je travaille (c'est une erreur) avec en tête des int et des long
int équivalents.
Si ce n'est pas le cas: int result = static_cast<int>(static_cast<long
int>(a)/b*c);
drkm typa:Pierre Maurette writes:
[...]Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à
dire comme un problème d'entiers.
Et qu'advient-il lorsque
a == std::numeric_limits< int >::max() ;
Oui. J'avais fait des hypothèses sur le problème qui n'étaient pas
mentionnées dans le message original (mais que le second message de
Rincevent rendent valables). En fait, le message original est un peu
étrange, je ne vois ce que vient y faire le floor() puisque a, b et c
me semblent devoir être tous positifs.
? En fait, je suis en train de me demander s'il n'y a pas conversion
du résultat de « a * c » en un long int dans ce cas, mais je ne pense
pas ; et ce ne ferait que déplacer le problème. Tandis que
int result = static_cast< int >(
static_cast< double >( a ) / b * c
) ;
gère correctement le problème.
Je trouve dommage de passer par des double si le contexte rend cette
précaution inutile, et je mettrais ma main à couper que c'est ici le
cas.
Ça dépend de l'étendue des valeurs admissibles pour a, b et c, mais
également de la fréquence du calcul.
Il est clair que si le calcul est fait une seule fois (avant une
boucle par exemple), il est inutile de trop se casser la tête. Surtout
si l'on ne sait rien sur a, b et c, auquel cas il faudrait faire
quelques tests pour choisir entre (a/b)*c, (c/b)*a et (a*c)/b, pas
nécessairement plus lent que la passage par double, mais un peu plus
prise de tête, moins lisible, etc...
Attention également, le passage par double donne un résultat qui peut
être différent (de celui exact donné par des int) si a*c est divisible
par b.
D'une façon plus générale, il me semble voir souvent des erreurs dues
à une utilisation abusive d'opérations "réelles" sur une problématique
d'entiers. Ce qui n'en disqualifie pas non plus l'usage modéré.
Pour ce qui est de la promotion en long int, je n'ai trouvé que
4.5/1. Je ne suis pas certain qu'il s'agit du bon paragraphe, mais
si c'est le cas, cette promotion en long int n'existe pas (ce que je
pense).
Il me semble également qu'il ne doit pas y avoir de promotion int ->
long int.
Mais je travaille (c'est une erreur) avec en tête des int et des long
int équivalents.
Si ce n'est pas le cas: int result = static_cast<int>(static_cast<long
int>(a)/b*c);
Pierre Maurette wrote in message
news:..."Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres naturels.
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<oaa4b0p9oquthc0m4rdj870bfpfoma32ul@4ax.com>...
"Rincevent" <rincevent@nospam.fr> typa:
5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres naturels.
Pierre Maurette wrote in message
news:..."Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres naturels.
Mais jamais je ne pourrait
Mais jamais je ne pourrait
Mais jamais je ne pourrait
Pour les classes on conseille de s'inspirer de "l'univers du problème" ;
serait-ce une tare de faire de même pour d'autres types, encore
plus basiques ? Quand une variable représente un entier qui n'a
aucun sens autre que positif, cela me révulse absolument qu'il
ne soit pas unsigned.
Pour les classes on conseille de s'inspirer de "l'univers du problème" ;
serait-ce une tare de faire de même pour d'autres types, encore
plus basiques ? Quand une variable représente un entier qui n'a
aucun sens autre que positif, cela me révulse absolument qu'il
ne soit pas unsigned.
Pour les classes on conseille de s'inspirer de "l'univers du problème" ;
serait-ce une tare de faire de même pour d'autres types, encore
plus basiques ? Quand une variable représente un entier qui n'a
aucun sens autre que positif, cela me révulse absolument qu'il
ne soit pas unsigned.
Dans le monde des unsigned int, "être positif" n'a pas de sens.
Et c'est vraiment dans la quintessence du type : le concept auquel
correspond le mieux les types entiers unsigned n'est pas pas celui des
nombres entiers positifs,
mais celui de Z/nZ (i.e. arithmétique modulo n -avec n puissance de 2
précisémént) dont le caractère cyclique s'oppose profondément à toute
relation d'ordre compatible avec l'addition.
Dans le monde des unsigned int, "être positif" n'a pas de sens.
Et c'est vraiment dans la quintessence du type : le concept auquel
correspond le mieux les types entiers unsigned n'est pas pas celui des
nombres entiers positifs,
mais celui de Z/nZ (i.e. arithmétique modulo n -avec n puissance de 2
précisémént) dont le caractère cyclique s'oppose profondément à toute
relation d'ordre compatible avec l'addition.
Dans le monde des unsigned int, "être positif" n'a pas de sens.
Et c'est vraiment dans la quintessence du type : le concept auquel
correspond le mieux les types entiers unsigned n'est pas pas celui des
nombres entiers positifs,
mais celui de Z/nZ (i.e. arithmétique modulo n -avec n puissance de 2
précisémént) dont le caractère cyclique s'oppose profondément à toute
relation d'ordre compatible avec l'addition.
Dans news:,Pierre Maurette wrote in message
news:...Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Tout à fait d'accord. Mais C/C++ ne sont pas seuls dans leur choix.
Tiens vous êtes bizarres : au contraire, j'ai toujours trouvé que les
langages où les opérations classiques (+-*/) sont dans le type des
données SAUF la division étaient plutôt bizarres. Il me semble que,
la plupart du temps, si on a des entiers pour les calculs, on veut un
entier comme résultat et la division réelle ne fait qu'apporter des
conversions inutiles.
Demandez à quelqu'un qui fait du VB s'il fait attention d'utiliser la
division entière quand il en a besoin (au moins en Pascal, il me
semble qu'il fallait convertir explicitement le résultat de la
division pour le ravoir en entier).
Je comprends que le programmeur peut faire des erreurs s'il ne fait
pas attention à l'ordre des opérations en calcul entier, mais il faut
apprendre car il y a aussi des problèmes avec l'ordre des opérations
dans les calculs réels, même si la plupart des programmeurs ne
semblent pas s'en préoccuper.
Dans news:d6652001.0405242305.6929a8fb@posting.google.com,
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<cat3b05qmcpdous2n731hvsfu9lobbqskq@4ax.com>...
Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Tout à fait d'accord. Mais C/C++ ne sont pas seuls dans leur choix.
Tiens vous êtes bizarres : au contraire, j'ai toujours trouvé que les
langages où les opérations classiques (+-*/) sont dans le type des
données SAUF la division étaient plutôt bizarres. Il me semble que,
la plupart du temps, si on a des entiers pour les calculs, on veut un
entier comme résultat et la division réelle ne fait qu'apporter des
conversions inutiles.
Demandez à quelqu'un qui fait du VB s'il fait attention d'utiliser la
division entière quand il en a besoin (au moins en Pascal, il me
semble qu'il fallait convertir explicitement le résultat de la
division pour le ravoir en entier).
Je comprends que le programmeur peut faire des erreurs s'il ne fait
pas attention à l'ordre des opérations en calcul entier, mais il faut
apprendre car il y a aussi des problèmes avec l'ordre des opérations
dans les calculs réels, même si la plupart des programmeurs ne
semblent pas s'en préoccuper.
Dans news:,Pierre Maurette wrote in message
news:...Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Tout à fait d'accord. Mais C/C++ ne sont pas seuls dans leur choix.
Tiens vous êtes bizarres : au contraire, j'ai toujours trouvé que les
langages où les opérations classiques (+-*/) sont dans le type des
données SAUF la division étaient plutôt bizarres. Il me semble que,
la plupart du temps, si on a des entiers pour les calculs, on veut un
entier comme résultat et la division réelle ne fait qu'apporter des
conversions inutiles.
Demandez à quelqu'un qui fait du VB s'il fait attention d'utiliser la
division entière quand il en a besoin (au moins en Pascal, il me
semble qu'il fallait convertir explicitement le résultat de la
division pour le ravoir en entier).
Je comprends que le programmeur peut faire des erreurs s'il ne fait
pas attention à l'ordre des opérations en calcul entier, mais il faut
apprendre car il y a aussi des problèmes avec l'ordre des opérations
dans les calculs réels, même si la plupart des programmeurs ne
semblent pas s'en préoccuper.
Dans news:,Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels. Le type naturel pour les calculs entiers en C/C++, c'est
int. On n'utilise d'autres types que dans les cas exceptionnels. On
n'utilise donc unsigned que dans les cas où on a besoin d'un de ces
caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats « bizarre »,
même si on manipule le bit de poids fort. (C'est surtout important
pour les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le
calcul d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces
niveaux de gris, par exemple, je verrais bien un unsigned
char, parce que signé, il lui faudrait un short.
C'est à peu près ce que je pense aussi, mais les nombreuses
discussions (sur clc++m par exemple) montrent bien que ce n'est pas
complètement noir ou blanc. En particulier, le fait que la
bibliothèque standard regorge de unsigned (pour aucune des raisons
citées plus haut) indique qu'au moins quelques grands experts ont,
pendant un certain temps, pensé autrement.
Ceci dit, je crois que c'est un « erreur » qui est du même
niveau que les conversions implicites à perte de valeur :
on
sent bien que ces « experts » mettent les compilateurs en mode
« pas d'avertissement pour ces petits détails » alors qu'au
contraire plusieurs personnes, dont moi, aiment que les
programmes passent sans avertissement, même au niveau le plus
élevé...
Dans news:d6652001.0405242327.5c289e3d@posting.google.com,
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels. Le type naturel pour les calculs entiers en C/C++, c'est
int. On n'utilise d'autres types que dans les cas exceptionnels. On
n'utilise donc unsigned que dans les cas où on a besoin d'un de ces
caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats « bizarre »,
même si on manipule le bit de poids fort. (C'est surtout important
pour les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le
calcul d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces
niveaux de gris, par exemple, je verrais bien un unsigned
char, parce que signé, il lui faudrait un short.
C'est à peu près ce que je pense aussi, mais les nombreuses
discussions (sur clc++m par exemple) montrent bien que ce n'est pas
complètement noir ou blanc. En particulier, le fait que la
bibliothèque standard regorge de unsigned (pour aucune des raisons
citées plus haut) indique qu'au moins quelques grands experts ont,
pendant un certain temps, pensé autrement.
Ceci dit, je crois que c'est un « erreur » qui est du même
niveau que les conversions implicites à perte de valeur :
on
sent bien que ces « experts » mettent les compilateurs en mode
« pas d'avertissement pour ces petits détails » alors qu'au
contraire plusieurs personnes, dont moi, aiment que les
programmes passent sans avertissement, même au niveau le plus
élevé...
Dans news:,Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels. Le type naturel pour les calculs entiers en C/C++, c'est
int. On n'utilise d'autres types que dans les cas exceptionnels. On
n'utilise donc unsigned que dans les cas où on a besoin d'un de ces
caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats « bizarre »,
même si on manipule le bit de poids fort. (C'est surtout important
pour les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le
calcul d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces
niveaux de gris, par exemple, je verrais bien un unsigned
char, parce que signé, il lui faudrait un short.
C'est à peu près ce que je pense aussi, mais les nombreuses
discussions (sur clc++m par exemple) montrent bien que ce n'est pas
complètement noir ou blanc. En particulier, le fait que la
bibliothèque standard regorge de unsigned (pour aucune des raisons
citées plus haut) indique qu'au moins quelques grands experts ont,
pendant un certain temps, pensé autrement.
Ceci dit, je crois que c'est un « erreur » qui est du même
niveau que les conversions implicites à perte de valeur :
on
sent bien que ces « experts » mettent les compilateurs en mode
« pas d'avertissement pour ces petits détails » alors qu'au
contraire plusieurs personnes, dont moi, aiment que les
programmes passent sans avertissement, même au niveau le plus
élevé...
a écrit dans le message news:Pierre Maurette wrote in message
news:..."Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur
est donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas
forcément un entier, on prends donc la partie entière pour être
sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels.
Pour les classes on conseille de s'inspirer de "l'univers du problème"
; serait-ce une tare de faire de même pour d'autres types, encore plus
basiques ? Quand une variable représente un entier qui n'a aucun sens
autre que positif, cela me révulse absolument qu'il ne soit pas
unsigned.
Je veux bien regarder la machine, toutes considérations conceptuelles
égales par ailleurs. Mais jamais je ne pourrait m'habituer à violer un
concept pour des raisons bassement techniques.
<kanze@gabi-soft.fr> a écrit dans le message news:
d6652001.0405242327.5c289e3d@posting.google.com...
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<oaa4b0p9oquthc0m4rdj870bfpfoma32ul@4ax.com>...
"Rincevent" <rincevent@nospam.fr> typa:
5) Pour la particules appartenant à la k-ème classe, sa couleur
est donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas
forcément un entier, on prends donc la partie entière pour être
sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels.
Pour les classes on conseille de s'inspirer de "l'univers du problème"
; serait-ce une tare de faire de même pour d'autres types, encore plus
basiques ? Quand une variable représente un entier qui n'a aucun sens
autre que positif, cela me révulse absolument qu'il ne soit pas
unsigned.
Je veux bien regarder la machine, toutes considérations conceptuelles
égales par ailleurs. Mais jamais je ne pourrait m'habituer à violer un
concept pour des raisons bassement techniques.
a écrit dans le message news:Pierre Maurette wrote in message
news:..."Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur
est donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas
forcément un entier, on prends donc la partie entière pour être
sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels.
Pour les classes on conseille de s'inspirer de "l'univers du problème"
; serait-ce une tare de faire de même pour d'autres types, encore plus
basiques ? Quand une variable représente un entier qui n'a aucun sens
autre que positif, cela me révulse absolument qu'il ne soit pas
unsigned.
Je veux bien regarder la machine, toutes considérations conceptuelles
égales par ailleurs. Mais jamais je ne pourrait m'habituer à violer un
concept pour des raisons bassement techniques.
