quel IDE pour C++

JM wrote:

J'imagine qu'il parle des fonctions membres : Si x est un
Machin, et Machin a une fonction membre foo(), l'éditeur te
proposera foo() quand tu tapes "x.f".

Oui.

D'accord. L'éditeur utilise sa connaissance du C++ pour limiter
les possibilités d'achévement. J'avoue que je doute que ça
change grand chose la plupart du temps -- les éditeurs que
j'utilise cherche d'abord dans le fichier où on est en train
d'éditer, ensuite dans le fichier visible dans l'autre panneau
(typiquement, l'en-tête avec la définition de la classe). Il
trouve donc naturellement les les noms membre d'abord.

Si après std::, en revanche, il ne considère que la bibliothèque
standard (dont les en-têtes ne se trouvent même pas chargés dans
l'éditeur), ça pourrait être intéressant. De même qu'après o.f(,
où f prend un paramètre de type std::string, il ne considère que
les variables du type std::string ou de type char const*.

Et en cas de plusieurs fonction commençant par la même lettre
par exemple, tu as une boite qui apparait et qui permet de
sélectionner la bonne fonction

Quel horreur. On n'est pas obligé à s'en servir, j'espère. Quand
je saisis du code, je ne veux surtout pas déplacer mes mains du
clavier. (Avec vim, l'achèvement est activé par ^P. Si le nom
qu'il me propose ne me convient pas, un autre ^P m'en propose
un autre. Je peux ainsi cycler à travers les noms.)

--
James Kanze GABI Software
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 surtout utile quand on te file 100 mille lignes de
spaghetti, non documenté, pour trouver dans quelles modules tu
passes dans le cas qui t'intéresse.

C'est moi aussi quand je m'approprie un code que j'utilise le plus un
debuggeur.

(Mais nous sommes d'accord
que dans une boîte bien gérée, ça n'arrive jamais, n'est-ce
pas:-).)

Uniquement si on accepte le corrolaire qu'il n'existe pas de boîtes
bien gérées.

--
Loïc

Si après std::, en revanche, il ne considère que la bibliothèque
standard (dont les en-têtes ne se trouvent même pas chargés dans
l'éditeur),

C'est le cas.

ça pourrait être intéressant. De même qu'après o.f(,
où f prend un paramètre de type std::string, il ne considère que
les variables du type std::string ou de type char const*.

Je ne connais pas d'assistant qui fasse ça.

Et en cas de plusieurs fonction commençant par la même lettre
par exemple, tu as une boite qui apparait et qui permet de
sélectionner la bonne fonction

Quel horreur. On n'est pas obligé à s'en servir, j'espère. Quand
je saisis du code, je ne veux surtout pas déplacer mes mains du
clavier. (Avec vim, l'achèvement est activé par ^P. Si le nom
qu'il me propose ne me convient pas, un autre ^P m'en propose
un autre. Je peux ainsi cycler à travers les noms.)

Bien sur que tu n'es obligé à rien, tu peux juste continuer de taper,
mais tu peux aussi gérer cette boîte au clavier. Par exemple, avec
les flèches pour choisir la bonne alternative, ou encore plus souvent
un simple espace ou une parenthèse ouvrante fini de taper le mot
sélectionné. Même pas besoin de faire des codes claviers à
plusieurs touches ;)

Ce qui apparaît aussi est une aide en info bulle issue des
commentaires situés à côté du la définition de ce qu'on tappe. Ca
peut être pratique.

--
Loïc

kanze :

Là, tu m'intrigues. Normalement, le nom de la fonction doit être
fonction de ce que fait la fonction. Comment Visual C++ sait ce
que va faire la fonction ? En termes de l'application ?

Je ne connais pas precisement l'algorithme, mais c'est d'apres les
dernieres fonctions utilisees, ou l'acronyme (tu tapes cw, il te suggere
CreateWindows()).
Et puis, il n'y a pas forcement des miliers de fonctions dans la portee,
donc plus tu tapes de lettres et plus la liste de suggestion se reduit.

S'il s'agit d'un nom qui est déjà présent ailleurs dans
l'éditeur, en quoi est-ce que ça diffère de l'achevement du nom,
tel qu'il existe en emacs ou en vim depuis au moins une
quinzaine d'années ?

Non ce n'est pas les noms ailleurs dans l'editeur, ce sont tous les noms
accessible dans la portee.
Et c'est beaucoup plus pousse que la completion. Par exemple, si tu
ecris un appel de fonction et que l'editeur detecte le meme nom dans les
fonctions mais avec une casse differente, il te souligne le mot (a la
maniere de word).

Pour les include, il te sort la liste des fichiers, etc.
Et les noms des variables locales en gras, les noms des bibliotheques en
italique, etc.

Là, en revanche, ça me semble intéressant. Pas toujours, mais
souvent. Je suppose qu'il est multilingue. Est-ce qu'il détecte
aussi les fautes du genre ?

Les fautes du genre de quoi ?

Oui il est multilingue, en fait il utilise les dictionnaires de
OpenOffice.org, donc 50 langues.

Mais la j'ai l'impression de faire la pub pour le produit :-)
Mieux vaut aller sur le site de l'editeur : http://www.wholetomato.com

