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.
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
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.
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
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
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.
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
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
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:james.kanze@gmail.com
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
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
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
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:james.kanze@gmail.com
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
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
In article , DELVA Michael wrote:
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).
In article <Xns99C5D9C8B5AD0michaelmoviestatsfr@212.27.60.39>,
DELVA Michael <michael@moviestats.fr> wrote:
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).
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
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.
On 10 Oct 2007 19:24:17 GMT, DELVA Michael <michael@moviestats.fr>:
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.
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
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.
On Thu, 11 Oct 2007 00:22:51 -0700, James Kanze
<james.kanze@gmail.com>:
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.
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
On Oct 12, 1:12 am, Fabien LE LEZ wrote:
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
On Oct 12, 1:12 am, Fabien LE LEZ <grams...@gramster.com> wrote:
On Thu, 11 Oct 2007 00:22:51 -0700, James Kanze
<james.ka...@gmail.com>:
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:james.kanze@gmail.com
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
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
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
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.
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
Fabien LE LEZ writes:
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
Fabien LE LEZ <gramster@gramster.com> writes:
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
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
