bonjour,

J'ai un problème dans le code suivant : http://pastebin.com/m6b2e9308
le removeElement ne fonctionne jamais...
L'ajout fonctionne bien avec le addElement, par contre impossible de faire un removeElement... J'ai essayé 2facons différentes, mais rien à faire...
Je vous donne la classe Client au cas ou : http://pastebin.com/m22d5d5a1

Je vous épargne tout le code vu que le problème est à ce niveau.

merci

La fonction removeelement compare les objets grace a la fonctions equals de Client. As tu bien defini cette fonctoin ?
Si elle n'est pas defini, equals test l'egalite de reference, comme tu a l'air de recreer des objet a chaque fois, ca m'a l'air d'etre la cause de l'erreur.

oui j'ai bien redéfini equals, il est dans la classe Client. Et je n'ai pas vu d'erreur à ce niveau, mais il est vrai que je débute...

bon, j'ai testé 2-3 trucs sans résultat...

J'aurai néanmoins une autre question : j'ai rajouté un peu de code de debug pour trouver l'erreur dans la fonction qui suit.

public void retraitClient (Client clt) {

Vector v = (Vector) dico.get(clt.getSociete());
if (v == null) return;

for (int i =0 ; i< v.size() ; i++) {
Client iop = (Client) v.elementAt(i);
System.out.println(iop);
System.out.println(i);
}
if (clt.equals((Client)v.elementAt(2))) System.out.println("EGAL!!!");

v.removeElement(clt);
if (v.size() == 0) dico.remove(clt.getSociete());
}

Quand je l'exécute "EGAL" s'affiche, pourtant le removeElement ne s'exécute pas. Et là je ne comprends vraiment pas...

Autre question : si je ne cast pas le v.elementAt(2) en classe "Client", equals renvoit faux. Du coup je ne comprends pas trop quel classe il prends comme référence sans le cast...

if (v.elementAt(2).equals(clt)) System.out.println("EGAL!!!");

en fait dans ce sens là ca ne fonctionne pas d'ou le porblème je suppose...
Mais je ne comprends pas là

On peut voir la méthode equals de ta classe?
Sinon tu peux utiliser contains() pour vérifier que l'élément existe dans le vecteur.

Par ailleurs, la classe vector est plus vraiment recommandée à l'utilisation si jamais tu le savais pas.

