Discussion :

[TanEk]

Non, toujours non, le C++ a un typage plus fort que le java.
Que mets tu dans un Array en java ? et qu'est ce que tu obtiens lorsque tu lis un Array ? ben ouais, un Object, que tu dois recaster dans ta classe favorite. tu perds le typage.
C++ est tres intransigeant au niveau du typage, grace a ses containers qui ne perdent pas le typage

Heu... depuis la version 5 de Java il existe ce qu'on appelle les template (edit : generics ! pas template ! voir message de Millie plus loin) qui permettent de faire genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
ArrayList<Texture> textures = new ArrayList<>();
Texture maTexture = new Texture();
textures.add(maTexture);
Texture autre = textures.get(0);

C'est pas exactement des template à la C++ qui génère du code pour chaque type mais ça permet d'avoir un typage sûr et de pas avoir à faire des cast à tout bout de champ.

[Alp]

Ce que je trouve bizarre avec le fait que cela ait été ajouté à Java, c'est que ça va à l'encontre de la mentalité "tout dérive de Object" qui permettait déjà de stocker, quitte à faire des casts. Peut-être est-ce le fait d'avoir vu que ça marchait plutôt bien côté C++ et que d'ailleurs ça se développe encore, qui les a faits changer d'avis.

[millie]

c'est que ça va à l'encontre de la mentalité "tout dérive de Object" qui permettait déjà de stocker, quitte à faire des casts.

Pourquoi ça va à l'encontre de ce principe ? Tout les objets dérivent toujours de Object.

depuis la version 5 de Java il existe ce qu'on appelle les template

En fait, ça s'appelle des generics et ca apportent moins de fonctionnalités que les template C++.

[Alp]

Bah ça fait redondance. Le seul truc "ajouté" c'est de ne pouvoir stocker _que_ un certain type et ses enfants. Ils n'ont ajouté qu'un tout petit morceau de ce qu'il est possible de faire avec les templates

[ac_wingless]

Ils n'ont ajouté qu'un tout petit morceau de ce qu'il est possible de faire avec les templates

Il faut reconnaitre que les templates se sont révélés beaucoup plus puissants que prévu, à la grande surprise des plus grands spécialistes du langage.

generic programming is the area where use of C++ has progressed the furthest relative to the support offered by the language

My understanding of templates was still at the container-of-T stage, while Barton, Nackman, Stepanov and others were demonstrating that such uses barely scratched the surface of what templates could do.

On peut dire que ce sont les travaux de d'une poignée d'innovateurs (il faut aussi citer Alexandrescu, Abrahams et Gurtovoy) qui ont popularisé des techniques insoupçonnées à l'époque de la définition des templates, où la seule ambition était sans doute originellement de simplement mettre en place ce qu'on trouve en Java et C#.

Ce qui est vraiment intéressant, c'est que ces travaux ont tellement distendu le C++, à sa limite de lisibilité (voire au delà... ), que le comité C++ a décidé de fournir, au travers des concepts, une infrastructure pour formaliser et supporter décemment ces applications innovantes (par rapport aux utilisations Java et C#).

[Alp]

Il n'y a pas que les concepts. Une partie non négligeable des nouveautés concernent les templates. Sans parler de la réécriture de la bibliothèque standard pour tenir compte des concepts, variadic templates, ...

Enfin, on s'écarte du sujet. Tout ça pour dire que je ne comprends pas pourquoi ils n'ont pris qu'un tout petit morceau Une deadline à respecter ?

[TanEk]

Ce que je trouve bizarre avec le fait que cela ait été ajouté à Java, c'est que ça va à l'encontre de la mentalité "tout dérive de Object" qui permettait déjà de stocker.

Ce n'est pas parce que cela permettait que c'était adapté. Et tout ne dérive pas de Object, en l'occurrence tous les types primitifs (float, bool, etc.) ne dérivent pas de Object. Les légendes urbaines... D'ailleurs on ne peut pas faire de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
ArrayList<float> array;
// Par contre on peut faire 
ArrayList<Float> array; // (Float dérive bien de Object...)

Ce qui est assez contraignant je vous l'accorde, mais il existe des biblio qui ont été crée permettant d'avoir des conteneurs de types primitifs (qui pour gnutrove est basé sur une génération de code java pour chaque type à la C++ like).

[Alp]

Pour float, bool & co, je sais très bien. M'enfin la proportion est assez faible hein...

Mais je m'interroge sur le fait qu'il n'y ait pas eu plus de possibilités des templates du C++ qui aient été intégrées à Java.

