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.
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
-- Loïc
kanze@gabi-soft.fr wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça
signifie que les différents éléments sont prévus pour fonctionner
ensemble, et sont cohérents en terme de données de configuration, de
raccourcis clavier, de look and feel,...
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
-- Loïc
Jean-Marc Bourguet
Loïc Joly writes:
wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ? D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
En quoi n'est-ce pas le cas du shell?
-- 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
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
kanze@gabi-soft.fr wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie
que les différents éléments sont prévus pour fonctionner ensemble, et sont
cohérents en terme de données de configuration, de raccourcis clavier, de
look and feel,...
En quoi n'est-ce pas le cas du shell?
--
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
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ? D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
En quoi n'est-ce pas le cas du shell?
-- 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
drkm
Marc Boyer writes:
In article , drkm wrote:
Je ne sais pas ce que tu appelles IDE, mais la clef est d'analyser le code. Emacs fait ça plutôt pas mal, cfr <URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Mais il y a, j'ai l'impression, autant d'interprétations que d'utilisateurs. Je n'en ai moi-même pas une idée très précise, si ce n'est que ça me fait vaguement penser à VC++ ou Eclispe.
En fait, ça demande à l'éditeur de faire un brin de compilation, et c'est quand même plus facile à faire quand editeur+compilo sont fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies de GCC vers un format exploitable par Semantic.
Je n'ai jamais trouvé le temps de le faire (je n'y ai plus beaucoup d'intérêt pour l'instant, et il me manque sans doute des compétences au niveau de l'interface TREE de GCC), mais cela me semble tout à fait faisable. Il « suffit de se plonger un peu dans TREE », et de générer le fichier source Emacs Lisp ad-hoc.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais intéressant. J'avais testé la speedbar, mais celle qui est installée par défaut chez moi se vautre lamentablement (reconnaît pas les méthodes des classes, confond class et fonction...). Il semble qu'il me faille regarder plus en détail.
Il faut faire attention à ne pas télécharger les packages indépendants, qui sont d'anciennes versions, mais CEDET, qui regroupe le tout.
Mais je te donnais le lien en parlant d'analyse syntaxique. Qui est faite par Semantic, partie de CEDET, sur lequel se base ECB, l'IDE pour Emacs dont je t'ai parlé.
--drkm
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wkfz39d0bx.fsf_-_@fgeorges.org>, drkm wrote:
Je ne sais pas ce que tu appelles IDE, mais la clef est d'analyser
le code. Emacs fait ça plutôt pas mal, cfr <URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Mais il y a, j'ai l'impression, autant d'interprétations que
d'utilisateurs. Je n'en ai moi-même pas une idée très précise, si ce
n'est que ça me fait vaguement penser à VC++ ou Eclispe.
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies
de GCC vers un format exploitable par Semantic.
Je n'ai jamais trouvé le temps de le faire (je n'y ai plus beaucoup
d'intérêt pour l'instant, et il me manque sans doute des compétences
au niveau de l'interface TREE de GCC), mais cela me semble tout à fait
faisable. Il « suffit de se plonger un peu dans TREE », et de générer
le fichier source Emacs Lisp ad-hoc.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais intéressant.
J'avais testé la speedbar, mais celle qui est installée par défaut
chez moi se vautre lamentablement (reconnaît pas les méthodes des
classes, confond class et fonction...).
Il semble qu'il me faille regarder plus en détail.
Il faut faire attention à ne pas télécharger les packages
indépendants, qui sont d'anciennes versions, mais CEDET, qui regroupe
le tout.
Mais je te donnais le lien en parlant d'analyse syntaxique. Qui est
faite par Semantic, partie de CEDET, sur lequel se base ECB, l'IDE
pour Emacs dont je t'ai parlé.
Je ne sais pas ce que tu appelles IDE, mais la clef est d'analyser le code. Emacs fait ça plutôt pas mal, cfr <URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Mais il y a, j'ai l'impression, autant d'interprétations que d'utilisateurs. Je n'en ai moi-même pas une idée très précise, si ce n'est que ça me fait vaguement penser à VC++ ou Eclispe.
En fait, ça demande à l'éditeur de faire un brin de compilation, et c'est quand même plus facile à faire quand editeur+compilo sont fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies de GCC vers un format exploitable par Semantic.
Je n'ai jamais trouvé le temps de le faire (je n'y ai plus beaucoup d'intérêt pour l'instant, et il me manque sans doute des compétences au niveau de l'interface TREE de GCC), mais cela me semble tout à fait faisable. Il « suffit de se plonger un peu dans TREE », et de générer le fichier source Emacs Lisp ad-hoc.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais intéressant. J'avais testé la speedbar, mais celle qui est installée par défaut chez moi se vautre lamentablement (reconnaît pas les méthodes des classes, confond class et fonction...). Il semble qu'il me faille regarder plus en détail.
Il faut faire attention à ne pas télécharger les packages indépendants, qui sont d'anciennes versions, mais CEDET, qui regroupe le tout.
Mais je te donnais le lien en parlant d'analyse syntaxique. Qui est faite par Semantic, partie de CEDET, sur lequel se base ECB, l'IDE pour Emacs dont je t'ai parlé.
--drkm
drkm
Marc Boyer writes:
wrote:
Le minimal pour moi à ce jour serait l'intégration - édition + recherche des symboles - compilation - debug - auto-documentation (Doxygen-like) - gestion de version (CVS-like)
Sinon, autant garder emacs.
Il existe un mode pour traiter les commentaires à la Doxygen ?
Et vim et emacs font un brin de compilation, et connaît un peu de syntaxe C++. Mais ce n'est pas ce que j'entends sous IDE en soi, c'est plutôt le concepte de browser.
Qui existe également sous Emacs. Je n'ai jamais vraiment testé OO-Browser, EBrowse et ECB, mais je pense que c'est bien le but recherché. Pourvoir naviguer dans une hirérchie de classe ou les membres d'une classe donnée.
--drkm
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
kanze@gabi-soft.fr wrote:
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
Il existe un mode pour traiter les commentaires à la Doxygen ?
Et vim et emacs font un brin de compilation, et
connaît un peu de syntaxe C++. Mais ce n'est pas ce que j'entends sous
IDE en soi, c'est plutôt le concepte de browser.
Qui existe également sous Emacs. Je n'ai jamais vraiment testé
OO-Browser, EBrowse et ECB, mais je pense que c'est bien le but
recherché. Pourvoir naviguer dans une hirérchie de classe ou les
membres d'une classe donnée.
Le minimal pour moi à ce jour serait l'intégration - édition + recherche des symboles - compilation - debug - auto-documentation (Doxygen-like) - gestion de version (CVS-like)
Sinon, autant garder emacs.
Il existe un mode pour traiter les commentaires à la Doxygen ?
Et vim et emacs font un brin de compilation, et connaît un peu de syntaxe C++. Mais ce n'est pas ce que j'entends sous IDE en soi, c'est plutôt le concepte de browser.
Qui existe également sous Emacs. Je n'ai jamais vraiment testé OO-Browser, EBrowse et ECB, mais je pense que c'est bien le but recherché. Pourvoir naviguer dans une hirérchie de classe ou les membres d'une classe donnée.
--drkm
Loïc Joly
Jean-Marc Bourguet wrote:
Loïc Joly writes:
wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ? D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
En quoi n'est-ce pas le cas du shell?
En ce que les différents outils que l'on a besoin d'appeler à partir du shell pour développer ont été conçus pas des équipes différentes qui n'avaient pas forcément comme objectif d'être cohérents avec les autres outils (voire même qui n'imaginaient même pas que ces autres outils puissent exister).
-- Loïc
Jean-Marc Bourguet wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
kanze@gabi-soft.fr wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie
que les différents éléments sont prévus pour fonctionner ensemble, et sont
cohérents en terme de données de configuration, de raccourcis clavier, de
look and feel,...
En quoi n'est-ce pas le cas du shell?
En ce que les différents outils que l'on a besoin d'appeler à partir du
shell pour développer ont été conçus pas des équipes différentes qui
n'avaient pas forcément comme objectif d'être cohérents avec les autres
outils (voire même qui n'imaginaient même pas que ces autres outils
puissent exister).
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ? D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
En quoi n'est-ce pas le cas du shell?
En ce que les différents outils que l'on a besoin d'appeler à partir du shell pour développer ont été conçus pas des équipes différentes qui n'avaient pas forcément comme objectif d'être cohérents avec les autres outils (voire même qui n'imaginaient même pas que ces autres outils puissent exister).
-- Loïc
drkm
Arnaud Meurgues writes:
J'ai l'impression que dans les écoles d'info, seul compte le développement au sens pissage de code, et rien n'est dit sur le test (encore moins sur l'observabilité de l'état interne).
Je confirme, au niveau de mon expérience personnelle.
J'ai l'impression que dans les
écoles d'info, seul compte le développement au sens pissage de code, et
rien n'est dit sur le test (encore moins sur l'observabilité de l'état
interne).
Je confirme, au niveau de mon expérience personnelle.
J'ai l'impression que dans les écoles d'info, seul compte le développement au sens pissage de code, et rien n'est dit sur le test (encore moins sur l'observabilité de l'état interne).
Je confirme, au niveau de mon expérience personnelle.
--drkm
Marc Boyer
In article , drkm wrote:
Marc Boyer writes:
wrote:
Le minimal pour moi à ce jour serait l'intégration - édition + recherche des symboles - compilation - debug - auto-documentation (Doxygen-like) - gestion de version (CVS-like)
Sinon, autant garder emacs.
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. Bon, ça doit pouvoir se coder, c'est vrai.
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 <wk3bz6d9wq.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
kanze@gabi-soft.fr wrote:
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
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.
Bon, ça doit pouvoir se coder, c'est vrai.
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.
Le minimal pour moi à ce jour serait l'intégration - édition + recherche des symboles - compilation - debug - auto-documentation (Doxygen-like) - gestion de version (CVS-like)
Sinon, autant garder emacs.
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. Bon, ça doit pouvoir se coder, c'est vrai.
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.
Marc Boyer
In article , drkm wrote:
Marc Boyer writes:
In article , drkm wrote:
Je ne sais pas ce que tu appelles IDE, mais la clef est d'analyser le code. Emacs fait ça plutôt pas mal, cfr <URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Mais il y a, j'ai l'impression, autant d'interprétations que d'utilisateurs. Je n'en ai moi-même pas une idée très précise, si ce n'est que ça me fait vaguement penser à VC++ ou Eclispe.
Oui, ce sont les plus connus.
En fait, ça demande à l'éditeur de faire un brin de compilation, et c'est quand même plus facile à faire quand editeur+compilo sont fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies de GCC vers un format exploitable par Semantic.
Donc, tu te fais l'intégration à la main.
Je n'ai jamais trouvé le temps de le faire (je n'y ai plus beaucoup d'intérêt pour l'instant, et il me manque sans doute des compétences au niveau de l'interface TREE de GCC), mais cela me semble tout à fait faisable. Il « suffit de se plonger un peu dans TREE », et de générer le fichier source Emacs Lisp ad-hoc.
Cf ci dessus.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais intéressant. J'avais testé la speedbar, mais celle qui est installée par défaut chez moi se vautre lamentablement (reconnaît pas les méthodes des classes, confond class et fonction...). Il semble qu'il me faille regarder plus en détail.
Il faut faire attention à ne pas télécharger les packages indépendants, qui sont d'anciennes versions, mais CEDET, qui regroupe le tout.
OK, merci de la précision.
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 <wk7joidaa5.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wkfz39d0bx.fsf_-_@fgeorges.org>, drkm wrote:
Je ne sais pas ce que tu appelles IDE, mais la clef est d'analyser
le code. Emacs fait ça plutôt pas mal, cfr <URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Mais il y a, j'ai l'impression, autant d'interprétations que
d'utilisateurs. Je n'en ai moi-même pas une idée très précise, si ce
n'est que ça me fait vaguement penser à VC++ ou Eclispe.
Oui, ce sont les plus connus.
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies
de GCC vers un format exploitable par Semantic.
Donc, tu te fais l'intégration à la main.
Je n'ai jamais trouvé le temps de le faire (je n'y ai plus beaucoup
d'intérêt pour l'instant, et il me manque sans doute des compétences
au niveau de l'interface TREE de GCC), mais cela me semble tout à fait
faisable. Il « suffit de se plonger un peu dans TREE », et de générer
le fichier source Emacs Lisp ad-hoc.
Cf ci dessus.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais intéressant.
J'avais testé la speedbar, mais celle qui est installée par défaut
chez moi se vautre lamentablement (reconnaît pas les méthodes des
classes, confond class et fonction...).
Il semble qu'il me faille regarder plus en détail.
Il faut faire attention à ne pas télécharger les packages
indépendants, qui sont d'anciennes versions, mais CEDET, qui regroupe
le tout.
OK, merci de la précision.
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.
Je ne sais pas ce que tu appelles IDE, mais la clef est d'analyser le code. Emacs fait ça plutôt pas mal, cfr <URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Mais il y a, j'ai l'impression, autant d'interprétations que d'utilisateurs. Je n'en ai moi-même pas une idée très précise, si ce n'est que ça me fait vaguement penser à VC++ ou Eclispe.
Oui, ce sont les plus connus.
En fait, ça demande à l'éditeur de faire un brin de compilation, et c'est quand même plus facile à faire quand editeur+compilo sont fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies de GCC vers un format exploitable par Semantic.
Donc, tu te fais l'intégration à la main.
Je n'ai jamais trouvé le temps de le faire (je n'y ai plus beaucoup d'intérêt pour l'instant, et il me manque sans doute des compétences au niveau de l'interface TREE de GCC), mais cela me semble tout à fait faisable. Il « suffit de se plonger un peu dans TREE », et de générer le fichier source Emacs Lisp ad-hoc.
Cf ci dessus.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais intéressant. J'avais testé la speedbar, mais celle qui est installée par défaut chez moi se vautre lamentablement (reconnaît pas les méthodes des classes, confond class et fonction...). Il semble qu'il me faille regarder plus en détail.
Il faut faire attention à ne pas télécharger les packages indépendants, qui sont d'anciennes versions, mais CEDET, qui regroupe le tout.
OK, merci de la précision.
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.
Marc Boyer
In article , drkm wrote:
Marc Boyer writes:
In article , drkm wrote:
Marc Boyer writes:
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut. C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un petit find des familles pourra bouger tout ça...
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Ce que je veux dire, c'est qu'il faut veiller à ne pas inclure les élements non template. Ou l'éditeur de lien te le rappellera.
Oui, OK.
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 <wkvfc3dmek.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wk3bz85fwa.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut.
C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des
éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un
petit find des familles pourra bouger tout ça...
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Ce que je veux dire, c'est qu'il faut veiller à ne pas inclure les
élements non template. Ou l'éditeur de lien te le rappellera.
Oui, OK.
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.
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut. C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un petit find des familles pourra bouger tout ça...
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Ce que je veux dire, c'est qu'il faut veiller à ne pas inclure les élements non template. Ou l'éditeur de lien te le rappellera.
Oui, OK.
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.
kanze
Jean-Marc Bourguet wrote in message news:...
writes:
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne peux pas faire l'édition de liens, parce qu'il en dépend d'autres modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y a une équipe d'integration.)
Meme nos tests unitaires sont fait dans le cadre de l'application (du moins au niveau ou je travaille, dans les infrastructures ce n'est pas toujours le cas) parce que justement on depend de tellement d'autres choses -- infrastructure, passes precedantes,... -- que d'ecrire des tests bench sans tout ca serait difficile. On ajoute parfois de l'instrumentation a l'application pour augmenter l'observabilite de l'etat interne et detecter des problemes plus pres de la source.
Ce que j'ai vu la plupart du temps, c'est qu'on développait aussi un charpente de test, avec une simulation de l'infrastructure, fortement instrumentée. Mais ce n'est pas universel -- ça a un coût non négligeable. (Coût qu'on récupère largement par la suite, à juger d'après ce que j'ai vu.)
J'ai aussi vu le cas où on configurer le système de gestion de versions à réfuser la libération si la module ne passait pas ses tests unitaires. Il était impossible que je puisse libérer mon travail (et donc que les autres puissent le voir) sans qu'il se compile et qu'il passe ses tests unitaires. (Et la couverture des tests unitaires était, évidemment, sujet à révue -- en fait, on faisait la revue du code et des tests unitaires ensemble, et si la couverture n'en était pas suffisante, la module ne passait pas la revue.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<pxbzn1f347f.fsf@news.bourguet.org>...
kanze@gabi-soft.fr writes:
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu
ne peux pas faire l'édition de liens, parce qu'il en dépend
d'autres modules auquels tu n'as pas réelement accès. (C'est
pour ça qu'il y a une équipe d'integration.)
Meme nos tests unitaires sont fait dans le cadre de l'application (du
moins au niveau ou je travaille, dans les infrastructures ce n'est pas
toujours le cas) parce que justement on depend de tellement d'autres
choses -- infrastructure, passes precedantes,... -- que d'ecrire des
tests bench sans tout ca serait difficile. On ajoute parfois de
l'instrumentation a l'application pour augmenter l'observabilite de
l'etat interne et detecter des problemes plus pres de la source.
Ce que j'ai vu la plupart du temps, c'est qu'on développait aussi un
charpente de test, avec une simulation de l'infrastructure, fortement
instrumentée. Mais ce n'est pas universel -- ça a un coût non
négligeable. (Coût qu'on récupère largement par la suite, à juger
d'après ce que j'ai vu.)
J'ai aussi vu le cas où on configurer le système de gestion de versions
à réfuser la libération si la module ne passait pas ses tests unitaires.
Il était impossible que je puisse libérer mon travail (et donc que les
autres puissent le voir) sans qu'il se compile et qu'il passe ses tests
unitaires. (Et la couverture des tests unitaires était, évidemment,
sujet à révue -- en fait, on faisait la revue du code et des tests
unitaires ensemble, et si la couverture n'en était pas suffisante, la
module ne passait pas la revue.)
--
James Kanze GABI Software http://www.gabi-soft.fr
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
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne peux pas faire l'édition de liens, parce qu'il en dépend d'autres modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y a une équipe d'integration.)
Meme nos tests unitaires sont fait dans le cadre de l'application (du moins au niveau ou je travaille, dans les infrastructures ce n'est pas toujours le cas) parce que justement on depend de tellement d'autres choses -- infrastructure, passes precedantes,... -- que d'ecrire des tests bench sans tout ca serait difficile. On ajoute parfois de l'instrumentation a l'application pour augmenter l'observabilite de l'etat interne et detecter des problemes plus pres de la source.
Ce que j'ai vu la plupart du temps, c'est qu'on développait aussi un charpente de test, avec une simulation de l'infrastructure, fortement instrumentée. Mais ce n'est pas universel -- ça a un coût non négligeable. (Coût qu'on récupère largement par la suite, à juger d'après ce que j'ai vu.)
J'ai aussi vu le cas où on configurer le système de gestion de versions à réfuser la libération si la module ne passait pas ses tests unitaires. Il était impossible que je puisse libérer mon travail (et donc que les autres puissent le voir) sans qu'il se compile et qu'il passe ses tests unitaires. (Et la couverture des tests unitaires était, évidemment, sujet à révue -- en fait, on faisait la revue du code et des tests unitaires ensemble, et si la couverture n'en était pas suffisante, la module ne passait pas la revue.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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
