OVH Cloud OVH Cloud

Editer du C++ template avec un editeur de texte

138 réponses
Avatar
Marc Boyer
Bonjour,

une petite question sur vos pratiques d'édition.

Pour écrire la définition de code de classe template, j'aimerais
bien séparer l'interface de l'implémentation.

Mais ça devient très lourd, du genre

template <class T>
typename X<T>::iterator X<T>::first_with(typename X<T>::cond& c){
....
}

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.

10 réponses

Avatar
K. Ahausse
"Jean-Marc Bourguet" a écrit dans le message de
news:

C'est des projets de quelle taille? Mon experience est plutot pour
des grosses choses (le programme sur lequel je suis pour le moment
approche les 100 millions de lignes, est delivre sur les 11


Oui là est la différence, mes applis, en taille, sont plutot ridicules à
coté .

plateformes ci-dessus, maintenu en 6 versions -- la future, l'actuelle
et la precedante sur deux infrastructures -- par des equipes sur je ne
sais pas combien de sites) et doit se transposer assez mal aux petits


[...]

Si tu parles de LaTeX, c'est peut-etre toi qui perds quelque chose.


Non, je parlais : editeur de sources rudimentaire. 'vi' en plus médiocre (
mes excuses aux inconditionnels de 'vi')

de compiler à grands coups de batch, ou de scripts,


Jamais vu personne utiliser quelque chose de moins evolue que make.
Et j'ai rien vu de suffisemment meilleur pour valoir la peine de
changer.


En l'occurence, là, ç'a existe : compilation par des batchs ou des scripts.
Un enfer ... innommable.


de mettre au point (du moins sous windows) sans utiliser un debugger
symbolique.


En utilisant un debuggeur non symbolique ou sans utiliser de debuggeur
du tout? La seconde alternative me semble viable (c'est
principalement comme ca que je fonctionne sur mes petits projets
perso). La premiere tient du masochisme.



Et donc pour la mise au point de tes projets perso, tu utilises des logs,
une trace, des message à l'écran ?


Cela, au nom du poids de l'historique,


Ne sousestime pas le cout du changement.
Ni la puissance d'outils que tu ne maitrises pas.


Je n'ai pas tous les tenants et les aboutissants, certes, mais je ne pense
pas me tromper. Malheureusement.