[mavina]

Ce n'est pas parce que cela permettait que c'était adapté. Et tout ne dérive pas de Object, en l'occurrence tous les types primitifs (float, bool, etc.) ne dérivent pas de Object. Les légendes urbaines... D'ailleurs on ne peut pas faire de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
ArrayList<float> array;
// Par contre on peut faire 
ArrayList<Float> array; // (Float dérive bien de Object...)

Ce qui est assez contraignant je vous l'accorde, mais il existe des biblio qui ont été crée permettant d'avoir des conteneurs de types primitifs (qui pour gnutrove est basé sur une génération de code java pour chaque type à la C++ like).

Le truc c'est que derrière les types primitif ya des classes qui existent et qui sont utilisés par la VM pour représenter les types primitifs, donc on peut dire que les types primitifs dérivent au final de object, même si ca ne se voit pas (tente un System.out.println(int.class) pour t'en convaincre, ainsi que ce lien de la javadoc)

F.

[millie]

Mais je m'interroge sur le fait qu'il n'y ait pas eu plus de possibilités des templates du C++ qui aient été intégrées à Java.

Mais les generics ne sont pas des templates. Ils ne servent qu'à vérifier le code à la compilation (et éviter des erreurs de cast qui auraient pu se produire à l'exécution). Et contrairement à du C++, une classe generics en Java est compilée qu'une seule fois à la compilation, il n'y a pas de copie de code et il n'est pas nécessaire de disposer des sources lorsque l'on souhaite l'utiliser.

Les generics sont également utiles pour l'utilisation de la boucle for étendu (for(MonObject o : maliste)) et pour l'utilisation de l'autoboxing (afin que l'utilisation d'objets generics avec des types primitifs sont plus simples)

[deadalnix]

C'est pas exactement des template à la C++ qui génère du code pour chaque type mais ça permet d'avoir un typage sûr et de pas avoir à faire des cast à tout bout de champ.

Sauf que quand on décompile, on obtient la même chose qu'avant avec les cast et tout. C'est juste un artifice mais il y a le même chose qu'avant derrière.

[Alp]

Sauf que quand on décompile, on obtient la même chose qu'avant avec les cast et tout. C'est juste un artifice mais il y a le même chose qu'avant derrière.

Autrement dit, ça facilite simplement la vie des programmeurs Java --- ce qui est loin d'être une mauvaise chose en soi hein

[TanEk]

Le truc c'est que derrière les types primitif ya des classes qui existent et qui sont utilisés par la VM pour représenter les types primitifs, donc on peut dire que les types primitifs dérivent au final de object, même si ca ne se voit pas (tente un System.out.println(int.class) pour t'en convaincre, ainsi que ce lien de la javadoc)

F.

