Allocation pimpl et pile

Question

Alors j'ai pensé à Pimpl et à la répartition de la pile.J'ai écrit une bibliothèque et j'ai décidé d'utiliser PIMPL pour masquer le membre privé de la classe.Cela signifie que j'aurais une classe déclarée comme celle-ci

class Foo {
private:
    class Handle;
    std::tr1::shared_ptr<Handle> handle;
public:
    Foo();
};

C'est assez simple en avant.Mais dans le constructeur, vous faites cela

Foo::Foo() : handle(new Handle()) {}

Alors, lorsque quelqu'un qui utilise ma bibliothèque crée un foo sur la pile, ils font essentiellement une allocation de tas de toute façon.Est-ce le compromis que vous devez vivre lorsque vous utilisez PIMPL?J'ai pensé à libérer la documentation avec un avertissement à côté des constructeurs: "Avertissement: Cela se traduit par une allocation de tas" ou somesuch.

Mon autre pensée était d'avoir toutes les classes exposées à la mise en œuvre comme des interfaces virtuelles pures et un tas de méthodes d'usine statiques qui renvoient des pointeurs intelligents.Cela signifie aussi une allocation de tas, mais il n'y a pas d'astuce à elle.

Toutes les pensées ou suggestions?Suis-je trop attentif aux programmeurs utilisant ma bibliothèque?

Answer 1

est-ce le compromis que vous devez vivre lorsque vous utilisez PIMPL?

Effectivement, oui, bien qu'il existe des techniques, telles que celles discutées par Herb Sutter dans "Le Fast Pimpl Idiom, " qui peut être utilisé pour éliminer ou accélérer l'allocation de tas, au prix d'une plus grande complexité.

J'ai pensé à libérer la documentation avec un avertissement à côté des constructeurs: "Avertissement:" AVERTISSEMENT: Cela se traduit par une allocation de tas "ou somesuch.

Seulement s'il est nécessaire de le faire (c'est-à-dire que si vos utilisateurs seraient surpris par le fait que votre classe a effectué une allocation de tas). De nombreuses classes effectuent une allocation de tas, y compris de nombreux de ceux de la bibliothèque standard C ++ (tous les conteneurs, par exemple).

Suis-je trop attentif aux programmeurs utilisant ma bibliothèque?

éventuellement :-). Sauf si vous avez des exigences de haute performance pour votre classe ou que vous vous attendez à ce que les cas de votre classe soient créés et détruits extrêmement fréquemment, je ne m'inquiéterais pas trop. Bien sûr, si vous avez des exigences de performance significatives, PIMPL peut ne pas être un bon choix.

Answer 2

Alors, lorsque quelqu'un qui utilise ma bibliothèque crée un foo sur la pile, ils font essentiellement une allocation de tas de toute façon. Est-ce le compromis que vous devez vivre lorsque vous utilisez PIMPL?

yep.

J'ai pensé à libérer la documentation avec un avertissement à côté des constructeurs: "Avertissement:" AVERTISSEMENT: Cela se traduit par une allocation de tas "ou somesuch.

Je considérerais que sur des commentaires agressifs :) Si votre classe est si critique, vous devriez peut-être éviter l'idiome pimpl. Si vous représentez un numéro, cela pourrait être concernant et la peine de noter. Si vous cachez la mise en œuvre d'une connexion de base de données, ne valez pas le commentaire :)

Mon autre pensée était d'avoir toutes les classes exposées à la mise en œuvre comme des interfaces virtuelles pures et un tas de méthodes d'usine statiques qui renvoient des pointeurs intelligents. Cela signifie aussi une allocation de tas, mais il n'y a pas d'astuce à elle.

Ouais, c'est un peu plus évident pour l'utilisateur, mais encore une fois probablement ne vaut probablement pas la peine de vous-même.

Toutes les pensées ou suggestions? Suis-je trop attentif aux programmeurs utilisant ma bibliothèque?

Il y a un compromis, mais si votre classe est suffisamment complexe pour vraiment gagner de l'idiome Pimpl, vous pouvez probablement supposer qu'une allocation de tas est correcte. Si j'utilisais votre bibliothèque, cela ne me préoccuperait probablement pas.