liste, map ou tableau ?

[Fig]

Pour une fois que l'on a quelque chose à dire sur un sujet et qu'on est deux dans ce cas...

Oui, ça revient à comparer les clés stockés dans la liste avec celle recherchée. Ce n'est pas si lent si il y a peu d’éléments en collision (passer en revue 10 élements de liste chainée, ça va vite), sinon, ça craint effectivement, d'où l'importance de bien ajuster le nombre de slot.
Si Fred peut confirmer...

Le paramètre optionnel 'Slots' défini le nombre de slots interne qui sera utilisé par la map pour effectuer le stockage des éléments. Plus il y a de slots en interne, plus l'accès à un élément sera rapide, mais plus la consommation mémoire sera importante. C'est un compromis dépendant du nombre d'éléments que la map contiendra au maximum et de la rapidité nécessaire à l'accès d'un élément. La valeur par défaut est 512. Ce paramètre n'a pas d'influence sur le nombre d'éléments que la map peut contenir.

[graph100]

effectivement si on examine la doc avec la lumière de ton explication précédente, c'est cohérent.
Cependant, ce serais bien si Fred nous expliquait dans le détails la gestion des Tableaux/Listes chainées/Map.
Il m'est souvent arrivé de devoir fouiller dans la mémoire pour tenter de trouver une explication à certains trucs, ou pour pouvoir faire des choses qui ne sont pas permises pour le moment par pb.

En gros je n'aime pas les boites noires. (Mais si ça pose un problème par rapport au fait que pb est vendu, bah je comprendrais )
ma justification est alimenté par la volonté de comprendre. Et d'arriver un résultat avec les bons outils.

un exemple : j'ai eu besoin de connaitre le type et de pouvoir accéder aux éléments d'un tableau sans avoir créer le tableau. C'est faisable en allant regarder avant le tableau, mais j'aimerais savoir vers quoi vont les pointeurs et les nombres bizarres qui sont en mémoire juste avant...
en fait, il n'y a pas ou peu d'outils permettant de faire des codes dont le destinataire est un programmeur. (Bien sur je ne veux pas que pb deviennent un fouillis énorme comme VB.net)

[Fig]

Oui je suis comme toi.
Mais avec la nouvelle version de pb, je trouve qu'on peut à peu près tout faire, notamment les push et pop des adresses des listes qui évitent des manipulations fastidieuses de pointeurs quand on a une double boucle foreach/fornext qui utilise la même liste.

Sinon c'est vrai tu es obligé de tout réinventer, comme les listes chainées, à l'époque où on ne pouvait les inclure dans les structures... (allocatememory et peek/poke, voir asm...)

J'envoie un message perso à Fred voir si il veut venir nous expliquer cela...

[graph100]

ouki ^^ j’attends de voir

ah la la, pour les listes chainées avec peek et poke xD j'avais fait un code assez gros pour implémenter une structure en tree, car ça n'existe pas encore ça. Fallais que chaque nœud renvoie sur son parent, et que chaque parent liste tout ses enfants. Avec le problème du nœud initial et l'accès à chaque nœud avec son "adresse" (exprimée en coordonnée de nœud dans la liste du parent) --> un gros sac de nœud
Je voulais faire un prog qui modélise la croissance d'une plante ^^, intéressant, mais j'ai stoppé.

Il manque encore des choses dans les push / pop : dans tu fais ton prog en thread, un foreach n'est absolument pas sur, que ce soit avec une liste ou une map.

Du coup, mon code avec l'environnement des gadgets regorge de truc du genre :

Code : Tout sélectionner

*pointeur.Structure_de_l_element_de_map = FindMapElement(Main_Var\MaMap(), ma_cle$)

sinon c'est pas thread safe. L'élément courant risque d'être modifié par un autre thread.

on n'a pas non plus de bidule complètement threadsafe pour mettre des elements dans une file par le bas et les prendre avec un autre thread par le haut. Faut se taper des sémaphores pour l'accès à la liste. Mais je n'arrive pas à être clair avec moi-même sur ce coup là :s

[Fred]

Oui les map dans PB utilisent une liste chainée en cas de collision.

[graph100]

merci Fred (très sobre, mais je suppose qu'on en demande trop)