Float ce n'est pas float et ce n'est pas utilisé pour être représenté par la VM ou ce n'est pas derrière, c'est à côté si tu veux que je garde ta métaphore . Donc non on ne peut pas dire que les types primitifs dérivent de object, tente un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
int a;
a.class; // Ca marche pas
a.toString(); // Ca marche pas
a.quelque_chose(; // Ca marche pas
class A extends int // Ca marche pas !
{
};

Les types primitifs sont exactement la même chose (à quelques choses prêts peut-être pour les float... pour des soucis de portabilité et encore je ne m'avancerai pas là-dessus) que les types primitifs C++, que ce soit au niveau mémoire, etc. Après il existe des conversions implicites vers leur équivalent objet fait par autoboxing, etc. lorsque l'on a besoin d'opérations de type objet, mais ce ne sont que des facilités apportées par le langage.

float est un type primitif.
Float est une classe.

Si l'on fait pas cette distinction on en arrive à tout est objet en Java et bla et bla.

C'est pas exactement des template à la C++ qui génère du code pour chaque type mais ça permet d'avoir un typage sûr et de pas avoir à faire des cast à tout bout de champ.

Sauf que quand on décompile, on obtient la même chose qu'avant avec les cast et tout. C'est juste un artifice mais il y a le même chose qu'avant derrière.

Es-tu sûr de cela ? Est-ce que c'est vrai pour la dernière JVM ? Le but justement des generics est de vérifier le typage à la compilation et donc de ne pas avoir à faire de conversion au runtime...

[mavina]

Mais c'est incroyable de contredire les autres avec des âneries pareilles sans vérifier un minimum ce que l'on dit. Float ce n'est pas float et ce n'est pas utilisé pour être représenté par la VM ou ce n'est pas derrière, c'est à côté si tu veux que je garde ta métaphore . Donc non on ne peut pas dire que les types primitifs dérivent de object, tente un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
int a;
a.class; // Ca marche pas
a.toString(); // Ca marche pas
a.quelque_chose(; // Ca marche pas
class A extends int // Ca marche pas !
{
};

Les types primitifs sont exactement la même chose (à quelques choses prêts peut-être pour les float... pour des soucis de portabilité et encore je ne m'avancerai pas là-dessus) que les types primitifs C++, que ce soit au niveau mémoire, etc. Après il existe des conversions implicites vers leur équivalent objet fait par autoboxing, etc. lorsque l'on a besoin d'opérations de type objet, mais ce ne sont que des facilités apportées par le langage.

float est un type primitif.
Float est une classe.

Si l'on fait pas cette distinction on en arrive à tout est objet en Java et bla et bla.

There are nine predefined Class objects to represent the eight primitive types and void. These are created by the Java Virtual Machine, and have the same names as the primitive types that they represent, namely boolean, byte, char, short, int, long, float, and double.

tiré de http://javasearch.developpez.com/j2s...#isPrimitive()

C'est pas moi qui l'dis, c'est la javadoc, j'ai bien dit que ce sont des choses gérées par la VM, pas par nous ...
Ce ne sont pas des anneries, les types primitifs sont bien représentés par des objets par la VM, et comme je l'ai dit, int.class, ou float.class par exemple te renvoie bien quelque chose...

Pour finir, si tu vas dans Boolean par exemple, tu remarques une variable statique TYPE dont la définition est :

public static final Class TYPE
The Class object representing the primitive type boolean.

http://javasearch.developpez.com/j2s...lean.html#TYPE
C'est pareil pour toutes les classes enveloppées. La encore c'est pas moi qui l'dis, c'est la javadoc.

Il y en a même une pour void : http://javasearch.developpez.com/j2s...Void.html#TYPE...


Fred

[loka]

Après avoir lu ta citation mavina, je pense que c'est TanEk qui a raison, c'est à dire que Oui il existe les class Float, Boolean, etc.. qui représentent les types primitifs et ont leur nom (avec majuscule).

Tu n'as absolument rien démontré, au contraire tu as argumenté ce que disait TanEk ou alors je sais plus lire l'anglais

[mavina]

voici un petit bout de code pour confirmer mes propos :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public class Test
{
	public static void main(String[] args)
	{
		System.out.println(Boolean.class.equals(Boolean.TYPE));
		System.out.println(Boolean.class.isPrimitive());
		System.out.println(Boolean.TYPE.isPrimitive());
	}
}

Qui renvoie bien évidemment
false
false
true
...
Alors que représente Boolean.TYPE si ca ne représente pas la classe Boolean ?
Il aurait été étonnant qu'il y ai une redondance d'information entre Boolean.class et Boolean.TYPE non ?
TYPE c'est tout simplement la classe représentant les types primitifs, ce qui se voit losqu'on appelle isPrimitive() dessus... La classe de int, n'en déplaise à certains, c'est int, tout simplement, et un System.out.println(int.class) affichera bien "int"... Tout ceci n'est pas géré par l'utilisateur.

Je vois pas comment je peux prouver quelque chose qui est marqué noir sur blanc sur la Javadoc...

F.

[loka]

C'est normal que ça marche, tu utilises Boolean et non boolean... c'est ce que TanEk te dis depuis le début, que Boolean != boolean

Edit : ce que ton programme montre c'est que le type boolean est bien un type primitif mais pas que boolean est une classe, essayes de faire des tests en partant de boolean et non de Boolean, tu prends le problème à l'envers et ne démontres rien

[mavina]

Derniere réponse HS pour répondre à loka :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
		System.out.println(Boolean.TYPE.equals(boolean.class));
		System.out.println(boolean.class.isPrimitive());

Voilà, c'est fait avec boolean.class... Et bien évidemment, true true..

F.

[TanEk]

Allez je suis gentil :

http://www.particle.kth.se/~lindsey/.../wrappers.html
http://www.glenmccl.com/tip_016.htm

Il ne faut pas confondre un objet (en l'occurence Integer.TYPE ou int.class qui sont des références vers le même objet) qui représente un type et le type lui-même (en l'occurence int tout cours... qui n'est pas un objet mais un type primitif).

objet != type primitif != classe en java...
int.class != int != Integer