Salut à tous,
Je suis d'accord avec la simplicité très terre à terre de calcul de Brossden.
Et c'est d'ailleurs avec ce raisonnement qu'on est contraint de réfléchir pour utiliser les blocs mémoire et les gérer.
En fait, les listes chaînées sont très bien pour la plupart des utilisations.
SAUF quand la taille de la structure de l'élément est petite. Or dans le cas du traitement de données massif, Fred ne peut pas répondre à tous nos besoins spécifiques : la structure interne d'un élément est actuellement élaborée pour répondre au mieux à ce qu'on attend couramment d'une liste chaîne. Et il en a fait l'instruction SortXXX().
Côté matériel, le CPU a une méthode de recherche extrêmement rapide mais très rigide, car elle se base sur la contigüité des données traitées. Le seul moyen de rendre les données compatibles à ce type de traitement c'est justement de fractionner chaque élément d'une pseudo-liste et de les classer par champ, voire de «sous-champ», voire plus précis encore selon les domaines d'utilisation de la base de données.
Pour illustrer, prenons l'exemple de la centrale de casse automobile (c'est la liste chaînée).
Il y a plein de voitures accidentées (éléments de la liste chaînée) dans tous les sens. Et vous avez recruté Superman pour bosser avec vous là-dedans. Superman, c'est l'instruction de recherche du CPU (j'ai posté une explication il y a qqes mois (rech >> SCASB, SCASW ou SCASD).
Un client arrive avec une voiture en panne : c'est le carburateur.
Vous ne pouvez pas demander à Superman d'aller chercher un carburateur comme ça. Il vous faut démonter TOUTES LES VOITURES et les classer par nature (je ne vous parle même pas de la «traçabilité» qu'il faut faire pour pouvoir les remonter ensuite). Ainsi, si vous avez 25 kilomètres de carburateurs différents qui se succèdent tous les 15 centimètres, Superman vous trouvera le carburateur très rapidement.
Cette technique n'est valable qu'avec les blocs mémoire. Et je pense que c'est sûrement la technique utilisée pour les puissants gestionnaires de base de données. Seulement, elle est très spécifique, donc à chaque type de recherche, il y a un type de classement. Elle n'est valable que dans le cas d'une multitude de recherches successives dans le même classement. Ce qui peut tout de même arriver fréquemment.
C'est la raison pour laquelle j'ai posté cette idée plus haut, en répondant à la question «n'y a-t-il pas une meilleure solution ?». Car, Neosis en sachant ce que tu as (type de données) et ce que tu veux (type de traitement), les listes chaînées peuvent s'avérer trop gourmandes en mémoire.
Maintenant, ton problème est ailleurs et réglé. Donc ceci est hors sujet.
, en fait j'ai besoin de stocker de nombreuses données pendant que mon programme fonctionne et pour cela j'utilise des listes chainée. Pour le moment j'ai 2 listes chainée avec environ 12000 éléments dans chaque listes. A chaque élément j'ai environ 8 variables, bref tous ça fait pas mal et je voudrais savoir si il n'y a pas de meilleurs solutions.
