Je voudrai revenir sur une discussion qui s'est déjà tenue sur ce forum.
Vaut-il mieux utiliser des Long ou des Integer en terme de rapidité de
traitement ?
Il est évident que la question ne se pose que dans le domaine de validité
commun aux deux types (c'est à dire dans le domaine des integer)
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
ng
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement plus rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de méga de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur 16bits) contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Patrice Henrio wrote:
Je voudrai revenir sur une discussion qui s'est déjà tenue sur ce forum. Vaut-il mieux utiliser des Long ou des Integer en terme de rapidité de traitement ? Il est évident que la question ne se pose que dans le domaine de validité commun aux deux types (c'est à dire dans le domaine des integer)
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement plus
rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond
exactement à la taille des registres du proc (pas besoin de faire des
conversions du type nb sur n bits -> conversion vers 32bits -> calcul
(transfert ds le registre + calcul + "récupération" de la valeur) ->
conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de méga
de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur 16bits)
contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à
d'autre langage comme le C++ où ils dépendent de la machine).
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
Patrice Henrio wrote:
Je voudrai revenir sur une discussion qui s'est déjà tenue sur ce
forum. Vaut-il mieux utiliser des Long ou des Integer en terme de
rapidité de traitement ?
Il est évident que la question ne se pose que dans le domaine de
validité commun aux deux types (c'est à dire dans le domaine des
integer)
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement plus rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de méga de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur 16bits) contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Patrice Henrio wrote:
Je voudrai revenir sur une discussion qui s'est déjà tenue sur ce forum. Vaut-il mieux utiliser des Long ou des Integer en terme de rapidité de traitement ? Il est évident que la question ne se pose que dans le domaine de validité commun aux deux types (c'est à dire dans le domaine des integer)
Jean-Marc
"ng" a écrit dans le message de news:
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
plus
rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de
méga
de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
16bits)
contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
Hello,
j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut employer systématiquement des Long et ne conserver les Integer que lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une librairie tierce (écrite dans un autre langage par exemple). On gagnera (sans doute) en vitesse, mais même sans cela, on évite du coup de se poser des questions en employant uniquement des Long pour représenter les entiers. Le code est aussi plus agréable et plus simple à lire avec un type unique pour représenter les entiers.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"ng" <ng@ngsoft-fr.com> a écrit dans le message de
news:uUFfh3wAFHA.2792@TK2MSFTNGP15.phx.gbl...
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
plus
rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond
exactement à la taille des registres du proc (pas besoin de faire des
conversions du type nb sur n bits -> conversion vers 32bits -> calcul
(transfert ds le registre + calcul + "récupération" de la valeur) ->
conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de
méga
de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
16bits)
contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à
d'autre langage comme le C++ où ils dépendent de la machine).
Hello,
j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut
employer systématiquement des Long et ne conserver les Integer que
lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une
librairie tierce (écrite dans un autre langage par exemple). On gagnera
(sans doute) en vitesse, mais même sans cela, on évite du coup de se
poser des questions en employant uniquement des Long pour représenter
les entiers. Le code est aussi plus agréable et plus simple à lire avec
un type unique pour représenter les entiers.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
plus
rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de
méga
de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
16bits)
contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
Hello,
j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut employer systématiquement des Long et ne conserver les Integer que lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une librairie tierce (écrite dans un autre langage par exemple). On gagnera (sans doute) en vitesse, mais même sans cela, on évite du coup de se poser des questions en employant uniquement des Long pour représenter les entiers. Le code est aussi plus agréable et plus simple à lire avec un type unique pour représenter les entiers.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Patrice Henrio
Merci beaucoup de la précision, je pense que je vais ré-écrire une partie du programme en en tenant compte
"ng" a écrit dans le message de news:
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement plus rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de méga de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur 16bits) contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Patrice Henrio wrote:
Je voudrai revenir sur une discussion qui s'est déjà tenue sur ce forum. Vaut-il mieux utiliser des Long ou des Integer en terme de rapidité de traitement ? Il est évident que la question ne se pose que dans le domaine de validité commun aux deux types (c'est à dire dans le domaine des integer)
Merci beaucoup de la précision, je pense que je vais ré-écrire une partie du
programme en en tenant compte
"ng" <ng@ngsoft-fr.com> a écrit dans le message de news:
uUFfh3wAFHA.2792@TK2MSFTNGP15.phx.gbl...
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
plus rapide avec des longs car ceux-ci sont codés sur 32bits ce qui
correspond exactement à la taille des registres du proc (pas besoin de
faire des conversions du type nb sur n bits -> conversion vers 32bits ->
calcul (transfert ds le registre + calcul + "récupération" de la
valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de
méga de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
16bits) contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à
d'autre langage comme le C++ où ils dépendent de la machine).
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
Patrice Henrio wrote:
Je voudrai revenir sur une discussion qui s'est déjà tenue sur ce
forum. Vaut-il mieux utiliser des Long ou des Integer en terme de
rapidité de traitement ?
Il est évident que la question ne se pose que dans le domaine de
validité commun aux deux types (c'est à dire dans le domaine des
integer)
Merci beaucoup de la précision, je pense que je vais ré-écrire une partie du programme en en tenant compte
"ng" a écrit dans le message de news:
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement plus rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de méga de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur 16bits) contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Patrice Henrio wrote:
Je voudrai revenir sur une discussion qui s'est déjà tenue sur ce forum. Vaut-il mieux utiliser des Long ou des Integer en terme de rapidité de traitement ? Il est évident que la question ne se pose que dans le domaine de validité commun aux deux types (c'est à dire dans le domaine des integer)
Patrice Henrio
Il est difficile de se défaire des vieilles habitudes, du temps des proc à 16, voire 8, bits. A cette époque, il valait mieux privilégier des integer . Autres temps, autres moeurs !
"Jean-Marc" a écrit dans le message de news: 41f698f7$0$335$
"ng" a écrit dans le message de news:
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
plus
rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de
méga
de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
16bits)
contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
Hello,
j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut employer systématiquement des Long et ne conserver les Integer que lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une librairie tierce (écrite dans un autre langage par exemple). On gagnera (sans doute) en vitesse, mais même sans cela, on évite du coup de se poser des questions en employant uniquement des Long pour représenter les entiers. Le code est aussi plus agréable et plus simple à lire avec un type unique pour représenter les entiers.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Il est difficile de se défaire des vieilles habitudes, du temps des proc à
16, voire 8, bits. A cette époque, il valait mieux privilégier des integer .
Autres temps, autres moeurs !
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de news:
41f698f7$0$335$ba620e4c@news.skynet.be...
"ng" <ng@ngsoft-fr.com> a écrit dans le message de
news:uUFfh3wAFHA.2792@TK2MSFTNGP15.phx.gbl...
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
plus
rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond
exactement à la taille des registres du proc (pas besoin de faire des
conversions du type nb sur n bits -> conversion vers 32bits -> calcul
(transfert ds le registre + calcul + "récupération" de la valeur) ->
conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de
méga
de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
16bits)
contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à
d'autre langage comme le C++ où ils dépendent de la machine).
Hello,
j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut
employer systématiquement des Long et ne conserver les Integer que
lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une
librairie tierce (écrite dans un autre langage par exemple). On gagnera
(sans doute) en vitesse, mais même sans cela, on évite du coup de se
poser des questions en employant uniquement des Long pour représenter
les entiers. Le code est aussi plus agréable et plus simple à lire avec
un type unique pour représenter les entiers.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Il est difficile de se défaire des vieilles habitudes, du temps des proc à 16, voire 8, bits. A cette époque, il valait mieux privilégier des integer . Autres temps, autres moeurs !
"Jean-Marc" a écrit dans le message de news: 41f698f7$0$335$
"ng" a écrit dans le message de news:
Salut,
Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
plus
rapide avec des longs car ceux-ci sont codés sur 32bits ce qui correspond exactement à la taille des registres du proc (pas besoin de faire des conversions du type nb sur n bits -> conversion vers 32bits -> calcul (transfert ds le registre + calcul + "récupération" de la valeur) -> conversion vers n bits.).
De plus sur nos machines actuelles (disposant de plusieurs centaine de
méga
de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
16bits)
contrairement à autrefois.
On préférera ainsi priviligier, la plupart du temps, la rapidité.
(On notera que sous VB les types ont une taille fixes contrairement à d'autre langage comme le C++ où ils dépendent de la machine).
Hello,
j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut employer systématiquement des Long et ne conserver les Integer que lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une librairie tierce (écrite dans un autre langage par exemple). On gagnera (sans doute) en vitesse, mais même sans cela, on évite du coup de se poser des questions en employant uniquement des Long pour représenter les entiers. Le code est aussi plus agréable et plus simple à lire avec un type unique pour représenter les entiers.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Jean-Marc
Oui, j'ai aussi commencé sur des machines ou la méoire se comptait en octets, en Kilo-octets quand on était riche et on grapillait bits par bits ce qu'on pouvait. Ca ne donnait pas forcément de bonnes habitudes, mais c'était sport :-)
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Patrice Henrio" a écrit dans le message de news:%
Il est difficile de se défaire des vieilles habitudes, du temps des proc à 16, voire 8, bits. A cette époque, il valait mieux privilégier des integer
.
Autres temps, autres moeurs !
"Jean-Marc" a écrit dans le message de
news:
41f698f7$0$335$ > "ng" a écrit dans le message de > news: >> Salut, >> >> Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement > plus >> rapide avec des longs car ceux-ci sont codés sur 32bits ce qui
correspond
>> exactement à la taille des registres du proc (pas besoin de faire des >> conversions du type nb sur n bits -> conversion vers 32bits -> calcul >> (transfert ds le registre + calcul + "récupération" de la valeur) -> >> conversion vers n bits.). >> >> De plus sur nos machines actuelles (disposant de plusieurs centaine de > méga >> de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur > 16bits) >> contrairement à autrefois. >> >> On préférera ainsi priviligier, la plupart du temps, la rapidité. >> >> (On notera que sous VB les types ont une taille fixes contrairement à >> d'autre langage comme le C++ où ils dépendent de la machine). > > Hello, > > j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut > employer systématiquement des Long et ne conserver les Integer que > lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une > librairie tierce (écrite dans un autre langage par exemple). On gagnera > (sans doute) en vitesse, mais même sans cela, on évite du coup de se > poser des questions en employant uniquement des Long pour représenter > les entiers. Le code est aussi plus agréable et plus simple à lire avec > un type unique pour représenter les entiers. > > -- > Jean-marc > "There are only 10 kind of people > those who understand binary and those who don't." > >
Oui,
j'ai aussi commencé sur des machines ou la méoire se comptait en
octets, en Kilo-octets quand on était riche et on grapillait bits par
bits ce qu'on pouvait. Ca ne donnait pas forcément de bonnes habitudes,
mais c'était sport :-)
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Patrice Henrio" <patrice.henrio@laposte.net> a écrit dans le message de
news:%23BhvsJxAFHA.2624@TK2MSFTNGP11.phx.gbl...
Il est difficile de se défaire des vieilles habitudes, du temps des proc à
16, voire 8, bits. A cette époque, il valait mieux privilégier des integer
.
Autres temps, autres moeurs !
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de
news:
41f698f7$0$335$ba620e4c@news.skynet.be...
> "ng" <ng@ngsoft-fr.com> a écrit dans le message de
> news:uUFfh3wAFHA.2792@TK2MSFTNGP15.phx.gbl...
>> Salut,
>>
>> Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement
> plus
>> rapide avec des longs car ceux-ci sont codés sur 32bits ce qui
correspond
>> exactement à la taille des registres du proc (pas besoin de faire des
>> conversions du type nb sur n bits -> conversion vers 32bits -> calcul
>> (transfert ds le registre + calcul + "récupération" de la valeur) ->
>> conversion vers n bits.).
>>
>> De plus sur nos machines actuelles (disposant de plusieurs centaine de
> méga
>> de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur
> 16bits)
>> contrairement à autrefois.
>>
>> On préférera ainsi priviligier, la plupart du temps, la rapidité.
>>
>> (On notera que sous VB les types ont une taille fixes contrairement à
>> d'autre langage comme le C++ où ils dépendent de la machine).
>
> Hello,
>
> j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut
> employer systématiquement des Long et ne conserver les Integer que
> lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une
> librairie tierce (écrite dans un autre langage par exemple). On gagnera
> (sans doute) en vitesse, mais même sans cela, on évite du coup de se
> poser des questions en employant uniquement des Long pour représenter
> les entiers. Le code est aussi plus agréable et plus simple à lire avec
> un type unique pour représenter les entiers.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
Oui, j'ai aussi commencé sur des machines ou la méoire se comptait en octets, en Kilo-octets quand on était riche et on grapillait bits par bits ce qu'on pouvait. Ca ne donnait pas forcément de bonnes habitudes, mais c'était sport :-)
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Patrice Henrio" a écrit dans le message de news:%
Il est difficile de se défaire des vieilles habitudes, du temps des proc à 16, voire 8, bits. A cette époque, il valait mieux privilégier des integer
.
Autres temps, autres moeurs !
"Jean-Marc" a écrit dans le message de
news:
41f698f7$0$335$ > "ng" a écrit dans le message de > news: >> Salut, >> >> Pour faire des calculs (sur des processeurs 32bits) c'est théoriquement > plus >> rapide avec des longs car ceux-ci sont codés sur 32bits ce qui
correspond
>> exactement à la taille des registres du proc (pas besoin de faire des >> conversions du type nb sur n bits -> conversion vers 32bits -> calcul >> (transfert ds le registre + calcul + "récupération" de la valeur) -> >> conversion vers n bits.). >> >> De plus sur nos machines actuelles (disposant de plusieurs centaine de > méga >> de mémoire RAM) on est pas a 2 octets près (l'integer se codant sur > 16bits) >> contrairement à autrefois. >> >> On préférera ainsi priviligier, la plupart du temps, la rapidité. >> >> (On notera que sous VB les types ont une taille fixes contrairement à >> d'autre langage comme le C++ où ils dépendent de la machine). > > Hello, > > j'ajoute à l'excellente réponse de ng que si on fait du pur VB, on peut > employer systématiquement des Long et ne conserver les Integer que > lorsqu'on doit s'aligner sur type pour appeler des fonctions d'une > librairie tierce (écrite dans un autre langage par exemple). On gagnera > (sans doute) en vitesse, mais même sans cela, on évite du coup de se > poser des questions en employant uniquement des Long pour représenter > les entiers. Le code est aussi plus agréable et plus simple à lire avec > un type unique pour représenter les entiers. > > -- > Jean-marc > "There are only 10 kind of people > those who understand binary and those who don't." > >