--
John Deuf

On 10 Jan 2006 21:36:12 GMT, John Deuf <nomail@dontuseit.com>:

Est-ce qu'il détecte
aussi les fautes du genre ?

Les fautes du genre de quoi ?

Par exemple "Le chaise est cassé". Les gens dont la langue maternelle
est l'anglais (et c'est, je crois, le cas de James) ont beaucoup de
mal avec le genre (masculin/féminin) des noms.

On 10 Jan 2006 00:26:45 -0800, "kanze" <kanze@gabi-soft.fr>:

L'instrumentation (les sorties vers
le log) doit suffire -- en fin de compte, si le problème se
présente chez l'utilisateur, c'est tout ce que tu vas avoir.

J'utilise pas mal de débogueur quand je ne sais pas exactement ce que
mon programme fait. Typiquement, c'est parce que je découvre une
technologie (ou un nouveau pattern C++), que j'utilise une
bibliothèque mal documentée, etc.
C'est souvent dans des programmes de test, mais ça ne change rien à
l'utilité du débogueur.

Il est également pratique pour repérer certaines erreurs.
Par exemple, il y a une demi-heure, un pas-à-pas avec affichage de la
valeur des variable m'a permis de découvrir en un rien de temps que
j'avais écrit
(bidule ? machin : truc)= 42;
au lieu de
(bidule ? truc : machin)= 42;
Alors que ça m'aurait sans doute pris nettement plus longtemps sans
débogueur.

Dans tous les cas, c'est généralement dans les premières phases du
codage d'une fonction -- bien avant que qui que ce soit ait accès à
mon code ou à l'exécutable.

Note : je code principalement des applications GUI, et bien souvent je
ne peux pas créer de logs chez le client -- qui, de toutes façons, ne
m'enverrait sans doute pas le fichier.

Fabien LE LEZ :

Est-ce qu'il détecte
aussi les fautes du genre ?

Les fautes du genre de quoi ?

Par exemple "Le chaise est cassé". Les gens dont la langue maternelle
est l'anglais (et c'est, je crois, le cas de James) ont beaucoup de
mal avec le genre (masculin/féminin) des noms.

Ah! Les fautes DE genre...
C'est de la grammaire, je ne pense pas que ca soit corrige. Pour l'instant
ca se limite a l'orthographe.

--
John Deuf

loic.actarus.joly@numericable.fr wrote:

C'est surtout utile quand on te file 100 mille lignes de
spaghetti, non documenté, pour trouver dans quelles modules
tu passes dans le cas qui t'intéresse.

C'est moi aussi quand je m'approprie un code que j'utilise le
plus un debuggeur.

(Mais nous sommes d'accord que dans une boîte bien gérée, ça
n'arrive jamais, n'est-ce pas:-).)

Uniquement si on accepte le corrolaire qu'il n'existe pas de
boîtes bien gérées.

Mais si. J'ai déjà travaillé dans les boîtes (à plusieurs
occasions) où tous le code était bien documenté, et où je n'ai
jamais eu besoin d'un déboggueur pour comprendre ce qu'il
faisait.

--
James Kanze GABI Software
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

Fabien LE LEZ wrote:

On 10 Jan 2006 00:26:45 -0800, "kanze" <kanze@gabi-soft.fr>:

L'instrumentation (les sorties vers le log) doit suffire --
en fin de compte, si le problème se présente chez
l'utilisateur, c'est tout ce que tu vas avoir.

J'utilise pas mal de débogueur quand je ne sais pas exactement
ce que mon programme fait.

