est-il possible de faire tab1=tab2 en java?
sinon y a-t-il une méthode de recopie d'objet?
merci

System.arrayCopy(), ou un truc du genre (sous reserve de memoire foireuse)

ouia mais arrayCopy c pas kan on a déclaré un array  justemetn?
moi c just un int[] tab;

Un int[] EST un Array, c'est juste un raccourci d'écriture.

c'est bien System.arraycopy qu'il te faut
 

 
 
je te rappelle qu'un tableau est un objet en java

Ouai merci bien tout le monde

juste une info : le System.arrayCopy c'est juste une optimization d'une bête boucle for de copie...

 
...optimisée comment d'ailleurs ?

Ha, ok, c'est un appelle JNI

c'est un appel système ... les proc sont optimisés pour la copie binaire de "tranches" de mémoire

Je me permets de upper comme un malpropre. Par curiosité, j'ai fais quelques tests basiques, et j'ai constaté que System.arraycopy() était deux à trois fois plus lent qu'une bête boucle for.
C'est normal ? c'est mes tests qui sont foireux ? c'est quoi ?

tableau trop court, le coût de démarrer et de terminer l'appel JNI est plus grand que le gain durant la copie.

C'est pas vraiment qu'ils sont optimisés dans ce but spécifique,  
mais que quand tu fais une boucle, ça fait chaque fois des branches en plus, ce qui rajoute des instructions.
Je suppose que dans l'appel système, il va n'y avoir que le bon nombre d'instructions effectués directement à la suite l'une de l'autre.  
Sans compter que les prévisions des prefetcher sont sans doute moins efficaces avec ces branches dans la boucle.

Je pensais bien à un truc de ce genre, ou à une optimisation de ma boucle par le compilo vu je ne faisais que recopier un tableau vers l'autre et vice-versa.
Donc d'après toi, à partir de quelle taille de tableau cette methode devient intéressante ? Le cout de l'appel JNI est-il le même selon la plateforme ?
Et juste encore un petit truc : j'ai fais mes tests avec des tableau d'Integer et avec des tableaux d'int. J'aurais pensé que si la copie de références serait plus rapide, mais en fait c'est la copie d'entiers qui va plus vite ; une explication ?

suis pas sur à 100%, mais je pense que c'est pas seulement la reference qui est copiée mais l'objet lui meme
 
()

la taille dépends de 15000 paramètres, donc c'est l'âge du capitaine. Mais en gros, si tu sais que tu va dépasser le méga, il va falloir songer à optimiser.
 
Concernant la copie de références ou d'entiers, les 2 font la même taille (et la bonne taille pour être copiés) donc je ne m'explique la différence que par la vérification du type de la référence avant de la stocker.
En effet, dynamiquenet, java est safe, donc il va lever un ArrayStoreException (j'ai la doc sur mon disque donc je file pas l'url) si il y a incompatibilité de type entre la référence et la destination. Cette vérification nécessite de déréférencer, d'aller chercher l'entête de l'objet et de remonter son graphe d'héritage jusqu'à avoir la réponse.
 
Sur des tableaux de type primitif, on vérifie le type des tableaux eux-même une fois pour toutes avant, soit ils sont identiques et on copie direct sans se faire chier, soit il sont compatibles et on choisi la politique de conversion une fois pour toutes et elle sera la même pour toutes les cases, soit c'est incompatible et on plante un pain direct.
 
pour répondre à  -- : non, java ne copie pas les objets de sa propre initiative, c'est bien la référence qui est copiée (sémantiquement du moins, s'ils se mettent à l'arthimétique taggée c'est leur pb, pas le nôtre).
 
edit : typo, cleanup
 
edit2 : c'est cacheable la vérification de types, mais je sais pas si dans la pratique c'est caché.

ok
(je me disait qu'il faisait pê un clone() )
 
( arthimétique )

Nan faire un clone() est lourd de conséquence d'un point de vue sémantique, ça serait probalement marqué dans le nom de la fonction et obligatoirement marqué dans la doc. En plus statiquement tout le monde doit être Cloneable.
 
l'arithmétique taggée c'est encoder les entiers (les nombres primitifs en général) sur moins de 32 bits (typiquement 31) et réserver un bit pour dire si c'est un entier ou un pointeur. Sémantiquement ça se comporte comme des objets immuables.
Mais en java ça existe pas car les 32 bits sont marqués dans la norme donc ils sont dans l'implémentation. Mais par exemple O'Caml, smalltalk, Lisp et ses amis (bien que ce soit encore plus invisible car les grands entier sont présents en natif dedans) le font.
C'est super-pratique d'un point de vue sémantique et technique, d'un autre côté, ceux qui utilisent tous les 32 bits peuvent utiliser l'ancienne méthode, mais souvent à un coût supérieur à celui de java (car le principe est de limitier au max leur utilisation, donc de favoriser les autre).