Je pense que ça dépend de l'endroit où vous allez les utiliser. Je suppose que ce que vous envisagez de faire est quelque chose comme ça :
template <class T>
class BinaryTreeNode
{
//public interface ignored for this example
private:
shared_ptr<BinaryTreeNode<T> > left;
shared_ptr<BinaryTreeNode<T> > right;
T data;
}
Ce serait parfaitement logique si vous attendez de votre structure de données qu'elle gère les nœuds créés dynamiquement. Cependant, comme ce n'est pas la conception normale, je pense que c'est inapproprié.
Ma réponse serait que non, ce n'est pas un endroit approprié pour utiliser shared_ptr, car l'utilisation de shared_ptr implique que l'objet est réellement partagé - cependant, un nœud dans un arbre binaire est no jamais partagé. Cependant, comme Martin York l'a souligné, pourquoi réinventer la roue - il existe déjà un type de pointeur intelligent qui fait ce que nous essayons de faire - auto_ptr. Donc, allez-y avec quelque chose comme ça :
template <class T>
class BinaryTreeNode
{
//public interface ignored for this example
private:
auto_ptr<BinaryTreeNode<T> > left;
auto_ptr<BinaryTreeNode<T> > right;
T data;
}
Si quelqu'un demande pourquoi les données ne sont pas des trices partagées, la réponse est simple : si des copies des données sont bonnes pour l'ensemble de l'organisation, il est possible d'en faire des copies. client de la bibliothèque, ils passent dans l'élément de données, et le nœud de l'arbre fait une copie. Si le client décide que les copies sont une mauvaise idée, alors la client Le code peut passer dans un shared_ptr, que le nœud d'arbre peut copier en toute sécurité.