alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
mais c'est lourd.
Vous faites comment vous ? Un super éditeur/IDE qui cache tout le sucre ?
Et sinon, pourquoi les classes (enfin, mon compilo) ne permettent elle pas
de faire
class X {
void foo(); // Déclaration
...
void foo(){...}; // Implementation
}
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des diagrammes de classe, tu annotes la classe en décrivant ses membres (avec un enchaînement des ménus qui n'est peut-être pas aussi simple qu'il pourrait être), tu démandes la génération, et tu as tout ce que tu veux. Tu peux aussi définir des stéréotypes (par exemple, basés sur des modèles) qui fournissent une partie de la définition par défaut -- un stéréotype « sémantique valeur » qui pré-déclare l'opérateur d'affectation et le constructeur de copie, ou « singleton » qui pré-déclare la fonction statique instance, par exemple.
De ce côté là, j'ai testé une version d'éval de Together qui n'était pas mal du tout. Contrairement à Rose qui travaille à base de génération de code ou de rétrogénération d'UML, Together travaille sur les deux aspects simultanément, un peu comme un éditeur qui affiche à la fois le code HTML et l'équivalent Wysiwyg.
Du coup, ça permet de taper ce qui se tappe, et de dessiner ce qui se dessine.
-- Loïc
kanze@gabi-soft.fr wrote:
Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des diagrammes
de classe, tu annotes la classe en décrivant ses membres (avec un
enchaînement des ménus qui n'est peut-être pas aussi simple qu'il
pourrait être), tu démandes la génération, et tu as tout ce que tu veux.
Tu peux aussi définir des stéréotypes (par exemple, basés sur des
modèles) qui fournissent une partie de la définition par défaut -- un
stéréotype « sémantique valeur » qui pré-déclare l'opérateur
d'affectation et le constructeur de copie, ou « singleton » qui
pré-déclare la fonction statique instance, par exemple.
De ce côté là, j'ai testé une version d'éval de Together qui n'était pas
mal du tout. Contrairement à Rose qui travaille à base de génération de
code ou de rétrogénération d'UML, Together travaille sur les deux
aspects simultanément, un peu comme un éditeur qui affiche à la fois le
code HTML et l'équivalent Wysiwyg.
Du coup, ça permet de taper ce qui se tappe, et de dessiner ce qui se
dessine.
Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des diagrammes de classe, tu annotes la classe en décrivant ses membres (avec un enchaînement des ménus qui n'est peut-être pas aussi simple qu'il pourrait être), tu démandes la génération, et tu as tout ce que tu veux. Tu peux aussi définir des stéréotypes (par exemple, basés sur des modèles) qui fournissent une partie de la définition par défaut -- un stéréotype « sémantique valeur » qui pré-déclare l'opérateur d'affectation et le constructeur de copie, ou « singleton » qui pré-déclare la fonction statique instance, par exemple.
De ce côté là, j'ai testé une version d'éval de Together qui n'était pas mal du tout. Contrairement à Rose qui travaille à base de génération de code ou de rétrogénération d'UML, Together travaille sur les deux aspects simultanément, un peu comme un éditeur qui affiche à la fois le code HTML et l'équivalent Wysiwyg.
Du coup, ça permet de taper ce qui se tappe, et de dessiner ce qui se dessine.
-- Loïc
Loïc Joly
Marc Boyer wrote:
Arnaud Meurgues wrote:
Ben, faire des tests unitaires ne nécessite guère d'outils.
Heuh, ben, pour avoir les taux de couverture quand même, non ?
Bon, on peut laisser tomber ça, mais instrumenter les tests unitaires, ça demande quand même un template qui va bien, un peu de préprocesseur pour pouvoir tester que le résultat d'une fonction est égal au résultat attendu, ou que la bonne exception est bien lancée.
boost::test correspond assez au niveau minimum que tu décris.
-- Loïc
Marc Boyer wrote:
Arnaud Meurgues wrote:
Ben, faire des tests unitaires ne nécessite guère d'outils.
Heuh, ben, pour avoir les taux de couverture quand même, non ?
Bon, on peut laisser tomber ça, mais instrumenter les tests
unitaires, ça demande quand même un template qui va bien,
un peu de préprocesseur pour pouvoir tester que le résultat
d'une fonction est égal au résultat attendu, ou que la bonne
exception est bien lancée.
boost::test correspond assez au niveau minimum que tu décris.
Ben, faire des tests unitaires ne nécessite guère d'outils.
Heuh, ben, pour avoir les taux de couverture quand même, non ?
Bon, on peut laisser tomber ça, mais instrumenter les tests unitaires, ça demande quand même un template qui va bien, un peu de préprocesseur pour pouvoir tester que le résultat d'une fonction est égal au résultat attendu, ou que la bonne exception est bien lancée.
boost::test correspond assez au niveau minimum que tu décris.
-- Loïc
Matthieu Moy
drkm writes:
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le coût, sur un projet 100% logiciel, c'est la main d'oeuvre totale.
Le temps de développement, c'est la main d'oeuvre totale divisée par le nombre de personnes qui peuvent travailler en même temps. Pour réduire le temps de développement, il faut avoir un cycle de développement qui permette la parallélisation des tâches.
Selon les domaines, le temps de développement peut être plus ou moins important que le cout total.
-- Matthieu
drkm <usenet.fclcxx@fgeorges.org> writes:
C'est en effet principalement comme cela que je l'ai compris. Quels
pourraient être les autres coûts significatifs, sur un projet d'un
certaine empleur ?
Le coût, sur un projet 100% logiciel, c'est la main d'oeuvre totale.
Le temps de développement, c'est la main d'oeuvre totale divisée par
le nombre de personnes qui peuvent travailler en même temps. Pour
réduire le temps de développement, il faut avoir un cycle de
développement qui permette la parallélisation des tâches.
Selon les domaines, le temps de développement peut être plus ou moins
important que le cout total.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le coût, sur un projet 100% logiciel, c'est la main d'oeuvre totale.
Le temps de développement, c'est la main d'oeuvre totale divisée par le nombre de personnes qui peuvent travailler en même temps. Pour réduire le temps de développement, il faut avoir un cycle de développement qui permette la parallélisation des tâches.
Selon les domaines, le temps de développement peut être plus ou moins important que le cout total.
-- Matthieu
Matthieu Moy
drkm writes:
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Je crains de ne toujours pas comprendre ...
En passant, j'ai l'impression que ton find est un peu bancal.
Mouais, à mon avis, il a pas été testé le find ;-) Ca devrait plutôt ressembler à ça :
Il existe un mode pour traiter les commentaires à la Doxygen ?
Pas à ma connaissance, mais c'est pas le plus important. Ce qui gène le plus à mon gout, c'est le fait que quand on navigue dans la doc et qu'on clique sur la définition d'un code, on ouvre une vue du code (HTML, jolie) mais pas le code lui même avec un éditeur.
Je suppose que tu parles ici de la navigation dans la doc générée, au moyen d'un navigateur Web.
Il existe en fait un package pour Doxygen, appelé Doxymacs (sur SourceForge). Je ne l'ai jamais utilisé. Je ne sais pas s'il s'agit d'un support à l'édition de tels commentaires dans les sources, ou d'un navigateur de documentation, où une telle fonctionalité serait présente.
Un tel mode ne devrait d'ailleurs pas être très compliqué à réaliser. Au moins en transformant la sortie XML (par exemple) de Doxygen en fichier Info et en dérivant le mode Info ou en y ajoutant un type de lien supplémentaire, qui ouvrirait le fichier source ad-hoc, en se positionnant au bon endroit.
Bon, ça doit pouvoir se coder, c'est vrai.
Comme beaucoup de choses. Mais comme beaucoup de choses, si ça n'existe pas déjà, cela représente un investissement de le faire soi-même ;-).
--drkm
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wk3bz6d9wq.fsf@fgeorges.org>, drkm wrote:
Il existe un mode pour traiter les commentaires à la Doxygen ?
Pas à ma connaissance, mais c'est pas le plus important.
Ce qui gène le plus à mon gout, c'est le fait que quand on navigue
dans la doc et qu'on clique sur la définition d'un code, on
ouvre une vue du code (HTML, jolie) mais pas le code
lui même avec un éditeur.
Je suppose que tu parles ici de la navigation dans la doc générée,
au moyen d'un navigateur Web.
Il existe en fait un package pour Doxygen, appelé Doxymacs (sur
SourceForge). Je ne l'ai jamais utilisé. Je ne sais pas s'il s'agit
d'un support à l'édition de tels commentaires dans les sources, ou
d'un navigateur de documentation, où une telle fonctionalité serait
présente.
Un tel mode ne devrait d'ailleurs pas être très compliqué à
réaliser. Au moins en transformant la sortie XML (par exemple) de
Doxygen en fichier Info et en dérivant le mode Info ou en y ajoutant
un type de lien supplémentaire, qui ouvrirait le fichier source
ad-hoc, en se positionnant au bon endroit.
Bon, ça doit pouvoir se coder, c'est vrai.
Comme beaucoup de choses. Mais comme beaucoup de choses, si ça
n'existe pas déjà, cela représente un investissement de le faire
soi-même ;-).
Il existe un mode pour traiter les commentaires à la Doxygen ?
Pas à ma connaissance, mais c'est pas le plus important. Ce qui gène le plus à mon gout, c'est le fait que quand on navigue dans la doc et qu'on clique sur la définition d'un code, on ouvre une vue du code (HTML, jolie) mais pas le code lui même avec un éditeur.
Je suppose que tu parles ici de la navigation dans la doc générée, au moyen d'un navigateur Web.
Il existe en fait un package pour Doxygen, appelé Doxymacs (sur SourceForge). Je ne l'ai jamais utilisé. Je ne sais pas s'il s'agit d'un support à l'édition de tels commentaires dans les sources, ou d'un navigateur de documentation, où une telle fonctionalité serait présente.
Un tel mode ne devrait d'ailleurs pas être très compliqué à réaliser. Au moins en transformant la sortie XML (par exemple) de Doxygen en fichier Info et en dérivant le mode Info ou en y ajoutant un type de lien supplémentaire, qui ouvrirait le fichier source ad-hoc, en se positionnant au bon endroit.
Bon, ça doit pouvoir se coder, c'est vrai.
Comme beaucoup de choses. Mais comme beaucoup de choses, si ça n'existe pas déjà, cela représente un investissement de le faire soi-même ;-).
--drkm
drkm
Matthieu Moy writes:
drkm writes:
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le coût, sur un projet 100% logiciel, c'est la main d'oeuvre totale.
Le temps de développement, c'est la main d'oeuvre totale divisée par le nombre de personnes qui peuvent travailler en même temps.
Oui. Je prenais ici le le temps total passé à développer, en additionant le temps que chaque développeur a passé sur le code. Pas le nombre de jours entre le début et la fin du projet. Donc plutôt la somme de travail passée à développer.
C'est en effet principalement comme cela que je l'ai compris. Quels
pourraient être les autres coûts significatifs, sur un projet d'un
certaine empleur ?
Le coût, sur un projet 100% logiciel, c'est la main d'oeuvre totale.
Le temps de développement, c'est la main d'oeuvre totale divisée par
le nombre de personnes qui peuvent travailler en même temps.
Oui. Je prenais ici le le temps total passé à développer, en
additionant le temps que chaque développeur a passé sur le code. Pas
le nombre de jours entre le début et la fin du projet. Donc plutôt la
somme de travail passée à développer.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le coût, sur un projet 100% logiciel, c'est la main d'oeuvre totale.
Le temps de développement, c'est la main d'oeuvre totale divisée par le nombre de personnes qui peuvent travailler en même temps.
Oui. Je prenais ici le le temps total passé à développer, en additionant le temps que chaque développeur a passé sur le code. Pas le nombre de jours entre le début et la fin du projet. Donc plutôt la somme de travail passée à développer.
--drkm
drkm
Jean-Marc Bourguet writes:
drkm writes:
Arnaud Meurgues writes:
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le nombre de personnes, plus il y a du monde, en théorie plus on va vite.
Oui. J'avais pris le temps total de développement, cfr. ma réponse à Matthieu.
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels
pourraient être les autres coûts significatifs, sur un projet d'un
certaine empleur ?
Le nombre de personnes, plus il y a du monde, en théorie
plus on va vite.
Oui. J'avais pris le temps total de développement, cfr. ma réponse
à Matthieu.
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le nombre de personnes, plus il y a du monde, en théorie plus on va vite.
Oui. J'avais pris le temps total de développement, cfr. ma réponse à Matthieu.
--drkm
James Kanze
Loïc Joly writes:
|> wrote:
|> > Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des |> > diagrammes de classe, tu annotes la classe en décrivant ses |> > membres (avec un enchaînement des ménus qui n'est peut-être pas |> > aussi simple qu'il pourrait être), tu démandes la génération, et |> > tu as tout ce que tu veux. Tu peux aussi définir des stéréotypes |> > (par exemple, basés sur des modèles) qui fournissent une partie de |> > la définition par défaut -- un stéréotype « sémantique valeur » |> > qui pré-déclare l'opérateur d'affectation et le constructeur de |> > copie, ou « singleton » qui pré-déclare la fonction statique |> > instance, par exemple.
|> De ce côté là, j'ai testé une version d'éval de Together qui n'était |> pas mal du tout. Contrairement à Rose qui travaille à base de |> génération de code ou de rétrogénération d'UML, Together travaille |> sur les deux aspects simultanément, un peu comme un éditeur qui |> affiche à la fois le code HTML et l'équivalent Wysiwyg.
|> Du coup, ça permet de taper ce qui se tappe, et de dessiner ce qui |> se dessine.
Je viens de suivre une formation Together, et j'étais assez bien impressionné dans l'ensemble aussi. Le problème principal que j'ai vu, c'est que les développeurs ont l'air de « penser Java », et que OO = Java. Du coup, certains idiomes que j'utilise regulièrement lui posaient des problèmes. (C'est difficile sinon impossible à lui faire générer des fonctions virtuelles privées, par exemple.) Enfin, c'est ce qu'il m'a semblé. Mais c'est peut-être seulement une déformation du formateur.
Note que tous les outils de ce genre ont leurs faiblesses. Par exemple, Ni Rose ni Together ne permet la génération des fonctions libres, autant que je sache.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
|> kanze@gabi-soft.fr wrote:
|> > Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des
|> > diagrammes de classe, tu annotes la classe en décrivant ses
|> > membres (avec un enchaînement des ménus qui n'est peut-être pas
|> > aussi simple qu'il pourrait être), tu démandes la génération, et
|> > tu as tout ce que tu veux. Tu peux aussi définir des stéréotypes
|> > (par exemple, basés sur des modèles) qui fournissent une partie de
|> > la définition par défaut -- un stéréotype « sémantique valeur »
|> > qui pré-déclare l'opérateur d'affectation et le constructeur de
|> > copie, ou « singleton » qui pré-déclare la fonction statique
|> > instance, par exemple.
|> De ce côté là, j'ai testé une version d'éval de Together qui n'était
|> pas mal du tout. Contrairement à Rose qui travaille à base de
|> génération de code ou de rétrogénération d'UML, Together travaille
|> sur les deux aspects simultanément, un peu comme un éditeur qui
|> affiche à la fois le code HTML et l'équivalent Wysiwyg.
|> Du coup, ça permet de taper ce qui se tappe, et de dessiner ce qui
|> se dessine.
Je viens de suivre une formation Together, et j'étais assez bien
impressionné dans l'ensemble aussi. Le problème principal que j'ai vu,
c'est que les développeurs ont l'air de « penser Java », et que OO = Java. Du coup, certains idiomes que j'utilise regulièrement lui posaient
des problèmes. (C'est difficile sinon impossible à lui faire générer des
fonctions virtuelles privées, par exemple.) Enfin, c'est ce qu'il m'a
semblé. Mais c'est peut-être seulement une déformation du formateur.
Note que tous les outils de ce genre ont leurs faiblesses. Par exemple,
Ni Rose ni Together ne permet la génération des fonctions libres, autant
que je sache.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des |> > diagrammes de classe, tu annotes la classe en décrivant ses |> > membres (avec un enchaînement des ménus qui n'est peut-être pas |> > aussi simple qu'il pourrait être), tu démandes la génération, et |> > tu as tout ce que tu veux. Tu peux aussi définir des stéréotypes |> > (par exemple, basés sur des modèles) qui fournissent une partie de |> > la définition par défaut -- un stéréotype « sémantique valeur » |> > qui pré-déclare l'opérateur d'affectation et le constructeur de |> > copie, ou « singleton » qui pré-déclare la fonction statique |> > instance, par exemple.
|> De ce côté là, j'ai testé une version d'éval de Together qui n'était |> pas mal du tout. Contrairement à Rose qui travaille à base de |> génération de code ou de rétrogénération d'UML, Together travaille |> sur les deux aspects simultanément, un peu comme un éditeur qui |> affiche à la fois le code HTML et l'équivalent Wysiwyg.
|> Du coup, ça permet de taper ce qui se tappe, et de dessiner ce qui |> se dessine.
Je viens de suivre une formation Together, et j'étais assez bien impressionné dans l'ensemble aussi. Le problème principal que j'ai vu, c'est que les développeurs ont l'air de « penser Java », et que OO = Java. Du coup, certains idiomes que j'utilise regulièrement lui posaient des problèmes. (C'est difficile sinon impossible à lui faire générer des fonctions virtuelles privées, par exemple.) Enfin, c'est ce qu'il m'a semblé. Mais c'est peut-être seulement une déformation du formateur.
Note que tous les outils de ce genre ont leurs faiblesses. Par exemple, Ni Rose ni Together ne permet la génération des fonctions libres, autant que je sache.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Arnaud Meurgues writes:
|> Jean-Marc Bourguet wrote:
|> > Le seul gain de temps que je vois n'est pas a etat equivalent.
|> C'est le sens de ma question. James dit que produire du code de |> qualité (sans bug ou avec moins de bug) n'est "pas plus cher".
|> Si le "pas plus cher" implique "pas plus long", alors ça |> m'intéresse.
Mais la question, pas plus long de quoi reste.
Typiquement, un « projet » dure un certain temps. Et ne s'arrête pas après le premier deployement -- il faut le maintenir. De ce point de vue, faire bien fait bien faire plus long ; un produit robuste et maintenable a une durée de vie bien supérieur à un produit baclé.
Si tu parles simplement de sortir quelque chose, n'importe quoi... J'ai déjà vu le cas où une boîte livrée une disquette vièrge, en prétendant par la suite qu'il a dû être effacer quelque part en transport. Et il faut dire que ça a permis une sortie un peu plus vite qu'autrement. Pour dire que sans préciser le niveau de qualité acceptable en sortie, la question n'a pas de réponse. Pour un niveau de qualité acceptable, je dirais que faire bien revient aussi à faire plus vite. Mais j'avoue qu'il y a pas mal de logiciels qui sortent avec un niveau de qualité que j'estîme pas acceptable.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Le seul gain de temps que je vois n'est pas a etat equivalent.
|> C'est le sens de ma question. James dit que produire du code de
|> qualité (sans bug ou avec moins de bug) n'est "pas plus cher".
|> Si le "pas plus cher" implique "pas plus long", alors ça
|> m'intéresse.
Mais la question, pas plus long de quoi reste.
Typiquement, un « projet » dure un certain temps. Et ne s'arrête pas
après le premier deployement -- il faut le maintenir. De ce point de
vue, faire bien fait bien faire plus long ; un produit robuste et
maintenable a une durée de vie bien supérieur à un produit baclé.
Si tu parles simplement de sortir quelque chose, n'importe quoi... J'ai
déjà vu le cas où une boîte livrée une disquette vièrge, en prétendant
par la suite qu'il a dû être effacer quelque part en transport. Et il
faut dire que ça a permis une sortie un peu plus vite qu'autrement. Pour
dire que sans préciser le niveau de qualité acceptable en sortie, la
question n'a pas de réponse. Pour un niveau de qualité acceptable, je
dirais que faire bien revient aussi à faire plus vite. Mais j'avoue
qu'il y a pas mal de logiciels qui sortent avec un niveau de qualité que
j'estîme pas acceptable.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Le seul gain de temps que je vois n'est pas a etat equivalent.
|> C'est le sens de ma question. James dit que produire du code de |> qualité (sans bug ou avec moins de bug) n'est "pas plus cher".
|> Si le "pas plus cher" implique "pas plus long", alors ça |> m'intéresse.
Mais la question, pas plus long de quoi reste.
Typiquement, un « projet » dure un certain temps. Et ne s'arrête pas après le premier deployement -- il faut le maintenir. De ce point de vue, faire bien fait bien faire plus long ; un produit robuste et maintenable a une durée de vie bien supérieur à un produit baclé.
Si tu parles simplement de sortir quelque chose, n'importe quoi... J'ai déjà vu le cas où une boîte livrée une disquette vièrge, en prétendant par la suite qu'il a dû être effacer quelque part en transport. Et il faut dire que ça a permis une sortie un peu plus vite qu'autrement. Pour dire que sans préciser le niveau de qualité acceptable en sortie, la question n'a pas de réponse. Pour un niveau de qualité acceptable, je dirais que faire bien revient aussi à faire plus vite. Mais j'avoue qu'il y a pas mal de logiciels qui sortent avec un niveau de qualité que j'estîme pas acceptable.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Marc Boyer
In article , drkm wrote:
Marc Boyer writes:
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Je crains de ne toujours pas comprendre ...
En passant, j'ai l'impression que ton find est un peu bancal. Je n'en suis pas un expert, mais j'ai l'impression qu'il copie dans le répertoire courant tous les *.h des sous répertoires en y /ajoutant/ l'extension .hpp. Non ?
Oui, tout à fait. C'était juste pour donner l'idée.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <wk4qjllgtq.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Je crains de ne toujours pas comprendre ...
En passant, j'ai l'impression que ton find est un peu bancal. Je
n'en suis pas un expert, mais j'ai l'impression qu'il copie dans le
répertoire courant tous les *.h des sous répertoires en y /ajoutant/
l'extension .hpp. Non ?
Oui, tout à fait. C'était juste pour donner l'idée.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
En passant, j'ai l'impression que ton find est un peu bancal. Je n'en suis pas un expert, mais j'ai l'impression qu'il copie dans le répertoire courant tous les *.h des sous répertoires en y /ajoutant/ l'extension .hpp. Non ?
Oui, tout à fait. C'était juste pour donner l'idée.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
