[algorythmie] remplir un tableau dont on ne connait pas encore la taille

Citation:

---

Envoyé par adiGuba

Mais il est impossible de connaitre le type paramétré puisqu'il est perdu : donc c'est impossible.


Non : tu connais juste T mais pas son type exact. Or c'est ce dont tu as besoin pour créer un tableau.

Le code suivant ne compile pas parce qu'il est impossible de connaitre le type exacte de T à l'exécution :

Code:

---

1 2 3 4 5

class Test<T> { public T[] toArray() { return new T[5]; } }

---

a++

---

C'est vrai, mais ils auraient pu renvoyer un tableau de type apparent T[]... (T[]) tab;

On est sûr que tous les éléments sont de type T donc c pas génant...

Citation:

---

Envoyé par ®om

On est sûr que tous les éléments sont de type T donc c pas génant...

---

Sauf que comme on ne connait pas le type exact de T, on ne peut pas instancier de tableau de T et l'instruction suivante provoque une erreur :

Code:

---

return new T[5];

---

a++

Citation:

---

Envoyé par adiGuba

Sauf que comme on ne connait pas le type exact de T, on ne peut pas instancier de tableau de T et l'instruction suivante provoque une erreur :

Code:

---

return new T[5];

---

a++

---

Bah, oui, mais cette instruction, non:

Code:

---

T[] tab = (T[]) new Object[5];

---

Citation:

---

Envoyé par ®om

Bah, oui, mais cette instruction, non:

Code:

---

T[] tab = (T[]) new Object[5];

---

---

Non car le type des tableaux est vérifié à l'exécution. Et qu'un Object[] ne peut pas être casté en String[] par exemple...

Si tu prend le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Test<T> { public T[] toArray() { return (T[]) new Object[5]; }   public static void main(String[] args) { Test<String> test = new Test<String>();   String[] strings = test.toArray(); } }

---

Tu verras que tu obtiens une ClassCastException à l'execution...

Note toutefois que le compilateur te préviens en générant un warning sur l'instruction suivante :

Code:

---

(T[]) new Object[5]

---

La seule solution pour renvoyer un tableau du bon type est d'avoir un objet Class du bon type, par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Test<T> { private final Class<T> type;   public Test(Class<T> type) { assert type!=null; this.type = type; }   @SuppressWarnings("unchecked") public T[] toArray() { return (T[]) Array.newInstance(this.type, 5); }   public static void main(String[] args) { Test<String> test = new Test<String>(String.class);   String[] strings = test.toArray(); } }

---

a++

Ah ouais, étonnant, car ce code:

Code:

---

1 2	Object[] o = new Object[5]; String[] s = (String[]) o;

---

pourrait générer un warning à la compilation... Pourtant, ça n'est qu'à l'exécution que ça plante...

Citation:

---

Envoyé par ®om

Ah ouais, étonnant, car ce code:

Code:

---

1 2	Object[] o = new Object[5]; String[] s = (String[]) o;

---

pourrait générer un warning à la compilation... Pourtant, ça n'est qu'à l'exécution que ça plante...

---

C'est "normal" : les tableaux possèdent une notion d'héritage (String[] hérite de Object[]) qui fait que la vérification ne peut être effectué qu'à l'exécution.

Il n'y a pas de warning car l'utilisation des casts est par nature non-sécurisé et peut potentiellement provoquer une ClassCastException à l'exécution. Ton exemple est toutefois un cas simple qu'un outil de vérification de code pourrait détecter... mais ce n'est pas toujours aussi simple, par exemple :

Code:

---

1 2	Object[] o = uneMethodeQuiRenvoitUnTableau(); String[] s = (String[]) o;

---

Car dans ce cas on ne peut pas prédir d'éventuelle erreur cast sans analyser le code de la méthode, car si le vrai type du tableau est String[] cela fonctionnera. Le code suivant ne pose pas de problème :

Code:

---

1 2	Object[] o = new String[5]; String[] s = (String[]) o;

---

A l'inverse les Generics sont sécurisé et provoqueront plusieurs warnings/erreurs pour éviter ce type de problème : un code qui utilise les Generics ne devrait pas provoquer de ClassCastException s'il compile sans erreur ni warning...

Par contre un warning sur l'utilisation des Generics peut impliquer l'apparition de ClassCastException plus loin dans le code !!!!

D'ailleur les Generics apportent tellement de nouveaux warnings qu'il est parfois impossible de compiler un code 100% sécurisé sans warning si on n'utilise pas l'annotation @SuppressWarning...

a++

Citation:

---

Envoyé par adiGuba

D'ailleur les Generics apportent tellement de nouveaux warnings qu'il est parfois impossible de compiler un code 100% sécurisé sans warning si on n'utilise pas l'annotation @SuppressWarning...

---

Surtout si on mélange Generics / non Generics (par exemple quand on fait du Swing qui n'est pas générique...)

Citation:

---

Envoyé par ®om

Surtout si on mélange Generics / non Generics (par exemple quand on fait du Swing qui n'est pas générique...)

---

En effet... mais il faut quand même rester prudent, bien comprendre la raison du warning, et limiter au minimum sa portée avant d'utiliser l'annotation @SuppressWarning...

a++