concatenation generique - Page 1

pourquoi je peux pas? (java 6)

import java.lang.reflect.Array;
public class Utils {
    public static <T> T[] concat(T[] a, T[] b) {
        T[] r=  (T[]) Array.newInstance(T.class, a.length+b.length);
        System.arraycopy(a, 0, r, 0, a.length);
        System.arraycopy(b, 0, r, a.length, b.length);
        return r;        
    }
}

ça me dit: cannot select from a type variable

apparemment faut faire un truc comme ça (source de la jvm):

public static <T,U> T[] copyOf(U[] original, int newLength, Class<? extends T[]> newType) {
        T[] copy = ((Object)newType == (Object)Object[].class)
            ? (T[]) new Object[newLength]
            : (T[]) Array.newInstance(newType.getComponentType(), newLength);
        System.arraycopy(original, 0, copy, 0,
                         Math.min(original.length, newLength));
        return copy;
    }

mais je pige pas trop

edit: ah, ok , il faut faire :

public static <T> T[] concat(T[] a, T[] b) {
        T[] r=  (T[]) Array.newInstance(a.getClass(), a.length+b.length);
        System.arraycopy(a, 0, r, 0, a.length);
        System.arraycopy(b, 0, r, a.length, b.length);
        return r;
    }

je le laisse pour google.

edit2 : ah ben merde ça marche pas avec les types natifs byte, int, etc

Tiens, je décide de passer pour un gland mais d'apprendre quelque chose... c'est quoi cette syntaxe <T> T[] concat(T[] a, T[] b), avec les chevrons (et ce qui suit) ? J'ai jamais vu ça dans mes cours de Java (bon, ok, ça date carrément )...

<T> permet de dire que tu vas utiliser un type générique dans cette méthode. après je l'utilise, les crochets c'est juste un tableau dont les éléments sont de type T.

Nil > http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html
et plus particulièrement http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html


squalyl > pourquoi tu utilises des tableaux et pas des List<> ou un truc dans le genre ? J'avoue que j'ai du mal à voir l'intérêt de se compliquer la vie à utiliser ça. Pour moi les tableaux sont aux conteneurs ce que les char* sont aux std::string. En gros, j'utilise des List<T>, et si j'ai besoin d'un tableau pour une compatibilité avec une API particulière, je convertis au moment opportun pour pas trop influer sur les performances.
Ce que je veux dire, c'est que c'est tellement simple de faire un addAll sur une List<> pour concaténer que je trouve dommage de perdre son temps à utiliser des tableaux

certes.

mais bon c'était a moitié pour le phun.

Ah OK, si c'est pour le phun, ça va .
En fait je demandais ça parce que je vois des gens (genre, au hasard, mon chef ) qui utilisent des tableaux partout, et ça m'énerve

[google]email chef Pen^2[/google]

j'allais faire un !call

J'ai pas peur, j'assume #YN#

Pen^2 (./9) :

J'ai pas peur, j'assume #YN#

Han l'édit furtif

Pen^2 (./6) :
En fait je demandais ça parce que je vois des gens (genre, au hasard, mon chef ) qui utilisent des tableaux partout, et ça m'énerve :

Je ne vois pas le problème. Si la taille est fixe, l'utilisation d'un tableau me parait tout a fait correcte et même préférable.

squalyl (./1) :
edit2 : ah ben merde ça marche pas avec les types natifs byte, int, etc

En effet les générics ne couvrent pas les type natifs. Ils sont juste convertis en leurs classes équivalentes grâce à l'autoboxing.

oui, ben justement, ça autoboxingue pas grand chose dans ce cas.

Uther > bah oui, mais c'est pas forcément évident de savoir à l'avance ce que l'utilisateur va faire de cet ensemble.
Genre une méthode retourne un ensemble de trucs, ensuite l'utilisateur peut bien en faire ce qu'il veut : c'est pas pratique si c'est un tableau
Même en interne, rien ne dit que les besoins ne vont pas évoluer, autant être souple dès le départ. C'est pas ça qui va avoir un impact significatif sur les performances... (même dans du code critique je serais étonné que ça ait une influence importante)

Pen^2 (./14) :
bah oui, mais c'est pas forcément évident de savoir à l'avance ce que l'utilisateur va faire de cet ensemble.

Un intérêt est justement d'éviter qu'un utilisateur en face n'importe quoi. et puis si il en a vraiment besoin, on peux toujours convertir un array en List et vice versa.

Pen^2 (./14) :
C'est pas ça qui va avoir un impact significatif sur les performances... (même dans du code critique je serais étonné que ça ait une influence importante)

Ca a un impact non négligeable sur du code critique en vitesse même si c'est vrai que dans la grande majorité des cas ce n'est pas le cas.

Après, si on a un doute, c'est sur qu'il vaut mieux recourir au Listes qu'aux tableaux, mais je ne pense pas que les tableaux soient absolument a bannir.

Un tableau d'objets en Java est forcément un tableau de pointeurs, c'est très efficace comme structure de données jusqu'à un n plutôt élevé. Un pointeur prend maximum 8 octets sur les machines actuelles, copier/déplacer 8n octets n'est pas catastrophique tant que n reste relativement petit.

Qt 4 est passé de la liste chaînée (Qt 3) au tableau de pointeurs pour les listes par défaut, il faut maintenant demander explicitement une QLinkedList si on veut une liste chaînée. (Mais il faut quand-même préciser qu'une QList a aussi de l'espace réservé devant le tableau pour permettre une insertion au début plus efficace.)

Kevin Kofler (./17) :
Un tableau d'objets en Java est forcément un tableau de pointeurs

faux. les types boolean,byte,char,short,int,float,long,double sont stockés directement dans un tableau.

J'ai bien dit "d'objets", pas de types primitifs.

anéfé, ok.