Piège potentiel dans la dérivation à partir des conteneurs C STL
Dans le domaine de la programmation C, il y a souvent un débat sur les mérites de la dérivation à partir des conteneurs de la bibliothèque standard (conteneurs fournis avec la bibliothèque standard C, tels que les vecteurs, les listes, etc.) ou simplement en utilisant des typedefs pour les représenter (création d'un nouveau nom pour un type existant sans définir de nouveau type). Bien que les deux approches offrent leurs avantages, il est crucial d'être conscient d'un risque potentiel associé à la dérivation à partir de conteneurs STL.
Lors de l'utilisation de la dérivation, il est essentiel de se rappeler que les conteneurs standards, tels que les vecteurs, ne déclarer leurs destructeurs comme virtuels. Cela signifie que si vous dérivez de l'un de ces conteneurs et définissez un destructeur non virtuel dans votre classe dérivée, vous rencontrerez des problèmes lorsque vous tenterez de détruire un objet de cette classe dérivée à l'aide d'un pointeur vers la classe de base.
Pour illustrer cette problématique, considérons l'exemple suivant :
class Rates : public std::vector<double> { /* ... */ }; int main() { std::vector<double>* p = new Rates; delete p; // This will invoke the non-virtual ~std::vector<double>(), potentially leading to problems }
Dans ce cas, lorsque l'opérateur delete est appelé sur le pointeur p, il invoquera le destructeur de la base class, std::vector
Par conséquent, même si la dérivation à partir de conteneurs STL offre certains avantages, tels que l'activation de la surcharge de fonctions et de la spécialisation des modèles, il est crucial faites preuve de prudence et assurez-vous de ne pas remplacer le destructeur de classe de base par un destructeur non virtuel. Si vous avez besoin d'un comportement polymorphe, envisagez d'utiliser la composition au lieu de l'héritage.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!