la méthode equals se trouve dans le deuxième lien ( http://pastebin.com/m22d5d5a1 )

Et sinon je débute en Java, c'est ce qu'on a vu en cours, je suppose que c'est par simplicité au début... Mais effectivement je viens de lire ca en faisant mes recherches.
Mais merci pour l'info.

on est cense utilise quoi a la place de Vector ?

ArrayList...

Et si tu as besoin de la synchronisation interne tu peux toujours créer un wrapper qui gère celle-ci en écrivant :

List list = Collections.synchronizedList( MonArrayList );

L'avantage c'est que tu peux cesser d'utiliser la synchronisation si celle-ci n'est plus utile en cessant simplement d'utiliser le wrapper.

C'est bien de faire gaffe aux types de collections qu'on utilise même si on débute.

//equals version rigide
//(ici on sépare la vérification de la classe de celle des attributs
//pour un éventuel appel d'equals dans une sous-classe)

public boolean equals(Client x) {
if( ( x!=null) && ( x.getClass() == Client.class) )
{
return egalite( (Client)x );
}
return false;
}

protected final boolean egalite (Client clt) {
return (this.nom.equals(clt.nom)) && (this.societe.equals(clt.societe));
}

_skip, la difference avec vector est uniquement qu'elle n'est pas synchronized ? ou il y a quelque chose de different dans l'implementation ? (Le nom me fait penser a une implementation en liste chaine de tableau de taille fixe.)

ok en fait j'ai trouvé mon erreur, je pensais avoir redéfinit equals, mais en fait elle était seulement surchargée.

C'était pas un object en paramètre, j'avoue que ça m'a échappé aussi...
Tu peux éviter ce genre de désagrément en mettant l'annotation @Override au dessus de la déclaration de la méthode. En plus ça améliore la lisibilité je trouve.

@godrik
Oui en dehors de la synchronisation ces classes sont grosso-modo équivalentes. Mais utiliser un Vector si un ArrayList suffit, c'est à éviter.

Par ailleurs une synchronisation de ce genre est rarement intéressante car souvent tu souhaiterais locker le temps de plusieurs opérations, par exemple un test sur size suivi d'un ou plusieurs get/add/remove. Or là si tu te contentes de ce que propose Vector avec son lock par opération non seulement c'est pas performant mais en plus tu as déjà un gros risque de race condition entre les appels aux méthodes.

La synchronisation sur les objets ne m'ont jamais bien convaincu en java. La plupart du temps ce n'est pas suffisant et ca rajoute un overhead quand tu n'utilises pas de multi-threading.

Dans le récent package java.util.concurrent tu as des choses intéressantes, comme les queues synchrones ou les maps concurrentes qui sont des galères à implémenter soi-même.

Pour développer des applications parallèles, java est franchement riche. Quand j'ai migré nos algos vers du C++, ça m'a manqué.

(a la relecture du message, je m'apercois que ca ressemble a un troll, mais je le poste quand meme)

Je suis toujours super dubitatifs quand on dit que java est riche. La plupart des outils s'ecrivent tres bien et sont certainement deja ecrit quelques part. 95% de la java doc ce sont des exercices d'etudiant. C'est sur que c'est pratique de ne pas avoir a les ecrire.
Mais j'ai l'impression qu'il manque plein de chose dedans. Par exemple la derniere fois que j'ai regarde, je n'ai pas trouve de tas de fibonacci. Tu trouve un tas classique : PriorityQueue (avec une implementation assez mauvaise qui ne te laisse pas gerer des tas non binaire), mais pas de tas de fibonacci (Ca devrait implementer AbstractQueue et je ne vois rien qui y ressemble).

La queue synchrone ca n'a pas l'air plus complique qu'un moniteur de hoare avec deux files d'attente. C'est sur que les files d'attente proposees par le systeme ne sont en general pas FIFO, mais c'est un exercice classique d'implementer des files d'attente FIFO a partir de file d'attente "aleatoire".
Si tu ne veux pas te faire une file d'attente FIFO, tu t'en sors avec un semaphore par objet dans la liste.

Si j'ai bien compris la map concurrente, c'est juste une map partitionne en x ensembles ou chaque ensemble est protege par un semaphore.

C'était des exemples, la map concurrente est intéressante car elle permet de lire simultanément aux insertions de façon cohérente même si celles-ci déclenchent un rehash.

Mais il y a aussi des mécaniques intéressantes comme un threadpool disposant d'une file d'admission limitée qui peut forcer le thread producteur à se joindre aux consommateurs s'il y a bourrage.

Des tas de petites choses tout à fait stables que tu peux utiliser les yeux fermés, crois-moi c'est agréable. Je dis que java est riche parce que quasiment tout ce dont tu peux avoir besoin existe déjà, et le plus souvent en open source.

C'est rigolo cette difference de point de vue. Personnellement, java m'interesse pour son cote "write once, run everywhere", mais j'execre completement l'api java que je trouve fouilli et pas riche du tout. L'argument de l'open source est un peu pipeau, je suis sur qu'il y a des lib opensource relativement complete meme en brainfuck (ok, ptet pas en brainfuck).

En meme temps, je m'interesse pas vraiment aux problemes auxquels java repond.

Je suis curieux de savoir à quoi tu compares pour dire que ce n'est pas riche...

C'est pas que je défend java parce que ce n'est de loin pas ma techno préférée, cependant je suis obligé de reconnaître ses qualités, et justement ce qui rend java intéressant c'est la multitude de librairies et de modules qui sont à ta disposition (d'ou argument open source).

Je pense qu'il n'y a rien de riche dans ce domaine, mais les gens la trouve riche. C'est peut etre la plus riche de toute dans le cote api standard : les python, ruby et compagnie ne sont pas aussi gros que java. Et les C/C++ partent du principe que tu re implementeras ce dont tu as besoin pour coller a ton cas d'utilisation. Mais ca reste tout petit par rapport a ce qui est classique et dont tu as besoin (j'ai besoin) tout le temps:
-des structure dynamique implemente dans des tableaux pour augmenter la coherence des caches
-des iterateurs cache aware sur les tableaux multidimentionnel
-Des arbres de recherche pas binaire
-des generateurs aleatoires de loi arbitraire
-des outils de graphes
...

C'est pas que c'est difficile a trouver ou a implementer: Ca fait 30 ans que c'est ecrit par tous les etudiants en informatique du monde.

C'est juste que ca me fait marrer que les gens trouver java fourni en fonctionnalite alors que des que tu as besoin d'un truc plus complique qu'une liste chaine, il faut aller le chercher dans un paquet externe ou le reecrire.