Discussion :

[Suryavarman]

J’ai cette question qui me revient souvent.

A chaque fois que je passe un pointeur partagé en paramètre je me demande si je dois le faire passé par référence.

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
void Toto(std::shared_ptr<Lala>& lala)
{
    …
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
void Toto(std::shared_ptr<Lala> lala)
{
    …
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
void Toto(const std::shared_ptr<Lala>& lala_const)
{
    …
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
void Toto(const std::shared_ptr<Lala> lala_const)
{
    …
}

etc


Quel raisonnement suivez-vous/conseillez-vous pour faire votre choix?

[Médinoc]

Dans tous les cas l'objet lui-même ne sera pas copié.
Je dirais passe le shared_ptr par copie tant que tu n'as pas passé ton code au profileur et déterminé que cet appel de fonction était performance-critical.

[skeud]

De mon point de vu:
Il faut le passer en copie et non en référence. Le but des shared_ptr, est de pointer le nombre de référence dans chaque contexte, comme tu appelles une nouvelle fonction, tu augmente le nombre de contexte, donc on incrémente .
Imaginons que tu décides de threader ton appel de fonction, si tu le passes en référence, tu pourrais avoir des surprises ^^
D'autant plus qu'une copie d'un shared_ptr est très peu couteuse en cpu, donc pas trop de raison de vouloir changer ça

Ne jamais oublier "KISS"

[Bousk]

De base, le passage par référence tu oublies direct. Ce truc est là uniquement pour modifier le paramètre dans la fonction pour l'appelant.

Maintenant que l'on sait que la bataille se situe entre const& et copie, on y réfléchit 2 minutes.
Est-ce que la fonction ne fait qu'utiliser le paramètre sans le toucher ? Parfait, il peut être const&, son passage sera optimisé et l'appelant n'aura aucune surprise.
Est-ce que la fonction modifie le paramètre en interne ? Alors tu demandes une copie. La copie aura pour effet que l'appelant pourra move sa variable si possible et donc aucune copie ne sera faite.

Le cas de shared_ptr est un peu plus subtil parce que c'est le shared_ptr qui serait copié ou const mais pas son objet interne. Mais cette copie coûte avec le compteur de référence, ce qui peut être non négligeable.

[skeud]

Le cas de shared_ptr est un peu plus subtil parce que c'est le shared_ptr qui serait copié ou const mais pas son objet interne. Mais cette copie coûte avec le compteur de référence, ce qui peut être non négligeable.

La création d'un shared_ptr par copie et donc incrémentation du compteur de référence est vraiment dimensionnant en terme de cout cpu? (Je connais pas trop, j'ai pas regarder les bench la dessus donc je pose la question ^^)

[Bousk]

Sur TotoProject sûrement pas, sur un vrai projet où tu as potentiellement des centaines/milliers de ces trucs et du code exécuté sur plusieurs threads et cores...
Ça a beau s'améliorer, utiliser des atomic, intrinsics etc, ça reste un moment un truc alloué et synchronisé.
La différence entre 30fps et 60fps c'est ~16ms/frame, c'est (très) peu et tout compte.

Le mieux étant de ne pas utiliser de shared_ptr.