web-dev-qa-db-fra.com

Dois-je passer de l'utilisation de boost :: shared_ptr à std :: shared_ptr?

Je voudrais activer la prise en charge de C++ 0x dans GCC avec -std=c++0x. Je n'ai absolument pas nécessairement besoin des fonctionnalités C++ 11 actuellement prises en charge dans GCC 4.5 (et bientôt 4.6), mais je voudrais commencer à m'y habituer. Par exemple, dans certains endroits où j'utilise des itérateurs, un type auto serait utile.

Mais encore une fois, je n'ai besoin d'aucune des fonctionnalités actuellement prises en charge. Le but ici est de m'encourager à intégrer les fonctionnalités de la nouvelle norme dans mon "vocabulaire" de programmation.

D'après ce que vous savez de la prise en charge de C++ 11, est-ce une bonne idée de l'activer dans GCC, puis de l'adopter en, par exemple, en passant de l'utilisation de boost::shared_ptr à std::shared_ptr exclusivement car les deux ne se mélangent pas?

PS: je connais cette bonne question qui compare les différentes saveurs de shared_ptr mais je demande un conseil de niveau supérieur sur lequel utiliser avant la finalisation de la norme. Une autre façon de dire cela, lorsqu'un compilateur comme GCC dit qu'il prend en charge une "fonctionnalité expérimentale", cela signifie-t-il que je risque de rencontrer des erreurs étranges lors de la compilation qui seront des pertes de temps importantes et une source de questions cryptiques sur StackOverflow?

Edit : J'ai décidé de revenir de std::shared_ptr parce que je ne fais tout simplement pas confiance à son support dans GCC 4.5 comme montré par l'exemple dans cette question .

c++booststlc++11shared-ptr
65
Alan Turing

Il y a plusieurs raisons de passer à std::shared_ptr :

  • Vous supprimez une dépendance à Boost.
  • Débogueurs. Selon votre compilateur et votre débogueur, le débogueur peut être "intelligent" à propos de std::shared_ptr et montrer directement l'objet pointé, où il ne pourrait pas, par exemple, booster l'implémentation. Au moins dans Visual Studio, std::shared_ptr ressemble à un simple pointeur dans le débogueur, tandis que boost::shared_ptr expose un tas d'entrailles de boost.
  • Autres nouvelles fonctionnalités définies dans votre question liée.
  • Vous obtenez une implémentation qui est presque garantie d'être activée pour la sémantique de déplacement, ce qui pourrait enregistrer quelques modifications de refcount. (Théoriquement - je ne l'ai pas testé moi-même) Depuis le 2014-07-22 au moins, boost::shared_ptr comprend la sémantique des mouvements.
  • std::shared_ptr utilise correctement delete [] sur les types de tableaux, tandis que boost::shared_ptr provoque un comportement indéfini dans de tels cas (vous devez utiliser shared_array ou un suppresseur personnalisé) (En fait, je me corrige. Voir ceci - la spécialisation pour cela est pour unique_ptr seulement non shared_ptr.)

Et l'une des principales raisons flagrantes de ne pas:

  • Vous vous limiteriez au compilateur C++ 11 et aux implémentations de bibliothèques standard.

Enfin, vous n'avez pas vraiment à choisir. (Et si vous ciblez une série de compilateurs spécifique (par exemple MSVC et GCC), vous pouvez facilement l'étendre pour utiliser std::tr1::shared_ptr quand disponible. Malheureusement, il ne semble pas y avoir de méthode standard pour détecter le support TR1)

#if __cplusplus > 199711L
#include <memory>
namespace MyProject
{
    using std::shared_ptr;
}
#else
#include <boost/shared_ptr.hpp>
namespace MyProject
{
    using boost::shared_ptr;
}
#endif
58
Billy ONeal

Je suppose que cela dépend de combien vous utilisez boost. Personnellement, je ne l'utilise qu'avec parcimonie (en fait la bibliothèque de nombres aléatoires, dans un seul projet). J'ai récemment commencé à utiliser -std=c++0x pour mes autres projets, et j'y utilise les nouvelles fonctionnalités de la bibliothèque std :: comme shared_ptr. J'aime que mes projets aient le minimum de dépendances, donc je préfère dépendre de l'implémentation de bibliothèque standard du compilateur plutôt que de boost.

Mais je ne pense pas qu'il existe une réponse unique à cette question.

13
Neil Butterworth

Vous devez toujours utiliser std::shared_ptr dans la mesure du possible, si disponible, au lieu de boost. C'est essentiellement parce que toutes les nouvelles interfaces qui utilisent shared_ptr utilisera le ptr partagé standard.

12
Puppy

Ce n'est probablement pas une mauvaise idée de commencer à prendre l'habitude d'utiliser std :: shared_ptr lorsque le compilateur le permet. Puisque l'interface est identique à shared_ptr de boost, vous pouvez toujours revenir en arrière si vous en aviez besoin.

7
Chris Mennie

Outre la cohérence de l'implémentation, boost::shared_ptr conserve actuellement au moins deux avantages de niche par rapport à std::shared_ptr:

4
dhaffey

Une autre raison de passer à std::shared_ptr: Elle supporte std::unique_ptr, c'est-à-dire a un constructeur.

boost::shared_ptr non.

4
papafi

Si vous construisez sur la seule plate-forme qui vous convient (faites le changement)
(Remarque: vous avez des tests unitaires pour valider la compatibilité descendante, n'est-ce pas?)

Si vous compilez sur plusieurs plates-formes, c'est là que cela devient un peu plus gênant, car vous devez valider que les fonctionnalités de g ++ 4.5 sont disponibles sur toutes les plates-formes que vous utilisez (c'est-à-dire la construction pour MAC/Linux, le compilateur Mac g ++ par défaut est toujours un couple de version derrière les compilateurs par défaut sous Linux).

4
Martin York

J'ai trouvé que std :: shared_ptr était plus rapide que boost :: shared_ptr. J'ai fait un test, vous pouvez consulter le code et voir les résultats du graphique à secteurs comparant les pointeurs partagés boost, Qt et std.

enter image description here

https: //www.osletek.com ...

1
rosewater