Question debuggeur, j'en connais qui regrettent
encore celui qu'ils utilisaient il y a 7 ou 8 ans, et pas sans raisons
apparemment (je ne l'ai pas utilise assez).


J'avoue mon incompréhension.


Avatar
Jean-Marc Bourguet
"K. Ahausse" writes:

Si tu parles de LaTeX, c'est peut-etre toi qui perds quelque chose.


Non, je parlais : editeur de sources rudimentaire. 'vi' en plus
médiocre ( mes excuses aux inconditionnels de 'vi')


Tu parlais de traitement de texte, pas d'editeur.

En utilisant un debuggeur non symbolique ou sans utiliser de debuggeur
du tout? La seconde alternative me semble viable (c'est
principalement comme ca que je fonctionne sur mes petits projets
perso). La premiere tient du masochisme.


Et donc pour la mise au point de tes projets perso, tu utilises des
logs, une trace, des message à l'écran ?


De bons tests et les symptomes avec lequel les tests qui foirent le
font (et savoir quels tests ne foirent pas) suffit.

Cela, au nom du poids de l'historique,


Ne sousestime pas le cout du changement.
Ni la puissance d'outils que tu ne maitrises pas.


Je n'ai pas tous les tenants et les aboutissants, certes, mais je ne pense
pas me tromper. Malheureusement.

Question debuggeur, j'en connais qui regrettent
encore celui qu'ils utilisaient il y a 7 ou 8 ans, et pas sans raisons
apparemment (je ne l'ai pas utilise assez).


J'avoue mon incompréhension.


Moi pas. Ce debuggeur permettait sur un langage compile d'avoir une
technique de developpement proche de celles de langages interpretes
(declaration de variables dans le debuggeur par exemple).

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



Avatar
K. Ahausse
"Jean-Marc Bourguet" a écrit dans le message de
news:
"K. Ahausse" writes:

Si tu parles de LaTeX, c'est peut-etre toi qui perds quelque chose.


Non, je parlais : editeur de sources rudimentaire. 'vi' en plus
médiocre ( mes excuses aux inconditionnels de 'vi')


Tu parlais de traitement de texte, pas d'editeur.


Hélas, mes mots ont dépassés mes paroles :-) .
A ma décharge : à l'époque utiliser, un traitement de texte, en tant
qu'éditeur de sources n'avait rien de choquant.


En utilisant un debuggeur non symbolique ou sans utiliser de debuggeur
du tout? La seconde alternative me semble viable (c'est
principalement comme ca que je fonctionne sur mes petits projets
perso). La premiere tient du masochisme.


Et donc pour la mise au point de tes projets perso, tu utilises des
logs, une trace, des message à l'écran ?


De bons tests et les symptomes avec lequel les tests qui foirent le
font (et savoir quels tests ne foirent pas) suffit.


J'avais travaillé sur un micro-contrôleur dont l'émulateur avait été rendu
partiellement inopérant ( défaut de conception dans le hardware ). Et comme
pour toi, la mise au point se faisant sans debugger, à l'aveugle, tout dans
la tête. Le coté positif : cela oblige une rigueur dépouillée de tout
artifice.
Mais, bon, il n'y avait pas le choix. C'est un exercice que je ne ferais pas
de ma propre initiative, je suis bien content de disposer de l'assistance
d'outils récents.



Avatar
Jean-Marc Bourguet
"K. Ahausse" writes:

J'avais travaillé sur un micro-contrôleur dont l'émulateur avait été
rendu partiellement inopérant ( défaut de conception dans le
hardware ). Et comme pour toi, la mise au point se faisant sans
debugger, à l'aveugle, tout dans la tête.


J'ai travaille sur un projet avec micro-controlleur. Sans emulateur
ni simulateur; on pouvait simplement se connecter avec une liaison
RS232 sur le systeme qui comportait un moniteur (tout le boulot se
faisait dans les interruptions). C'etait amusant... Heureusement que
les choses a faire etaient simples.

Le coté positif : cela oblige une rigueur dépouillée de tout
artifice.


La rigueur est souvent un gain de temps.

Mais, bon, il n'y avait pas le choix. C'est un exercice que je ne
ferais pas de ma propre initiative, je suis bien content de disposer
de l'assistance d'outils récents.


Je ne m'interdis pas le debuggeur, il est simplement tres souvent
inutile.

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

Avatar
Jean-Marc Bourguet
Jean-Marc Bourguet writes:

Je ne m'interdis pas le debuggeur, il est simplement tres souvent
inutile.


Je complete: sur du code que je connais bien pour les problemes
detectes par les tests que j'ai ecrit pour ce code.

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

Avatar
drkm
Marc Boyer writes:

In article , drkm wrote:

Si je me souviens bien du contexte, il est question de modèles, et
tu inclus de toute façon l'implémentation dans l'en-tête. Même dans
ce cas, je te conseille de séparer (cmme tu sembles d'ailleurs le
faire) l'en-tête de l'implémentation, et d'inclure celle-ci dans
celui-là.


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.

--drkm


Avatar
drkm
[ X-Post f.c.l.c++ et f.c.a.emacs, Fu2 f.c.a.emacs ]

Marc Boyer writes:

In article , drkm wrote:

EBrowse ou ECB pourraient t'intéresser.


ebrowse: tiens, c'est installé sur ma machine. Je vais regarder ça.


Ça fait partie de la distribution standard.

ECB: c'est l'autre lien que tu m'avais donné, c'est ça ?


Oui. Enfin, je pense que je n'ai pas donné de lien. C'est sur
SourceForge : <URL:http://ecb.sf.net/>. D'après ce que j'en ai vu, le
but est de reproduire un environnement de travail comme on en trouve
dans VC++, par exemple. Avec plusieurs fenêtres comme la hiérarchie
de classes, la navigation dans les classes, la sortie de compilation,
etc.

Puisque je travaille sous la console, je n'ai jamais essayé de
l'utiliser. Je me vois mal avec une fenêtre d'édition réduite à 17 x
40 caractères ...

--drkm


Avatar
drkm
writes:

Alors, même à la fin d'un .cpp : #undef. Les macros n'ont pas de scope.
Alors, on la simule.


Au fait, quelqu'un connait l'état d'avancement de la proposition
dans ce sens ?

--drkm

Avatar
kanze
Marc Boyer wrote in message
news:<cnf31i$7lg$...
In article , drkm wrote:
Marc Boyer writes:
K. Ahausse wrote:
"Marc Boyer" a écrit dans
le message de news:cncj0u$l3m$


Ce que j'avais beaucoup apprécié sur VB, c'était la complétion
automatique en fonction du type.
Ca, seul un IDE peut le faire car cela demande une partie
de compilation en ligne.


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. 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:-).

