Discussion :

[Furikawari]

Ah ?

Encore une fois tu te plantes, ce n'est pas parce que la syntaxe est similaire que c'est la même chose, loin de là...

C'est quand même pas bien dur de distinguer syntaxe et fonctionnalité (à condition de savoir de quoi on parle).

Quand on veut comparer deux langages, encore faut-il les connaître. Il ne suffit pas d'être très bon dans l'un et avoir des a priori sur l'autre...

[jabbounet]

Oui les enums sont apparus plus tardivement, mais le point important est que ce sont de vrais objets, pas juste un typedef sur un type.

et ça apporte concretement quelque chose que ce soit un objet?

[gorgonite]

Tant qu'on est sur les Generics, les travaux sur sa JSRs ont commencé en 1999 (source : JSR 14), même si cela n'a été finalisé que fin 2004.
On ne peut donc pas vraiment parler d'une inspiration de C#

mais les premières annonces sur C# sont sorties en Janvier 1999 justement... et pas celles de Microsoft, mais de son créateur qui avait déjà C# 2.0 en tête à l'époque

Ah ?

ben oui... les generics sont "plus intégrés" dans le langage, alors que les templates sont en fait un méta-langage au dessus de C++, et les implantations du moteur de templates ne sont pas toujours équivalentes (cf VSC++ 2008 et g++ 4, on remarque qu'on doit mettre plus de typename dans l'utilisation de type paramétrisé par un argument du template)


c'est d'ailleurs pour cela qu'il a été "si facile" à C# d'introduire la contra-variance, ce qui à ma connaissance n'est pas du tout possible en C++ (ni en Java bien sûr puisqu'ils sont toujours 10 ans de retard sur tout le monde )

[gorgonite]

et ça apporte concretement quelque chose que ce soit un objet?

