Une liste intrusive est une liste dans laquelle le pointeur sur le nœud de liste suivant est stocké dans la même structure que les données de nœud. C’est normalement une mauvaise chose, car il lie les données à la mise en œuvre de liste spécifique. La plupart des bibliothèques de classes (par exemple, la bibliothèque standard C ++) utilisent des listes non intrusives, où les données ne connaissent rien à la mise en oeuvre de la liste (ou des autres conteneurs).

J’aime réellement le modèle intrusif

1. C’est mieux sur la mémoire (pas beaucoup de petites allocations pour que les choses pointent vers d’autres choses)
2. Il vous permet d’avoir un object qui existe dans plusieurs conteneurs
3. Il vous permet de rechercher un élément avec un seul mode de recherche (hash), puis de rechercher le prochain élément dans l’ordre lexographique (ce n’est pas la même chose que # 2, mais cela peut aussi être le multi_index_container de boost complété , mais notez que multi_index_container a certaines lacunes ne sont pas des problèmes avec intrusive)

Intrusif est BON
Vous avez juste besoin de savoir ce que vous faites (ce qui est vrai pour tout conteneur)

Les listes intrusives sont des listes où les objects sont eux-mêmes des têtes ou des cellules de listes. Ce sont des bonnes ou des mauvaises choses selon le contexte.

Dans certains modules définis (groupe de classes insécable travaillant ensemble), il peut s’agir du MEILLEUR moyen de lier les relations entre les classes. Ils permettent la gestion directe et complète sans frais de relations communes telles que l’unicité (ex: les pommes n’apparaissent pas deux fois dans les applets, et cela ne nécessite aucune clé, et les pommes n’appartiennent pas à deux arbres distincts), elles sont navigables. dans les deux sens (access direct à une pomme donnée et à des pommes à une pomme). Toutes les opérations de base sont O (1) (pas de recherche dans un conteneur externe).

Les listes intrusives sont TRES BAD entre deux modules. Parce qu’ils seront liés ensemble et que la justification des modules est la gestion de l’indépendance du code.

Voici une brève description valable pour les listes également:

I. Conteneurs intrusifs.

L’object à stocker contient des informations supplémentaires pour permettre l’intégration dans le conteneur. Exemple:

 struct Node
 {
     Node * next;  // Additionnel
     Node * prev;  // information 
     Données T;
 } 

1. Avantages:

• stocke les objects eux-mêmes.
• n’implique pas de gestion de la mémoire.
• l’itération est plus rapide.
• meilleures garanties d’exception.
• prévisibilité dans l’insertion et la suppression d’objects. (Aucune gestion de mémoire supplémentaire (non prévisible) n’est requirejse.)
• meilleure localité de mémoire.

2. Inconvénients:

• contient des données supplémentaires pour l’intégration du conteneur. (chaque type de magasin doit être adapté (modifié) aux exigences du conteneur.)
• attention aux éventuels effets secondaires lors de la modification du contenu de l’object stocké (notamment pour les conteneurs associatifs).
• gestion de la durée de vie de l’object inséré, indépendamment du conteneur.
• L’object peut éventuellement être supprimé avant d’être effacé du conteneur, ce qui entraîne l’invalidation de l’iterator.
• les contenants intrusifs sont NON copiables et NON assignables.

II. Conteneurs non intrusifs (conteneurs standard C ++)

L’object ne “sait” pas et contient des détails sur le conteneur dans lequel doit être stocké. Exemple:

 struct Node
 {
     Données T;
 } 

1. Avantages:

• ne contient pas d’informations supplémentaires concernant l’intégration du conteneur.
• la durée de vie de l’object gérée par le conteneur. (moins complexe.)

2. Inconvénients:

• stocker des copies des valeurs passées par l’utilisateur. (construction sur place possible.)
• un object ne peut appartenir qu’à un seul conteneur. (ou le contact devrait stocker les pointeurs sur les objects.)
• frais généraux sur le stockage des copies. (comptabilité sur chaque affectation.)
• les objects non-copiables ou non-mobiles NE PEUVENT PAS être stockés dans des conteneurs non intrusifs.
• ne peut pas stocker d’object dérivé et conserve toujours son type d’origine (trancher – perd le polymorphism.)