La rigueur est souvent un gain de temps.
Je ne m'interdis pas le debuggeur, il est simplement tres souvent
inutile.
La rigueur est souvent un gain de temps.
Je ne m'interdis pas le debuggeur, il est simplement tres souvent
inutile.
La rigueur est souvent un gain de temps.
Je ne m'interdis pas le debuggeur, il est simplement tres souvent
inutile.
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.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wksm79d5qi.fsf_-_@fgeorges.org>, 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.
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.
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.
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.
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.
A ma décharge : à l'époque utiliser, un traitement de texte, en tant
qu'éditeur de sources n'avait rien de choquant.
A ma décharge : à l'époque utiliser, un traitement de texte, en tant
qu'éditeur de sources n'avait rien de choquant.
A ma décharge : à l'époque utiliser, un traitement de texte, en tant
qu'éditeur de sources n'avait rien de choquant.
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é.
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).
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cnf31i$7lg$1@news.cict.fr>...
In article <wkfz39d0bx.fsf_-_@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
K. Ahausse wrote:
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans
le message de news:cncj0u$l3m$4@news.cict.fr...
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é.
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).
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é.
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).
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 par l'action de touche de fonctions, me semblait le paradis
du développeur.
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte cher
en temps.
Oui, 'essuyer les platres', lorsque tant de choses restent à faire,
coûte du temps, sans parler du coup au moral quand on arrive à un
constat d'echec...
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0411170214.17ce6135@posting.google.com...
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 par l'action de touche de fonctions, me semblait le paradis
du développeur.
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte cher
en temps.
Oui, 'essuyer les platres', lorsque tant de choses restent à faire,
coûte du temps, sans parler du coup au moral quand on arrive à un
constat d'echec...
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
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 par l'action de touche de fonctions, me semblait le paradis
du développeur.
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte cher
en temps.
Oui, 'essuyer les platres', lorsque tant de choses restent à faire,
coûte du temps, sans parler du coup au moral quand on arrive à un
constat d'echec...
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en
rien de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
kanze@gabi-soft.fr writes:
En ce qui concerne les autres fonctionalités, ça ne m'interesse en
rien de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en
rien de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
- 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.)
- 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.)
- 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.)
Matthieu Moy wrote in message
news:...writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en
rien de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core dans
la production. C-à-d une fois tous les six mois, environ.
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote in message
news:<vpqfz38elsl.fsf@ecrins.imag.fr>...
kanze@gabi-soft.fr writes:
En ce qui concerne les autres fonctionalités, ça ne m'interesse en
rien de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core dans
la production. C-à-d une fois tous les six mois, environ.
Matthieu Moy wrote in message
news:...writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse en
rien de pouvoir lancer le déboggueur directement depuis l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core dans
la production. C-à-d une fois tous les six mois, environ.
Pouvoir dérouler le programme dans ses recoins, évite, parfois,
d'attendre qu'un bug ait à se manifester.
Pouvoir dérouler le programme dans ses recoins, évite, parfois,
d'attendre qu'un bug ait à se manifester.
Pouvoir dérouler le programme dans ses recoins, évite, parfois,
d'attendre qu'un bug ait à se manifester.
