Pimpl idiome

Le
DELVA Michael
Bonsoir à tous,

je voulais savoir dans quelle mesure vous utilisez l'idiome Pimpl.

A première vue ça a l'air être un idiome vraiment intéressant, mais je
souhaite avoir vos retours d'expérience concernant son utilisation.

Quand est-ce que vous l'utilisez? (tout le temps, en de rares occasions,
parfois?)

Sous quelles conditions? Sutter dit que c'est utilie pour les classes
largement utilisées. Comme vous avez modéré ses propos la dernière fois
concernant l'idiome du create and swap dans les opérateurs d'affectation,
je me posais cette question.

Merci d'avance

Michael
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michael DOUBEZ
Le #311857
je voulais savoir dans quelle mesure vous utilisez l'idiome Pimpl.

A première vue ça a l'air être un idiome vraiment intéressant, mais je
souhaite avoir vos retours d'expérience concernant son utilisation.

Quand est-ce que vous l'utilisez? (tout le temps, en de rares occasions,
parfois?)


Ca depend pourquoi il est utilisé. Le but du pimpl est de masquer les
détails d'implémetation afin d'éviter les recompilations de code (au
cout d'une indirection).

Je n'ai jamais eu l'occasion de l'utiliser pour cette raison mais ça
m'est arrivé d'utiliser l'idiome pour unifier des classes orthogonales
ou encore pour changer la strategie d'un objet dynamiquement. Enfin,
c'est pas le genre de chose que je fais tous les jours.

Michael

Loïc Joly
Le #311856
Bonsoir à tous,

je voulais savoir dans quelle mesure vous utilisez l'idiome Pimpl.

A première vue ça a l'air être un idiome vraiment intéressant, mais je
souhaite avoir vos retours d'expérience concernant son utilisation.


En tant que tel, très peu. Pas pour des raisons intrinsèques, mais parce
qu'on m'a imposé dans mon environnement actuel de réaliser cette
séparation interface/implémentation par l'intermédiaire de classe
d'interface à la Java plutôt que par du pimpl.

Sur le principe de bien marquer une frontière entre deux niveaux
d'abstraction, par contre, c'est je pense une bonne chose, mais elle me
semble très coûteuse en temps (de plus pour écrire du code sans valeur
ajoutée, mécaniquement), du coup je ne sais pas trop à partir de quel
niveau de stabilité de l'interface et de non stabilité de
l'implémentation ça devient rentable.

Si je devais commencer un nouveau projet, je me demanderais dans quelle
mesure cette couche d'isolation ne pourrait pas s'automatiser.

--
Loïc

James Kanze
Le #311855
DELVA Michael wrote:
je voulais savoir dans quelle mesure vous utilisez l'idiome
Pimpl.

A première vue ça a l'air être un idiome vraiment intéressant,
mais je souhaite avoir vos retours d'expérience concernant son
utilisation.

Quand est-ce que vous l'utilisez? (tout le temps, en de rares
occasions, parfois?)

Sous quelles conditions? Sutter dit que c'est utilie pour les
classes largement utilisées. Comme vous avez modéré ses propos
la dernière fois concernant l'idiome du create and swap dans
les opérateurs d'affectation, je me posais cette question.


Dans mon cas, c'est prèsqu'un automatisme. La question serait
plutôt quand ne pas l'utiliser (des petites objets très stables,
par exemple, ou dans les hièrarchies où on travaille a de toute
façon une classe de base abstraite).

Sinon, j'imagine que ça dépend un peu du contexte. Dans une
application numérique, par exemple, avec peu de (source) code et
des contraints de performance, il doit servir certainement
moins. C'est un idiome qui convient surtout pour des projets
assez gros (en termes de lignes de code) où les performances
sont de toute façon limitées par les entrées/sorties (mais cette
caractèrisation couvre la plupart des systèmes commerciaux, je
crois).

--
James Kanze (GABI Software) mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze
Le #311854
Loïc Joly wrote:

Si je devais commencer un nouveau projet, je me demanderais
dans quelle mesure cette couche d'isolation ne pourrait pas
s'automatiser.


D'après ce que j'ai compris, il ne doit pas être difficile à
faire que Rose le génère. Malheureusement, je n'ai pas pu
l'expérimenter réelement, parce que dans la dernière application
où je m'étais servi de Rose, ils avaient déjà adopté la
politique des classes abstraites de base et des fonctions usine
pour arriver aux mêmes fins. Or, même si je trouve l'idiome du
pare-feu de compilation mieux, la différence n'est pas assez
grande pour bousculer leurs habitudes.

--
James Kanze (GABI Software) mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

espie
Le #311813
In article DELVA Michael
Bonsoir à tous,

je voulais savoir dans quelle mesure vous utilisez l'idiome Pimpl.

