Discussion :

[hetlar]

Salut ,

J'ai un code en C que je dois le transférer en java.en java je peux pas impelmenter des variables de type uint16 et uint32. Donc quelle est la solution ?

Merci Bien

[droggo]

Kei,

Il n'y a pas de type unsigned en Java !

Eh oui, on peut se demander pourquoi une telle gigantesque lacune.

[hetlar]

ET type int16 et int32 en java?

[droggo]

Koa,

Ce genre de question est aisément résolu en ouvrant/lisant n'importe quel livre/didacticiel sur Java, c'est absolument basique.

Et à l'occasion, on peut faire un tour dans la définition du langage, ce qui n'est jamais du temps perdu.

[nabil.g]

salut,
cette extension comme JAR externe ne pourrait pas faire l'affaire?
http://sourceforge.net/projects/juint/

[thelvin]

cette extension comme JAR externe ne pourrait pas faire l'affaire?
http://sourceforge.net/projects/juint/

Elle utilise des objets à la place de types de base, et des méthodes à la place d'opérateurs. Ce qui fait donc une syntaxe assez lourde et des calculs très inefficaces.
Mais quand c'est pas important, oui, c'est une manière de régler le problème sans se poser de question.

[mohamine1989]

Slt
C'est dommage, avec uint32, on peut obtenir une dynamique :0 -> 2^32, donc inutile de recourir a un float pour des valeurs 2^31 - 1 -> 2^32
Dommage
Bon courage

[thelvin]

C'est dommage, avec uint32, on peut obtenir une dynamique :0 -> 2^32,

Un long est aussi capable de contenir tout ça -_-°. Il n'y est pas limité, certes, ce n'est pas l'idéal. D'un autre côté c'est pas comme si on avait souvent des nombres supérieurs à 2G et qui doivent absolument être contraints < 4G.

donc inutile de recourir a un float pour des valeurs 2^31 - 1 -> 2^32

Il ne faut pas utiliser de flottants pour ça de toute façon. Un long fait très bien l'affaire, la précision du float n'est pas suffisante, et les calculs double trop longs.

J'ajoute que si on veut vraiment stocker des nombres limités à l'ensemble des valeurs de uint32, et qu'on est prêt à utiliser des "trucs" pour ça, on peut très bien décider que int peut le faire. int contient bel et bien un espace de 2^32 valeurs différentes. Il n'y a qu'à décider que les nombres négatifs n'existent pas et sont en réalité l'espace 2^31 -> 2^32 - 1. L'addition, la soustraction, la multiplication, la division, le modulo et l'égalité marchent parfaitement.
Ce qui ne marche pas, c'est la conversion d'un type à l'autre, genre int -> String ou int -> long, le int sera considéré négatif par Java s'il dépasse 2 ^ 31 - 1. Il suffit de le savoir et de le gérer.

[droggo]

Kia,

Un long est aussi capable de contenir tout ça -_-°. Il n'y est pas limité, certes, ce n'est pas l'idéal. D'un autre côté c'est pas comme si on avait souvent des nombres supérieurs à 2G et qui doivent absolument être contraints < 4G.



Il ne faut pas utiliser de flottants pour ça de toute façon. Un long fait très bien l'affaire, la précision du float n'est pas suffisante, et les calculs double trop longs.

J'ajoute que si on veut vraiment stocker des nombres limités à l'ensemble des valeurs de uint32, et qu'on est prêt à utiliser des "trucs" pour ça, on peut très bien décider que int peut le faire. int contient bel et bien un espace de 2^32 valeurs différentes. Il n'y a qu'à décider que les nombres négatifs n'existent pas et sont en réalité l'espace 2^31 -> 2^32 - 1. L'addition, la soustraction, la multiplication, la division, le modulo et l'égalité marchent parfaitement.
Ce qui ne marche pas, c'est la conversion d'un type à l'autre, genre int -> String ou int -> long, le int sera considéré négatif par Java s'il dépasse 2 ^ 31 - 1. Il suffit de le savoir et de le gérer.

Évidemment, pourquoi avoir un système qui permettrait de faire simple, quand on en a un qui oblige à faire compliqué.

[tchize_]

les différences entre les signés et non signés sont très faibles, c'est pour ça que java ne les a jamais implémentés. Sans compter que ça complique fortement les chose quand on copie un signé dans un non signé et vice - versa.

Comme dit thelvin, les opération de bases sont toutes les même. Oui un non signé peux aller jusque 2^32 (ou 2^64) et un signé est limité à un bit de moins. Mais en quoi est-ce un problème? La plupart des développeurs ne se posent même pas la question de savoir si il vaut mieux un int ou un short et utilisent le int par habitude. Donc visiblement, 16 bits de différence, ça ne change rien pour eux.

Je fais du java depuis plus de 10 ans, et jamais l'absence de nombre signé ne m'a posé problème.

Ici on parle de la conversion d'un code C. Le problème ne réside donc pas dans la présence ou non d'arithmétique non signée, mais dans l'idée qu'on puisse convertir un code d'un languages à un autre en changeant juste les définitions des variables.

[tchize_]

au fait, il y a un exception. Il existe un type non signé sur 16 bit en java: char

[thelvin]

Évidemment, pourquoi avoir un système qui permettrait de faire simple, quand on en a un qui oblige à faire compliqué.

Oui enfin, long est un système très simple, faudrait voir à pas l'oublier.

[mohamine1989]

long est un système très simple

Effectivement, sur 64bit en plus, très utile
C'est juste pour dire qu'il vaut mieux éviter le calcul en double précision si possible bien sur pour éviter une baisse de performances
Bon courage