Ton programme, ou une fonction dans ton programme. Pour savoir
ce que fait ton programme, il suffit de lui donner des entrées,
et de régarder les sorties. Ça s'appelle tester, et je n'ai
jamais entendu parler de l'utilisation d'un déboggueur là.

En ce qui concerne les fonctions, je fais l'inverse. D'abord, je
définis ce que doit faire la fonction, et puis je l'écris.
L'idée de d'abord écrire la fonction, et puis de régarder sous
le déboggueur, ne me semble pas une méthodologie très
productive.

Typiquement, c'est parce que je découvre une technologie (ou
un nouveau pattern C++), que j'utilise une bibliothèque mal
documentée, etc.

J'ai bien dit aussi que quand il s'agissait du code écrit par
les autres, et mal documenté...

C'est souvent dans des programmes de test, mais ça ne change
rien à l'utilité du débogueur.

Et j'ai aussi dit que dans les petits programmes de test...

Je n'ai pas dit qu'il est d'une utilité zéro. Mais je l'utilise
pas dans le développement du code, où son integration dans ou
avec un éditeur pourrait m'apporter quelque chose.

Il est également pratique pour repérer certaines erreurs. Par
exemple, il y a une demi-heure, un pas-à-pas avec affichage de
la valeur des variable m'a permis de découvrir en un rien de
temps que j'avais écrit
(bidule ? machin : truc)= 42;
au lieu de
(bidule ? truc : machin)= 42;
Alors que ça m'aurait sans doute pris nettement plus longtemps
sans débogueur.

Ah, bon ? Je ne connais pas la contexte, mais en général, quand
les sorties sont l'inverse de ce qu'elles doivent être, ou quand
on traite une condition d'erreur comme étant correcte, et vice
versa, on sait qu'il faut régarde le conditionnel qui teste
cette condition. Je n'ai pas besoin d'un déboggueur pour ça.

Dans tous les cas, c'est généralement dans les premières
phases du codage d'une fonction -- bien avant que qui que ce
soit ait accès à mon code ou à l'exécutable.

Note : je code principalement des applications GUI, et bien
souvent je ne peux pas créer de logs chez le client -- qui, de
toutes façons, ne m'enverrait sans doute pas le fichier.

C'est pour ça que j'ai bien dit : « Mais je crois que tu
travailles dans une contexte différente que moi -- surtout, que
ton rapport avec les utilisateurs n'est peut-être pas le même. »
En toute chose, il y a une façon optimale de travailler. Et il y
a aussi bien trop souvent un tas de raisons pourquoi on ne peut
pas le faire. Des raisons parfois artificielles ou bidon (on n'a
jamais fait comme ça jusqu'ici), mais parfois aussi des raisons
bien trop réeles, qu'on ne peut pas contourner.

(Nous utilisons des fichiers de log sur nos GUI, ici. Mais le
GUI n'a que quelques centaines d'utilisateurs, tous employés, et
tous d'une formation supérieur. C'est donc un cas un peu
spécial.)

--
James Kanze GABI Software
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

John Deuf wrote:

kanze :

[s'agissant d'une correction d'orthographe dans les
commentaires et les chaînes de caractères...]

Là, en revanche, ça me semble intéressant. Pas toujours, mais
souvent. Je suppose qu'il est multilingue. Est-ce qu'il détecte
aussi les fautes du genre ?

Les fautes du genre de quoi ?

Si, par exemple, j'écris quelque chose comme « l'appel
entrante ». En tant qu'anglophone, je constate que les erreurs
de genre sont fréquentes chez moi (et je sais que MS-Word les
détecte -- donc, s'ils se sont servis de la même machine de
vérification...).

Oui il est multilingue, en fait il utilise les dictionnaires
de OpenOffice.org, donc 50 langues.

Visual C++ utilise les dictionnaires de OpenOffice ? Ça
m'étonne ; Microsoft en a des bien meilleurs dans Word. (Et ce
n'est pas dans les habitudes de Microsoft d'utiliser des choses
GPL non plus.)

Mais la j'ai l'impression de faire la pub pour le produit :-)
Mieux vaut aller sur le site de l'editeur :
http://www.wholetomato.com

Aha. C'est un add-in. Avec le nom en Visual, j'ai cru que
c'était un feature de l'environement Microsoft. Alors, peut-être
un jour, on pourrait le retrouver ailleurs que sous Windows.

--
James Kanze GABI Software
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