Java étant tout objet, ça doit aider un peu (au lieu d'avoir des boxing bizarres comme les types somme de F# quand on les importe en C# )

en effet quand tu feras de la vérification de type à la compilation, tu auras un objet et donc un type, au lieu d'un alias d'entier... et tu peux ajouter des méthodes qui feront des traitements sur ce type


<mode troll>
bon un peu de reflexion permet de faire des choses similaires, et infiniment plus performantes en C++ (comme souvent ), mais ce ne sera pas aussi simple d'accès pour les newbies... qui constituent quand même 60% du cheptel de développeurs Java (dont la plupart se contente de switcher entre les frameworks d'une mode à l'autre, mais ne progresse pas énormement conceptuellement... là où c'est impératif en C++, sinon autant repasser sur Java ou C#)
</mode troll>

[jabbounet]

et pour gérer des entiers non signés il y'a une solution simple dans la roadmap de java?

[gorgonite]

et pour gérer des entiers non signés il y'a une solution simple dans la roadmap de java?

une surcharge de Integer

[Furikawari]

et pour gérer des entiers non signés il y'a une solution simple dans la roadmap de java?

??? Les entiers sont non signés en java. Quel est ton problème ?

[Furikawari]

Java étant tout objet, ça doit aider un peu (au lieu d'avoir des boxing bizarres comme les types somme de F# quand on les importe en C# )

en effet quand tu feras de la vérification de type à la compilation, tu auras un objet et donc un type, au lieu d'un alias d'entier... et tu peux ajouter des méthodes qui feront des traitements sur ce type
bon un peu de reflexion permet de faire des choses similaires, et infiniment plus performantes en C++ (comme souvent ), mais ce ne sera pas aussi simple d'accès pour les newbies... qui constituent quand même 60% du cheptel de développeurs Java (dont la plupart se contente de switcher entre les frameworks d'une mode à l'autre, mais ne progresse pas énormement conceptuellement... là où c'est impératif en C++, sinon autant repasser sur Java ou C#)

Ca sent bon la mauvaise foi et l'arrogance. Bizarre que quelqu'un comme toi en vienne à rabaisser l'utilisation d'objets pour les enums à du sucre pour newbies...

[jabbounet]

??? Les entiers sont non signés en java. Quel est ton problème ?

?????

je ne crois pas, je ne fais pas de java mais je sais qu'avec le jdk que les entier sont tous signés


voici quelques exemple d'entier 32bits non signé

les entier 32 bits non signés vont normalement de
0 à 4 294 967 295
arrive tu a mettre 4 294 967 295 sur un int?

[gorgonite]

Ca sent bon la mauvaise foi et l'arrogance. Bizarre que quelqu'un comme toi en vienne à rabaisser l'utilisation d'objets pour les enums à du sucre pour newbies...

ce n'est pas du tout ce que j'ai voulu dire... va falloir que je sépare mieux mes notes d'humour trollesques, du reste du propos


pour infos, je pense que dans chacune de mes interventions qui s'y prêtent, je me bats pour signaler quand le système de type d'un langage apporte un concept intéressant et suffisamment sûr pour faire de manière concise, lisible, et vérifiable à la compilation certaines choses que d'autres finissent par faire en 200 lignes imbitables vérifiées à la main parce qu'on peut pas faire autrement, ou via une surcharge énorme sous forme d'héritage, qui rendra l'ajout de "fonctions traversantes" encore plus difficiles (que vous les appeliez visiteur, container::iter, ou autre). et j'essaie de le faire sans tomber dans la dérive du système de type hyper-rigide qui demande une thèse pour faire un bubble-sort (style Coq , qui au passage est très sympa également )

[gorgonite]

arrive tu a mettre 4 294 967 295 sur un int?

prends un long
http://java.sun.com/javase/6/docs/ap...ng/Number.html

[jabbounet]

prends un long

pourquoi ça tiens sur 32 bits normalement.


et si je dois manipuler des unsigned long je fais comment?
entre 0 et 2^64 -1

toujours avec le jdk de base sinon ce ne serais pas drole.

[gorgonite]

pourquoi ça tiens sur 32 bits normalement.


et si je dois manipuler des unsigned long je fais comment?
entre 0 et 2^64 -1

toujours avec le jdk de base sinon ce ne serais pas drole.

BigInteger pour les entiers de taille arbitraire... qui finissent toujours par être obligatoires quand on a réellement besoin de grands entiers (et dans tous les langages )
http://java.sun.com/javase/6/docs/ap...igInteger.html

[Furikawari]

?????

je ne crois pas, je ne fais pas de java mais je sais qu'avec le jdk que les entier sont tous signés


voici quelques exemple d'entier 32bits non signé

les entier 32 bits non signés vont normalement de
0 à 4 294 967 295
arrive tu a mettre 4 294 967 295 sur un int?

Effectivement avec la version française j'ai mélangé les signés vs non signés.

Effectivement tout est signé en Java, mais Gorgonite t'a donné des pistes.

[jabbounet]

BigInteger pour les entiers de taille arbitraire... qui finissent toujours par être obligatoires quand on a réellement besoin de grands entiers (et dans tous les langages )
http://java.sun.com/javase/6/docs/ap...igInteger.html

mais c'est lent non? ah oui c'est le principe de java.
et je ne vois pas l'intérêt de gaspiller deux fois la taille d'un nombre pour pouvoir le gérer.


personnellement, j'en ai besoin car je travaille dans le développement de protocole et les RFC sur lesquels je me base me disent que c'est obligatoire de les supporter.

[_skip]

Je me permet juste de citer cet article pour signaler que "java" et "bonnes performances" peuvent être utilisés dans la même phrase lorsqu'il s'agit de calcul :

Scientific and technical computing, as, for example, carried out at CERN, is characterized by demanding problem sizes and a need for high performance at reasonably small memory footprint. There is a perception by many that the Java language is unsuited for such work. However, recent trends in its evolution suggest that it may soon be a major player in performance sensitive scientific and technical computing. For example, IBM Watson's Ninja project showed that Java can indeed perform BLAS matrix computations up to 90% as fast as optimized Fortran. The Java Grande Forum Numerics Working Group provides a focal point for information on numerical computing in Java. With the performance gap steadily closing, Java has recently found increased adoption in the field. The reasons include ease of use, cross-platform nature, built-in support for multi-threading, network friendly APIs and a healthy pool of available developers. Still, these efforts are to a significant degree hindered by the lack of foundation toolkits broadly available and conveniently accessible in C and Fortran.

The latest stable Colt release breaks the 1.9 Gflop/s barrier on JDK ibm-1.4.1, RedHat 9.0, 2x IntelXeon@2.8 GHz.

Ca provient du message de bienvenue du site de Colt, une puissante librairie de calcul scientifique en java.

[gorgonite]

Je me permet juste de citer cet article pour signaler que "java" et "bonnes performances" peuvent être utilisés dans la même phrase lorsqu'il s'agit de calcul :

+1 d'ailleurs tous ceux ayant déjà touché à une JVM, et étudié les optimisations qu'on peut y faire ont remarqué que coder "très bas niveau" (du C encapsulé ), permet une exécution très rapide des blocs de code dès la troisième itération

[jabbounet]

je ne doute pas que l'on puisse faire des programmes performant en java, mais je ne pense pas que gérer des entiers 32 avec des types qui font 64 bits aille dans ce sens.

[gorgonite]

mais c'est lent non? ah oui c'est le principe de java.
et je ne vois pas l'intérêt de gaspiller deux fois la taille d'un nombre pour pouvoir le gérer.

disons que chaque langage a ses limites sur la taille maximale des entiers qu'il gère... on ne peut pas créer N types pour faire beau parce qu'un autre a un type qui prend 2 bits de plus que nous en représentation native

l'utilisation d'entier à précision arbitraire est une solution envisagée dans TOUS les langages (même si certaines semblent switcher de manière transparente de l'int natif au BigInt), et après un petit coup d'optimisation, si le code est bien fait... on se retrouve souvent avec des performances correctes (et les 2 premiers tours d'une boucle sont souvent insignifiants si on joue avec de grosses quantités de données)

[_skip]

je ne doute pas que l'on puisse faire des programmes performant en java, mais je ne pense pas que gérer des entiers 32 avec des types qui font 64 bits aille dans ce sens.

Pour ce cas précis non... C'est une limitation en effet mais ensuite il faut voir si c'est bloquant.
Si tu as juste une dizaines de valeurs a gérer, tu utilises un long (au sens java) et c'est un compromis acceptable.

Maintenant si tu as un très grand nombre de ces valeurs, le problème va pas être le même. Personnellement je n'ai jamais été confronté à des situations (bien que j'en conçoive l'existence) dans lesquelles l'absence du unsigned int était véritablement un grand manque puisqu'une fois excédé le cap du 31e bit, la première multiplication risquait l'overflow.
Face à ce risque, l'usage d'un entier de 64bits devenait préférable.