A première vue ça a l'air être un idiome vraiment intéressant, mais je
souhaite avoir vos retours d'expérience concernant son utilisation.

Quand est-ce que vous l'utilisez? (tout le temps, en de rares occasions,
parfois?)


Exemple d'utilisation en conditions reelles: KDE.
La quasi-totalite des bibliotheques du systeme fait amplement reference
a pimpl, pour des raisons evidentes d'ingenierie.

Ca colle tres precisement aux raisons evoquees par Sutter.

Cas de non utilisation de pimpl: code extremement simple, performances
redhibitoires liees a l'indirection supplementaire, classes `concretes'
ou pimpl ne fait pas de sens... (presque du POD).

Fabien LE LEZ
Le #311812
On 10 Oct 2007 19:24:17 GMT, DELVA Michael
Quand est-ce que vous l'utilisez?


Typiquement, quand la classe contient des objets (ou hérite d'une
classe) dont la définition demande l'inclusion d'une grande quantité
de headers.
Et en pratique, c'est assez rare -- généralement, deux ou trois très
grosses classes dans une application.

Fabien LE LEZ
Le #311811
On Thu, 11 Oct 2007 00:22:51 -0700, James Kanze

C'est un idiome qui convient surtout pour des projets
assez gros (en termes de lignes de code)


Plutôt en terme de temps de compilation, non ?
(C'est bien toi qui parlais de temps de compilation excessivement
longs parce que tous les fichiers sources n'étaient pas sur la même
machine ?)

Si tu travailles avec une machine puissante, qui te permet de
recompiler complètement ton gros projet en trois minutes, je suis sûr
que tu utiliseras moins ce genre d'idiome.

James Kanze
Le #311810
On Oct 12, 1:12 am, Fabien LE LEZ
On Thu, 11 Oct 2007 00:22:51 -0700, James Kanze

C'est un idiome qui convient surtout pour des projets
assez gros (en termes de lignes de code)


Plutôt en terme de temps de compilation, non ?


Les deux vont ensemble, non ?

Je voulais simplement préciser qu'il ne s'agissait pas d'un
« assez gros » en termes d'occupation mémoire ; qu'une
application numérique de 10000 lignes n'y comptait pas, juste
parce qu'il contenait des dizaines de tableaux de quelque méga.
Quand on dit « gros », sans préciser, j'imagine facilement une
application qui utilise 2 ou 3 Giga de mémoire principale, même
si elle ne fait que 100 lignes de code.

(C'est bien toi qui parlais de temps de compilation excessivement
longs parce que tous les fichiers sources n'étaient pas sur la même
machine ?)


La véritable avantage, c'est de ne pas avoir besoin de
récompiler plus d'une ou deux sources quand par exemple tu
ajoutes un membre privé. Et que tes clients ne choppent pas une
récompilation complète de leur sous-système simplement parce que
tu l'as fais (ou pire, qu'ils ne finissent pas avec un link où
differents composants ont été compilés avec différentes versions
de ton en-tête).

Dans des projets plus gros, il y a aussi l'avantage de pouvoir
modifier la structure des données « privées » sans avoir à
sortir l'en-tête de la gestion des versions (chose qui, dans
certaines organisations, exige une autorisation spéciale).

Si tu travailles avec une machine puissante, qui te permet de
recompiler complètement ton gros projet en trois minutes, je suis sûr
que tu utiliseras moins ce genre d'idiome.


Je travaille actuellement sur des machines assez puissantes,
mais les temps de compilation dépassent encore largement les
trois minutes. (C'est vrai que depuis qu'on a migré sur la
nouvelle machine, le temps d'un rebuild complet a passé de trois
heures à 20 minutes.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Loïc Joly
Le #311809

La véritable avantage, c'est de ne pas avoir besoin de
récompiler plus d'une ou deux sources quand par exemple tu
ajoutes un membre privé. Et que tes clients...



Je pense que c'est là le point essentiel en terme de taille du projet.
Plus qu'en ligne de code, c'est en taille de l'équipe que le problème se
pose pour moi. A partir du moment ou une équipe est assez grosse pour
avoir la notion de client, et donc de bibliothèque, avec une
spécification d'interface pas trop mal faite, et donc une certaine
stabilité, le concept devient intéressant.

--
Loïc

Jean-Marc Bourguet
Le #311806
Fabien LE LEZ
Si tu travailles avec une machine puissante, qui te permet de recompiler
complètement ton gros projet en trois minutes, je suis sûr que tu
utiliseras moins ce genre d'idiome.


3 minutes, ça ne suffit pas pour faire l'édition de liens suivant les
librairies que j'ai en debug (en passant, quelqu'un sait pourquoi l'éditeur
de liens de GNU est tellement plus lent pour des libs en debug?).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Publicité
Poster une réponse
Anonyme