Mais en général, on démande qu'il soit graphique aussi. Peut-être un
environement graphique d'où je peux faire tout ce que je fais sous un
shell Unix:-).

En fait, je crois qu'il y a réelemnt un peu de ça. On démande un
environement graphique d'où je peux faire toutes les tâches nécessaires
au développement des logiciels. Et voilà le hic, parce que les tâches
nécessaires au développement des logiciels dépendent de qui développe et
comment. Donc, les premiers IDE se vautaient beaucoup de la
simplification dans la cycle edit-compile-debug -- du coup, ça ne
m'intéresse pas, parce que ce n'est pas comme ça que je
développe. (C'est où, la documentation, dans ce cycle ? Et comment
prend-il en compte la gestion des versions, ou les révues de code ?)

En fait, je crois que les IDE moderne permettent bien l'intégration de
pas mal d'outils supplémentaires -- je sais qu'on peut intégrer
Clearcase dans Visual Studios, par exemple, et je ne serais pas étonné
d'apprendre que la même chose vaut pour Doxygen et un éditeur de
HTML. Et Rose. Le résultat pourrait être réelement utilisable, et
nettement plus facile à apprendre qu'un shell de Unix.

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.


C'est un autre aspect. 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. Si c'est vrai que la
quasi-totalité des IDE integre un browser, il est aussi possible
d'utiliser des browser non integré, comme Sniff+. Et les solutions
vim/emacs proposées sont des browser integrés à l'éditeur (or que Sniff
prend l'approche opposé, et essaie d'ingegrer l'éditeur dans un browser
externe).

Beaucoup dépend de ce que tu dois faire. J'ai trouvé Sniff extrèmement
intéressant pour comprendre du code existant mal documenté. Pour la
création du code nouveau, en revanche, je préfère quelque chose du genre
Rose -- je « browse » plutôt dans les diagrammes, jusqu'à arriver à un
niveau assez bas pour que les sources soient signifiantes.

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...).


Mon expérience avec les speedbar pour le C++ est plutôt négative. Le
problème, c'est que pour un symbole donné, il y a typiquement plusieurs
endroits intéressants dans les sources. (Il y avait aussi le problème
que les speedbars que j'ai essayé, sous emacs, ne se mettait pas à jour
automatiquement. Mais c'était typiquement un problème mineur.) Ça pose
moins un problème avec Java (je me suis servi de JDEE), mais dans tous
les cas, ça impose qu'on enlève les mains de la position de base du
clavier -- pas un problème quand on browse, mais genant et une perte de
temps quand on développe réelement (c-à-d lors qu'on écrit du code).

--
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




Avatar
Marc Boyer
Jean-Marc Bourguet wrote:
"K. Ahausse" writes:
a écrit dans le message de
news:

En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur. En


Ha! je suis surpris, edition+compilation+debug s'enchainant sur simplement


Pour un tas de raisons que je n'ai pas envie d'expliquer ici, je
prefere de loin m'attacher a un process en cours que de le lancer d'un
debuggeur.

par l'action de touche de fonctions, me semblait le paradis du
développeur.


Le paradis c'est de ne pas avoir a se servir d'un debuggeur. J'y
arrive plus ou moins bien sur du code auquel j'ai participe au
developpement depuis le debut et tant que le probleme n'est pas trop
lie a des dependances -- on utilise beaucoup de callback par exemple,
et c'est une source de problemes -- , tres mal sur du code que je
recupere (et comme c'est la plupart du temps...)


Je réalise en lisant tes interventions (pas forcément ce message
à d'ailleurs) que depuis que j'ai systématisé les tests unitaires,
les pre/pros conditions et les invariants, mon usage du debogueur
se limite souvent à faire un "backtrace" sur le core.

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.