Bug indétectable via printf() / cout
AG
Je travaille dans une équipe de personnes pour lesquels le débugger
n'est pas l'outil qui tombe sous le sens lorsqu'il s'agit de trouver
les bugs des outils qu'ils ont développé.
Afin de les sensibiliser, je recherche un exemple de bug difficile
(voir impossible) a détecter via des printf()/cout qui n'afficheraient
que les contenus des variables. (Je me rends bien compte qu'on doit
pouvoir tout débugger avec printf()/cout, mais il faut parfois
afficher les adresses des variable (en plus de leur valeur), voir
parfois la mémoire à certains endroits.)
Je voudrais construire un exemple simple (notions de C++ pas trop
compliquées) et court (un seul fichier, 100 lignes max) pour qu'on
puisse l'étudier en un quart d'heure, mais le débugger en un temps
presque infini sans débugger.
Il est possible que l'exemple, puisqu'il y a un bug, dépende de la
plateforme mais c'est un peu inévitable.
L'idéal serait que le plantage ait lieu bien après le bug...ça rajoute
du piment. Bref, vous voyez l'idée quoi...
J'avais plusieurs pistes d'exploitation de bug:
Piste 1:
Boucle for décroissante sur un entier non signé : for(size_t i = N;
0<= i; i--)
Piste 2:
comparaison de double : double x; ... ; x == 0.0
Piste 3:
retour de malloc() non testé
Piste 4:
caractère de fin de ligne non testé (\0)
Mais jusque là, je crains qu'il ne soit trop facile de détecter le
bug
J'ai donc ensuite pensé aux références. Mais ce code est encore un peu
trop voyant. Dans le main(), on peut facilement se demander pourquoi
f1 et f2 sont des références, ce qui met directement la puce à
l'oreille. Peut être trouvez vous ce code bien trop compliqué, ou
auriez vous en tête un manière de "l'améliorer" :-)
A bon entendeur salut.
AG.
#include <iostream>
using namespace std;
#define BUFFER_LENGTH 10
template<int N, class T>
class fifo_circular
{
private:
T * position;
size_t pos_offset;
T buffer[N];
public:
fifo_circular() { pos_offset = N-1; position = buffer + pos_offset;
for(int i=0;i<N;i++) buffer[i]=T(0);};
T step(T &input)
{
*position = input;
if(pos_offset>0) // ici il y aurait peut être moyen de glisser le
bug de la piste 1
pos_offset--;
else
pos_offset = N-1;
position = buffer + pos_offset;
return *position;
};
template<int M, class U> friend ostream & operator<<(ostream & o,
const fifo_circular<M,U> &f);
};
template<int N, class T>
fifo_circular<N,T> & Init(T & value)
{
fifo_circular<N,T> & f = fifo_circular<N,T>(); // hé hé hé
for(size_t i = 0; i < N; i++)
f.step(value);
return f;
}
template<int M, class U>
ostream & operator<<(ostream & o, const fifo_circular<M,U> &f)
{
for(size_t i = 0; i < M; i++)
o << f.buffer[i] << " ";
return o;
}
int main(int argc, char * argv[])
{
int a = 1;
fifo_circular<5,int> & f1 = Init<5,int>(a); // ici, c'est un peu trop
voyant. On se demande pourquoi f1 est déclaré en tant que
référence...
a = 2;
fifo_circular<5,int> & f2 = Init<5,int>(a);
cout << "fifo f1: " << f1 << "\n";
cout << "fifo f2: " << f2 << "\n";
return 0;
}
Marc Boyer
> Je travaille dans une équipe de personnes pour lesquels le débugger
> n'est pas l'outil qui tombe sous le sens lorsqu'il s'agit de trouver
> les bugs des outils qu'ils ont développé.
Mais est-ce grave ? J'avoue ne quasiment jamais me servir
de débugger. Je travaille surtout en précondition/invariant
(assert) + tests unitaires, et éventuellement valgrind
quand je soupsonne une corruption mémoire.
Et une fois le bug identifié, à grand coups de cerr
+ assert.
D'autant que souvent, le bug n'apparait pas en mode débug ;-)
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot=130
AG
wrote:
> Mais est-ce grave ? J'avoue ne quasiment jamais me servir
> de débugger. Je travaille surtout en précondition/invariant
> (assert) + tests unitaires, et éventuellement valgrind
> quand je soupsonne une corruption mémoire.
>
> Et une fois le bug identifié, à grand coups de cerr
> + assert.
>
> D'autant que souvent, le bug n'apparait pas en mode débug ;-)
Bonjour Marc,
Je pense que c'est grave effectivement. Tout ce que tu écris pour
débugger est inutile avec un débugger. C'est donc un gain de temps
immédiat.
Ensuite d'aucun diront que leur debugger (type gdb) est mal
pratique...peut être. Mais avec un débugger pratique, c'est un gain de
temps certain.
Cela dit, qu'on me le dise si les debugger ne sont pas intensivement
utilisés dans l'industrie, je serais content de me tromper. Dans mon
entourage, tout ceux à qui j'ai montré un debugger pratique l'ont
adopté.
Alexandre.
PS: tes élèves, tu ne leur apprends pas le débugger ?
Jean-Marc Bourguet
> Cela dit, qu'on me le dise si les debugger ne sont pas intensivement
> utilis�s dans l'industrie, je serais content de me tromper.
Ca depend des gens, du probleme a debugger et du domaine. En general, je
trouve que j'abandonne de debuggeur pour autre chose trop lentement plutot
que trop vite. Et plus le probleme est complexe, moins ils sont utiles.
Un systeme de log et des assertions bien concues sont plus efficaces pour
les vrais problemes compliques.
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
JKB
Re: Bug indétectable via printf() / cout,
AG ?crivait dans fr.comp.lang.c++ :
Bonjour,
Je ne programme pas en C++, tout au plus je corrige des choses parce
que j'ai une certaine phobie de la programmation objet. Néanmoins, en C
si j'utilise assez régulièrement gdb/ddd, c'est toujours après avoir
généré un core pour l'analyser. J'ai un tas de bugs sous la main qui
ne se produisent _jamais_ lorsque je lance le truc à débugguer sous
un quelconque debugger (code multithreadé, choses bizarres sur des
variables, mutexes, sémaphores...). En général, je préfère une macro()
style assert() qui me crache sur la sortie quelques informations et qui
envoie un SIGBUS pour générer un core, un peu la même technique que Marc.
Au pire, j'utilise valgrind lorsqu'il est disponible voire des
choses comme efence lorsque je suis sur une architecture non
supportée par valgrind.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Marc Boyer
> wrote:
>> Mais est-ce grave ? J'avoue ne quasiment jamais me servir
>> de débugger. Je travaille surtout en précondition/invariant
>> (assert) + tests unitaires, et éventuellement valgrind
>> quand je soupsonne une corruption mémoire.
>>
>> Et une fois le bug identifié, à grand coups de cerr
>> + assert.
>>
>> D'autant que souvent, le bug n'apparait pas en mode débug ;-)
>
> Bonjour Marc,
>
> Je pense que c'est grave effectivement. Tout ce que tu écris pour
> débugger est inutile avec un débugger. C'est donc un gain de temps
> immédiat.
Mais tout ce que tu fais avec ton débuger est non rejouable
(à moins que tu ne scriptes ton deboggeur, mais j'ai rencontré
peu de personnes qui le fassent).
En plus, les precond/invariants servent aussi de documentation,
et puis tu les écris quand tu écris la fonctions, donc tu sais ce
que ça va faire.
Et puis c'est aussi facile d'écrire
PRINT_VALUE(toto)
avec une macro du type
#define PRINT_VALUE(X) if (debug) { cerr<<#X "="<<(X)<<endl;}
que de faire click-gauche, 'suivre-variable'
Et puis les débogueurs que je connaissais ne montraient pas d'historique.
Souvent, la question c'est "pourquoi cette var vaut ça ?", et tu remontes
le temps. En affichant les variables en console, la console se souvient.
De plus, en ce qui concerne les fuites mémoires, valgrind est
bien plus efficace que de suivre pas à pas le débogueur.
> Ensuite d'aucun diront que leur debugger (type gdb) est mal
> pratique...peut être. Mais avec un débugger pratique, c'est un gain de
> temps certain.
Possible. J'utilisais le deboggeur avant, sous Win* il y a plus
de 10 ans, puis SunStudio puis ddd/gdb/xemacs, puis plus rien...
> Cela dit, qu'on me le dise si les debugger ne sont pas intensivement
> utilisés dans l'industrie, je serais content de me tromper. Dans mon
> entourage, tout ceux à qui j'ai montré un debugger pratique l'ont
> adopté.
On verra ce que disent les autres contributeurs. Je ne parle que de
mon expérience.
> PS: tes élèves, tu ne leur apprends pas le débugger ?
Je leur apprenais, oui, mais pas avec gdb/ddd, ils y perdaient trop
de temps: avancer pas à pas, saisir les entrées, faire un "run-until",
voir qu'on est allé trop loin, recommencer, re-saisir les entrées...
Non, tests unitaires / assert / printf, c'était la méthodologie.
On présentait gdb/ddd en illustration des cours sur l'allocation
dynamique, pour qu'ils "voient" leurs listes chainées.
Et quand en projet ils galéraient à rechercher un bug, et qu'ils
finissaient par m'appeller, au bord de la crise, parfois me montraient
leur problème avec gdb/ddd, mais toujours, j'allais à la pèche aux
infos à coup d'assert/printf, et, éventuellement valgrind.
Marc Boyer
>
> Je ne programme pas en C++, tout au plus je corrige des choses parce
> que j'ai une certaine phobie de la programmation objet. Néanmoins, en C
> si j'utilise assez régulièrement gdb/ddd, c'est toujours après avoir
> généré un core pour l'analyser.
Oui, j'allais oublié le pb du crash et des analyses post-mortem.
> J'ai un tas de bugs sous la main qui
> ne se produisent _jamais_ lorsque je lance le truc à débugguer sous
> un quelconque debugger (code multithreadé, choses bizarres sur des
> variables, mutexes, sémaphores...). En général, je préfère une macro()
> style assert() qui me crache sur la sortie quelques informations et qui
> envoie un SIGBUS pour générer un core, un peu la même technique que Marc.
Oui, je me souviens aussi de code multi-thread temps-réel qui se bloque,
qui ne tourne pas sous le débogueur car tout y est trop lent, et qui
ne se bloque pas quand on ajoute les printfs (surement car ça ajoutes
des commutation de contexte)...
Senhon
"AG" <hey...@gmail.com> a �crit dans le message de groupe de discussion :
abe29be0-d45b-412f...@z7g2000vbl.googlegroups.com...
> On Nov 30, 2:27 pm, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
> wrote:
>
> d�bugger est inutile avec un d�bugger. C'est donc un gain de temps
> imm�diat.
> Ensuite d'aucun diront que leur debugger (type gdb) est mal
> temps certain.
>
Un debugger est un outils indispensable.
Personnellement, je regretterai ( exp�rience d�j� v�cu ) am�rement, de ne
pas disposer d'un debugger. Cela ne m'emp�che pas d'utiliser, aussi, des
cout pour la mise au point.
Les deux se compl�mentent.
GDB, rend d'�normes services.
Mais, je n'ai rien trouv� de mieux que Visual Studio, c'est un plaisir que
de travailler avec cette merveille. GDB en comparaison fait outil d'un autre
�ge.
Marc Boyer
> trop voyant. Dans le main(), on peut facilement se demander pourquoi
> f1 et f2 sont des références, ce qui met directement la puce à
> l'oreille. Peut être trouvez vous ce code bien trop compliqué, ou
> auriez vous en tête un manière de "l'améliorer" :-)
Tellement voyant que mon g++ le voit:
error: invalid initialization of non-const reference of type ‘fifo_circular<5, int>&’ from a temporary of type ‘fifo_circular<5, int>’
Marc Espie
AG <hey...@gmail.com> wrote:
>On Nov 30, 2:27�pm, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
>wrote:
>> � Mais est-ce grave ? J'avoue ne quasiment jamais me servir
>> (assert) + tests unitaires, et �ventuellement valgrind
>> quand je soupsonne une corruption m�moire.
>>
>> � Et une fois le bug identifi�, � grand coups de cerr
>> + assert.
>>
>> � D'autant que souvent, le bug n'apparait pas en mode d�bug ;-)
>
>Bonjour Marc,
>
>Je pense que c'est grave effectivement. Tout ce que tu �cris pour
>imm�diat.
assert() est de toutes facons toujours utile, puisqu'il permet de
detecter certains problemes avant qu'ils ne deviennnet des vrais bugs.
Il y a un risque a trop utiliser un debugguer: c'est une bequille trop
pratique, parfois. On debranche le cerveau, on ecrit n'importe quoi, et
on se dit "c'est pas grave, on debugguera apres..."
mais c'est sur que c'est quand meme super-pratique comme outil.
(nota: mode debug + optimisations, bien sur, histoire d'avoir le meme
code. Si ca donne pas le meme code, le compilateur est a jeter.)
Fabien LE LEZ
>Je travaille dans une �quipe de personnes pour lesquels le d�bugger
>n'est pas l'outil qui tombe sous le sens lorsqu'il s'agit de trouver
>les bugs des outils qu'ils ont d�velopp�.
J'avoue que je partage un peu leur avis.
Le d�bugger est un outil extr�mement pratique pour comprendre d'o�
viennent certains bugs coriaces. Mais je rencontre ces bugs assez
rarement, c'est pourquoi je ne sors mon d�bugger que quelques fois
dans l'ann�e.
>Piste 3:
>retour de malloc() non test�
>
>Piste 4:
>caract�re de fin de ligne non test� (\0)
Ces deux-l� sont extr�mement rares en C++ :
- � ma connaissance, la seule utilit� de malloc() est de
permettre la cr�ation de son propre op�rateur new, ce qu'on ne fait
pas tous les jours ;
- les histoires de '\0', c'est la cuisine interne de
std::string, et a priori, ce n'est pas toi (ni moi) qui l'�cris.
>je recherche un exemple de bug difficile
>(voir impossible) a d�tecter via des printf()/cout qui n'afficheraient
>que les contenus des variables.
As-tu rencontr� un exemple dans la vraie vie ? Si oui, ressors-le,
nettoie-le un peu, et tu as ce qu'il te faut.
Si tu n'en as pas en stock, et que tu n'en trouves pas un dans les six
semaines (par exemple), c'est que le d�bugger n'est pas si
indispensable que tu le pensais ;-)
James Kanze
> On Nov 30, 2:27 pm, Marc Boyer
> <Marc.Bo...@cert.onera.fr.invalid> wrote:
> > Mais est-ce grave ? J'avoue ne quasiment jamais me servir de
> > débugger. Je travaille surtout en précondition/invariant
> > (assert) + tests unitaires, et éventuellement valgrind quand
> > je soupsonne une corruption mémoire.
> > Et une fois le bug identifié, à grand coups de cerr
> > + assert.
> > D'autant que souvent, le bug n'apparait pas en mode débug ;-)
> Je pense que c'est grave effectivement. Tout ce que tu écris
> pour débugger est inutile avec un débugger. C'est donc un gain
> de temps immédiat.
Tu vas prétendre que la spécification des préconditions et des
invariants n'est pas nécessaire ? Qu'on peut se passer des tests
unitaires ?
Je n'aimerais pas à avoir à maintenir du code que tu as écrit.
Ni de m'en servir.
> Ensuite d'aucun diront que leur debugger (type gdb) est mal
> pratique...peut être. Mais avec un débugger pratique, c'est un
> gain de temps certain.
Dans certains cas où le code a été mal écrit, sans
spécifications des interfaces et sans documentation, c'est une
aide à la compréhense. Mais la nécessité d'utiliser un
déboggueur est toujours une reconnaissance que le code a été
écrit sans respecter les règles les plus simple de qualité. Et
que le code coûte beaucoup plus cher que s'il avait été écrit
correctement au départ.
> Cela dit, qu'on me le dise si les debugger ne sont pas
> intensivement utilisés dans l'industrie, je serais content de
> me tromper. Dans mon entourage, tout ceux à qui j'ai montré un
> debugger pratique l'ont adopté.
> PS: tes élèves, tu ne leur apprends pas le débugger ?
Aux élèves, il faudrait plutôt l'interdire. Il vaut mieux leur
apprendre d'écrire du code correctement, pourqu'ils n'en ont pas
besoin d'un déboggueur.
--
James Kanze
AG
> Ces deux-là sont extrêmement rares en C++ :
> - à ma connaissance, la seule utilité de malloc() est de
> permettre la création de son propre opérateur new, ce qu'on ne fait
> pas tous les jours ;
> - les histoires de '\0', c'est la cuisine interne de
> std::string, et a priori, ce n'est pas toi (ni moi) qui l'écris.
Oui, tu auras deviné que j'avais le C en tête lorsque j'ai écrit
cela...
> As-tu rencontré un exemple dans la vraie vie ?
ça m'est arrivé de mettre plusieurs jours à trouver un bug dans du
code que je n'ai pas écrit. Et lorsque le code fait 40k lignes, je ne
vais pas me lancer dans les tests unitaires. Et je pense que cette
situation est fréquente.
Je suis tout à fait d'accord que la méthodologie c'est tests
unitaires et compagnie, bonne parole prodiguée. Je suis aussi
d'accord que pour détecter tous les problèmes de deadlock et de
synchro, c'est pas l'idéal (mais là on s'éloigne du C++...). Et je
suis aussi d'accord que Valgrind aide beaucoup. Mais je ne négligerais
pas le débugger pour autant.
Pour moi gdb/ddd ne sont pas pratiques. Celui de Visual Studio l'est.
Dommage que le thread ait été dévié du sujet initial. j'aurais pensé
qu'il amuserait plus que ça. Je vous posterai ma trouvaille.
AG.
James Kanze
wrote:
> Le 30-11-2009, AG <hey...@gmail.com> a écrit :
[...]
> Possible. J'utilisais le deboggeur avant, sous Win* il y a
> plus de 10 ans, puis SunStudio puis ddd/gdb/xemacs, puis plus
> rien...
Je travaille actuellement avec Visual Studios 8 ; il offre bien
moins de possibilités que gdb (ou au moins, je ne les ai pas
trouvé).
[...]
> Non, tests unitaires / assert / printf, c'était la méthodologie.
À règle générale, dans des boîtes bien organisées, il est
interdit d'utiliser le deboggeur tant qu'on n'a pas de test
unitaire qui montre le problème. On ne veut pas qu'il
reapparaissent dans une version future, et on veut être sûr que
les tests unitaires le détectent. Et la plupart du temps, une
fois qu'on a isolé le problème assez pour définir un test
unitaire qui le declenche, on l'a isolé assez pour pouvoir
savoir exactement ce qui ne va pas d'après les symptomes.
> On présentait gdb/ddd en illustration des cours sur
> l'allocation dynamique, pour qu'ils "voient" leurs listes
> chainées.
> Et quand en projet ils galéraient à rechercher un bug, et
> qu'ils finissaient par m'appeller, au bord de la crise,
> parfois me montraient leur problème avec gdb/ddd, mais
> toujours, j'allais à la pèche aux infos à coup
> d'assert/printf, et, éventuellement valgrind.
Je ne suis pas sûr d'être d'accord avec l'utilisation du printf,
mais en général, il faut dire que si tu as besoin d'une
information une fois, tu en aurais besoin une autre fois, et
qu'il faut alors y introduire un log ou un trace. (Mais ça ne
vaut que pour les programmes « industriels » ; je vois mal un
élève, même à l'univerité, se servir extensivement des logs.)
--
James Kanze
James Kanze
> "AG" <hey...@gmail.com> a écrit dans le message de groupe de discussion :
> abe29be0-d45b-412f-a23c-88870abaf...@z7g2000vbl.googlegroups.com...
> > On Nov 30, 2:27 pm, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
> > wrote:
> > Je pense que c'est grave effectivement. Tout ce que tu écris
> > pour débugger est inutile avec un débugger. C'est donc un
> > gain de temps immédiat. Ensuite d'aucun diront que leur
> > debugger (type gdb) est mal pratique...peut être. Mais avec
> > un débugger pratique, c'est un gain de temps certain.
> Un debugger est un outils indispensable.
Pas tant que ça. Pour des poste-mortem, oui. Ou pour le code mal
écrit que tu hérites d'ailleurs. Où parfois dans des contextes
bien précis où tu ne peux pas utiliser des logs. Mais en
général, si la boîte est bien organisée, le déboggueur ser assez
peu.
> Personnellement, je regretterai ( expérience déjà vécu )
> amèrement, de ne pas disposer d'un debugger. Cela ne m'empêche
> pas d'utiliser, aussi, des cout pour la mise au point. Les
> deux se complémentent.
>
> GDB, rend d'énormes services.
> Mais, je n'ai rien trouvé de mieux que Visual Studio, c'est un
> plaisir que de travailler avec cette merveille. GDB en
> comparaison fait outil d'un autre âge.
Là, c'est de l'ironie, n'est-ce pas ? Parce que je me sers
actuellement de Visual Studio (pour comprendre du code que je
n'ai pas écrit, et pour lequel il n'y a aucune documentation),
et je me heurte constamment à ses limitations.
--
James Kanze
AG
> Tu vas prétendre que la spécification des préconditions et des
> invariants n'est pas nécessaire ? Qu'on peut se passer des tests
> unitaires ?
Non bien sûr, mais à l'inverse vas-tu prétendre qu'on est à l'abri de
tout avec les tests unitaires ? Non bien évidemment. Si on débugge
sans débuggeur, c'est forcément que les tests unitaires ont loupé
quelque chose. Arrivé à ce stade, n'est-ce pas une perte de temps de
re-écrire plein de code de débug, pour finalement compléter les tests
unitaires qu'avec un cas supplémentaire ?
> Aux élèves, il faudrait plutôt l'interdire. Il vaut mieux leur
> apprendre d'écrire du code correctement, pourqu'ils n'en ont pas
> besoin d'un déboggueur.
Ok, je prends bonne note, mais suis très surpris. C'était pas du tout
mon avis, et je tombe des nues.
Marc Espie
James Kanze <james...@gmail.com> wrote:
>Aux �l�ves, il faudrait plut�t l'interdire. Il vaut mieux leur
>apprendre d'�crire du code correctement, pourqu'ils n'en ont pas
>besoin d'un d�boggueur.
Avec ma population actuelle d'etudiants, je leur montre un debugger.
Il faut voir qu'ils n'ecrivent pas forcement du code correct, mais qu'ils
debugguent a grands coups de printf. Alors, quitte a debugguer, autant
que ca soit efficace...
Fabien LE LEZ
>Oui, tu auras devin� que j'avais le C en t�te lorsque j'ai �crit
>cela...
Justement, le C et le C++ sont tr�s diff�rents. Il me semble donc
qu'il y aura d'importantes diff�rences dans l'utilit� d'un d�bogueur
ou un d�tecteur de fuites m�moire.
>> As-tu rencontr� un exemple dans la vraie vie ?
>�a m'est arriv� de mettre plusieurs jours � trouver un bug dans du
>code que je n'ai pas �crit.
Je pense que tu as mis le doigt sur un point important : il y a pas
mal d'outils qui servent presque exclusivement sur le code des autres.
>Celui de Visual Studio l'est.
Oui. Dommage qu'il faille subir, pour l'utiliser, le reste de l'IDE.
C'est d'ailleurs en partie pour �a que j'utilise peu le d�bogueur :
d�marrer le d�bogueur me force � lancer l'IDE et � y cr�er un projet,
t�che d�sagr�able � laquelle je ne me r�soud que si je ne trouve pas
d'autre solution.
Fabien LE LEZ
Espie):
>Avec ma population actuelle d'etudiants, je leur montre un debugger.
>Il faut voir qu'ils n'ecrivent pas forcement du code correct, mais qu'ils
>debugguent a grands coups de printf. Alors, quitte a debugguer, autant
>que ca soit efficace...
Tu leur as d�j� conseill� de s'orienter vers une autre voie, ou tu
attends un peu ?
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
38e5cab6-ae8e-42fd...@e22g2000vbm.googlegroups.com...
> On Nov 30, 2:28 pm, "Senhon" <N...@Nul.Nul> wrote:
>> abe29be0-d45b-412f-a23c-88870abaf...@z7g2000vbl.googlegroups.com...
>
>>
>> GDB, rend d'�normes services.
>> Mais, je n'ai rien trouv� de mieux que Visual Studio, c'est un
>> plaisir que de travailler avec cette merveille. GDB en
>
> L�, c'est de l'ironie, n'est-ce pas ? Parce que je me sers
> actuellement de Visual Studio (pour comprendre du code que je
> et je me heurte constamment � ses limitations.
Pas du tout, mais alors, loin de l�.
Rien que l'usage de la touche F12, fonctionnalit� que je n'ai rencontr�
nulle part ailleurs, vaut le d�tour.
Bon c'est s�r que dans ton cas, c'est pas ton prog, peut-�tre pas ton OS de
pr�dilection, c'est pas ton outils de debug habituel, lorsque l'on est
habitu� � une interface utilisateur, cela g�ne pour passer � une autre : et
l'occurrence, entre GDB (commande ligne) et VisualStudio (graphique),
l'�cart est d�j� conceptuel.
Quelles sont ces limitations que tu rencontre ?
Michael Doubez
> On Nov 30, 1:43 pm, AG <hey...@gmail.com> wrote:
> > Cela dit, qu'on me le dise si les debugger ne sont pas
> > intensivement utilisés dans l'industrie, je serais content de
> > me tromper.
Intensément, je n'ai pas l'impression. Colmme James Kanze je l'utilise
principalement dans 3 cas:
- post mortem (core dump)
- code mal écrit, logique pas claire ou trop d'indirection
- programme figé, attach pour localisation du point de blocage
Occasionnellement, en dernier recours pour un bug qui me mystifie. Il
m'arrive d'utiliser les printf (commentés ensuite) pour les parties de
programme qui génèreraient trop de log; c'est un patch sur le fait
qu'on a pas une granularité de log/trace infinie.
> > Dans mon entourage, tout ceux à qui j'ai montré un
> > debugger pratique l'ont adopté.
> > PS: tes élèves, tu ne leur apprends pas le débugger ?
>
> Aux élèves, il faudrait plutôt l'interdire. Il vaut mieux leur
> apprendre d'écrire du code correctement, pourqu'ils n'en ont pas
> besoin d'un déboggueur.
Ou mieux: leur apprendre à lire du code correctement. Ca leur
permettrait de se relire et de lire le code des autres. Ensuite le
debuggueur est dans la tête et ça va plus vite; puis AMA, en
identifiant les points clé d'un programme ou d'un algo, ils verraient
mieux quels tests unitaires écrire.
--
Michael
Marc Boyer
> ça m'est arrivé de mettre plusieurs jours à trouver un bug dans du
> code que je n'ai pas écrit.
C'est en effet un point majeur que tu soulignes: c'est vrai
que dans ma pratique, je récupère peu de code extérieur, donc
je n'en ai pas besoin.
Et quand je déboguais du code étudiant, j'avais toujours le
codeur sous la main.
Senhon
"Fabien LE LEZ" <gram...@gramster.com> a �crit dans le message de groupe de
discussion : ig28h5pns410ne2jg...@4ax.com...
> On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG <hey...@gmail.com>:
>
>>Oui, tu auras devin� que j'avais le C en t�te lorsque j'ai �crit
>>cela...
>>
> mal d'outils qui servent presque exclusivement sur le code des autres.
>
>>Celui de Visual Studio l'est.
>
> Oui. Dommage qu'il faille subir, pour l'utiliser, le reste de l'IDE.
>
> C'est d'ailleurs en partie pour �a que j'utilise peu le d�bogueur :
> d�marrer le d�bogueur me force � lancer l'IDE et � y cr�er un projet,
> t�che d�sagr�able � laquelle je ne me r�soud que si je ne trouve pas
> d'autre solution.
C'est l� que tu te trompes �norm�ment.
Je comprends ta vision lorsque, au d�part, tu "subis" l'IDE, c'est d'un
frustrant ... je me souviens encore de la mienne et du rejet que cela
induisait.
VisualStudio est �norm�ment pratique quand tu utilises ( dans mon cas ) les
macros ( je ne saurai dire pour les "Mod�le objet d'extensibilit�").
Il est possible de d�finir ses propres patrons : de projets [ ou pas de
patron du tout ;-) ], de sources, de fonctions, de classes, de
pr�sentation, ....
En quelques clics ou raccourci clavier, il r�alise un travail consid�rable.
C'est d'une productivit� INEGALEE.
Cela demande un investissement au d�part, quelques crises de nerfs parce que
l'outils ne r�agis pas comme nous avons �t� format� par les outils
ant�rieurs.
Le truc c'est : il faut programmer son propre outils de programmation. Comme
l'�crivait Bjarne Stoupstrup, "... recursive is divine".
Michael Doubez
> "Fabien LE LEZ" <grams...@gramster.com> a écrit dans le message de groupe de
> discussion : ig28h5pns410ne2jgmoq42umc8qs4kr...@4ax.com...
>
> > Je pense que tu as mis le doigt sur un point important : il y a pas
> > mal d'outils qui servent presque exclusivement sur le code des autres.
>
> >>Celui de Visual Studio l'est.
>
> > Oui. Dommage qu'il faille subir, pour l'utiliser, le reste de l'IDE.
>
> > démarrer le débogueur me force à lancer l'IDE et à y créer un projet,
> > tâche désagréable à laquelle je ne me résoud que si je ne trouve pas
> > d'autre solution.
C'est peut être pour ça qu'ils ont renommé leur "target" en
"solution" :)
> C'est là que tu te trompes énormément.
> Je comprends ta vision lorsque, au départ, tu "subis" l'IDE, c'est d'un
> frustrant ... je me souviens encore de la mienne et du rejet que cela
> induisait.
>
> VisualStudio est énormément pratique quand tu utilises ( dans mon cas ) les
> macros ( je ne saurai dire pour les "Modèle objet d'extensibilité").
>
> Il est possible de définir ses propres patrons : de projets [ ou pas de
> patron du tout ;-) ], de sources, de fonctions, de classes, de
> présentation, ....
> En quelques clics ou raccourci clavier, il réalise un travail considérable.
> C'est d'une productivité INEGALEE.
Plus vite qu'insérer un patron en quatres touches sans quitter les
mains du clavier ?
> Cela demande un investissement au départ, quelques crises de nerfs parce que
> l'outils ne réagis pas comme nous avons été formaté par les outils
> antérieurs.
>
> Le truc c'est : il faut programmer son propre outils de programmation. Comme
> l'écrivait Bjarne Stoupstrup, "... recursive is divine".
En fait c'est James Coplien.
Et je ne vois pas la relation avec la recursion, programmer un outil
de programmation est un processus itératif.
--
Michael
Michael Doubez
Après vérification, c'est Peter Deutsch et Robert Heller.
Désolé pour le bruit.
--
Michael
Fabien LE LEZ
<michael...@free.fr>:
>Et je ne vois pas la relation avec la recursion, programmer un outil
>de programmation est un processus it�ratif.
L'id�e de programmer un outil pour pouvoir programmer, est r�cursive.
Senhon
"Michael Doubez" <michael...@free.fr> a �crit dans le message de groupe
de discussion :
589500b7-9e38-4263...@j14g2000yqm.googlegroups.com...
> On 1 d�c, 11:19, "Senhon" <N...@Nul.Nul> wrote:
>> "Fabien LE LEZ" <grams...@gramster.com> a �crit dans le message de groupe
>> de
>> discussion : ig28h5pns410ne2jgmoq42umc8qs4kr...@4ax.com...
>>
>
> Plus vite qu'ins�rer un patron en quatres touches sans quitter les
> mains du clavier ?
Pour ne parler que de ce que je connais, mon cas perso, un nouveau projet,
avec son fichier contenant un main, ces inclusions, ces initialisations,
tout un tas de truc ch..t � r�p�ter � chaque projet, se d�clenche en un
raccourci clavier.
>
>> Cela demande un investissement au d�part, quelques crises de nerfs parce
>> que
>> l'outils ne r�agis pas comme nous avons �t� format� par les outils
>> ant�rieurs.
>>
>> Le truc c'est : il faut programmer son propre outils de programmation.
>> Comme
>> l'�crivait Bjarne Stoupstrup, "... recursive is divine".
>
> En fait c'est James Coplien.
Soit, si tu le dis ... je disais juste que dans un des ses livres (dont le
titre, de m�moire, �tait "C with Classes"), Stroupstrup �crivait cette
sentence, en t�te de chapitre, qui m'avait beaucoup plu.
>
> Et je ne vois pas la relation avec la recursion, programmer un outil
> de programmation est un processus it�ratif.
>
C'est pas grave, c'�tait plut�t en clin d'oeil.
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message
> de groupe de discussion :
> 38e5cab6-ae8e-42fd-8184-012871b7f...@e22g2000vbm.googlegroups.com...
> > On Nov 30, 2:28 pm, "Senhon" <N...@Nul.Nul> wrote:
> >> "AG" <hey...@gmail.com> a écrit dans le message de groupe de discussion :
> >> abe29be0-d45b-412f-a23c-88870abaf...@z7g2000vbl.googlegroups.com...
> >> GDB, rend d'énormes services.
> >> Mais, je n'ai rien trouvé de mieux que Visual Studio, c'est
> >> un plaisir que de travailler avec cette merveille. GDB en
> >> comparaison fait outil d'un autre âge.
> > Là, c'est de l'ironie, n'est-ce pas ? Parce que je me sers
> > actuellement de Visual Studio (pour comprendre du code que
> > je n'ai pas écrit, et pour lequel il n'y a aucune
> > documentation), et je me heurte constamment à ses
> > limitations.
> Pas du tout, mais alors, loin de là.
> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
> rencontré nulle part ailleurs, vaut le détour.
Et ça fait quoi, la touche F12 ? Personne ici ne la connaît (et
ils sont pour la plupart des spécialistes du dévelopement sous
Windows).
> Bon c'est sûr que dans ton cas, c'est pas ton prog, peut-être
> pas ton OS de prédilection, c'est pas ton outils de debug
> habituel, lorsque l'on est habitué à une interface
> utilisateur, cela gêne pour passer à une autre : et
> l'occurrence, entre GDB (commande ligne) et VisualStudio
> (graphique), l'écart est déjà conceptuel.
Ce n'est pas l'OS que je connais le mieux, c'est vrai. Je ne
travaille avec Visual Studios et sous Windows que depuis quelque
moins (après environ 20 ans sous Unix). Dans l'ensemble, ça ne
me pose pas de problèmes ; il y a même des choses (pas mal,
d'ailleurs) où je trouve Windows supérieur à Unix. Mais le
debugger, ou bien, personne ici ne le connaît, ou bien, c'est un
désastre. (Aussi, je ne peux pas dire connaître gdb très bien.
Il faut dire que je me suis servi d'un déboggueur peut-être cinq
fois dans les dix dernières années.)
> Quelles sont ces limitations que tu rencontre ?
Qu'il n'ait pas de ligne de commande:-). Sérieusement, c'est
plus ou moins ça. J'ai l'habitude de pouvoir afficher n'importe
quelle expression (y compris des expressions qui comporte des
appels de fonctions dans mon code), et de l'afficher
systematiquement, chaque fois que l'exécution s'arrête. Et
l'environement où je travaille fait que je suis bien obligé à me
servir d'un déboggueur ; même l'échec d'une assertion n'arrête
pas le programme.
--
James Kanze
James Kanze
> On Nov 30, 5:39 pm, James Kanze <james.ka...@gmail.com>
> wrote:> Tu vas prétendre que la spécification des
> préconditions et des
> > invariants n'est pas nécessaire ? Qu'on peut se passer des
> > tests unitaires ?
> Non bien sûr, mais à l'inverse vas-tu prétendre qu'on est à
> l'abri de tout avec les tests unitaires ? Non bien évidemment.
> Si on débugge sans débuggeur, c'est forcément que les tests
> unitaires ont loupé quelque chose. Arrivé à ce stade, n'est-ce
> pas une perte de temps de re-écrire plein de code de débug,
> pour finalement compléter les tests unitaires qu'avec un cas
> supplémentaire ?
Si on se trouve avec une erreur qui n'est pas détectée par les
tests unitaires, la toute première chose qu'il faut faire, c'est
de créer un test unitaire qui la provoque. Avant de toucher à
quoique ce soit d'autre. Sinon, on saurait jamais si on l'a
corrigé. Et il y aura toujours la risque qu'on la réintroduit à
l'avenir.
--
James Kanze
James Kanze
> In article
> <8668bfdf-d729-4a25-bd0c-cd73b73fd...@j35g2000vbl.googlegroups.com>,
> James Kanze <james.ka...@gmail.com> wrote:
> >Aux l ves, il faudrait plut t l'interdire. Il vaut mieux leur
> >apprendre d' crire du code correctement, pourqu'ils n'en ont
> >pas besoin d'un d boggueur.
> Avec ma population actuelle d'etudiants, je leur montre un
> debugger. Il faut voir qu'ils n'ecrivent pas forcement du
> code correct, mais qu'ils debugguent a grands coups de printf.
> Alors, quitte a debugguer, autant que ca soit efficace...
C'est sûr qu'entre des grands coups de printf et un déboggueur,
il n'y a pas grand choses à dire. Mais ne serait-il pas
préférrable de leur enseigner comment écrire du code d'une façon
à n'avoir besoin ni d'un ni de l'autre.
À la rigueur, je me démande même si je leur autoriserais un
compilateur. Pour au moins un projet.
--
James Kanze
James Kanze
> On 30 nov, 17:39, James Kanze <james.ka...@gmail.com> wrote:
[en ce concerne des déboggueurs...]
> > Aux élèves, il faudrait plutôt l'interdire. Il vaut mieux leur
> > apprendre d'écrire du code correctement, pourqu'ils n'en ont pas
> > besoin d'un déboggueur.
> Ou mieux: leur apprendre à lire du code correctement.
Les deux vont ensemble. Mais j'aurais dû être plus clair ;
écrire du code correctement, c'est beaucoup plus qu'écrire du
code correct. La lisabilité joue un rôle importante.
> Ca leur permettrait de se relire et de lire le code des
> autres. Ensuite le debuggueur est dans la tête et ça va plus
> vite; puis AMA, en identifiant les points clé d'un programme
> ou d'un algo, ils verraient mieux quels tests unitaires
> écrire.
Ce qu'il faut, en fait, c'est non seulement que les élèves
écrivent du code, mais qu'ils le fassent lire. Et si la lecteur
n'est pas convaincu que le code est correct, on le rejette ; non
seulement le code doit être correct, il faut qu'il soit
visiblement correct, sans que le lecteur ait besoin d'un effort
particulier pour le comprendre. Ou comme j'ai lu quelque part
(Knuth, je crois), « code is either so simple, it obviously has
no errors, or so complex, it has no obvious errors ». C'est
évidemment le premier qu'il faut viser. (Ou comme disait mon
prof d'anglais au lycée : « good writing is clear and concise ».
Ce qui vaut pour l'anglais vaut aussi pour le C++.)
Ensuite, évidemment : les tests unitaires font partie du
« code ». Il faut qu'il soit aussi évident qu'ils teste tout.
--
James Kanze
James Kanze
> "Fabien LE LEZ" <grams...@gramster.com> a écrit dans le
> message de groupe de discussion :
> > On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG <hey...@gmail.com>:
> >>Oui, tu auras deviné que j'avais le C en tête lorsque j'ai
> >>écrit cela...
> > Je pense que tu as mis le doigt sur un point important : il
> > y a pas mal d'outils qui servent presque exclusivement sur
> > le code des autres.
> >>Celui de Visual Studio l'est.
> > Oui. Dommage qu'il faille subir, pour l'utiliser, le reste
> > de l'IDE.
Ce n'est pas tout à fait vrai. Je ne me rappelle jamais la
séquence de clics qu'il faut -- il faut chaque fois que je le
recherche dans la doc. Mais c'est tout à fait possible à créer
un « projet » à partir d'un exécutable, sans rien faire de
particulier, simplement pour les besoins du déboggage.
> > C'est d'ailleurs en partie pour ça que j'utilise peu le
> > débogueur : démarrer le débogueur me force à lancer l'IDE et
> > à y créer un projet, tâche désagréable à laquelle je ne me
> > résoud que si je ne trouve pas d'autre solution.
> C'est là que tu te trompes énormément.
> Je comprends ta vision lorsque, au départ, tu "subis" l'IDE,
> c'est d'un frustrant ... je me souviens encore de la mienne et
> du rejet que cela induisait.
> VisualStudio est énormément pratique quand tu utilises ( dans
> mon cas ) les macros ( je ne saurai dire pour les "Modèle
> objet d'extensibilité").
> Il est possible de définir ses propres patrons : de projets [
> ou pas de patron du tout ;-) ], de sources, de fonctions, de
> classes, de présentation, .... En quelques clics ou raccourci
> clavier, il réalise un travail considérable. C'est d'une
> productivité INEGALEE.
À un moment ou à autre, il faut bien que tu précises à VS quels
fichiers sont dans le projet, etc. Travail qui est bien plus
facile sous vim que avec la souris.
--
James Kanze
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
17bb354b-e410-41ee...@a32g2000yqm.googlegroups.com...
> On Dec 1, 9:02 am, "Senhon" <N...@Nul.Nul> wrote:
>> de groupe de discussion :
>> 38e5cab6-ae8e-42fd-8184-012871b7f...@e22g2000vbm.googlegroups.com...
>
>> > On Nov 30, 2:28 pm, "Senhon" <N...@Nul.Nul> wrote:
>> >> discussion :
>> >> abe29be0-d45b-412f-a23c-88870abaf...@z7g2000vbl.googlegroups.com...
>
>> >> GDB, rend d'�normes services.
>> >> Mais, je n'ai rien trouv� de mieux que Visual Studio, c'est
>> >> un plaisir que de travailler avec cette merveille. GDB en
>
>> > L�, c'est de l'ironie, n'est-ce pas ? Parce que je me sers
>> > actuellement de Visual Studio (pour comprendre du code que
>> > documentation), et je me heurte constamment � ses
>> > limitations.
>
>> Pas du tout, mais alors, loin de l�.
>> Rien que l'usage de la touche F12, fonctionnalit� que je n'ai
>
> Et �a fait quoi, la touche F12 ? Personne ici ne la conna�t (et
> ils sont pour la plupart des sp�cialistes du d�velopement sous
> Windows).
Cela te place directement sur la d�finition d'un �l�ment.
>> Bon c'est s�r que dans ton cas, c'est pas ton prog, peut-�tre
>> pas ton OS de pr�dilection, c'est pas ton outils de debug
>> habituel, lorsque l'on est habitu� � une interface
>> utilisateur, cela g�ne pour passer � une autre : et
>> l'occurrence, entre GDB (commande ligne) et VisualStudio
>> (graphique), l'�cart est d�j� conceptuel.
>
>
> Qu'il n'ait pas de ligne de commande:-). S�rieusement, c'est
> plus ou moins �a. J'ai l'habitude de pouvoir afficher n'importe
> quelle expression (y compris des expressions qui comporte des
> appels de fonctions dans mon code), et de l'afficher
> systematiquement, chaque fois que l'ex�cution s'arr�te. Et
> l'environement o� je travaille fait que je suis bien oblig� � me
> servir d'un d�boggueur ; m�me l'�chec d'une assertion n'arr�te
> pas le programme.
Cela semble confirmer ce que je pressentais.
Il n'y pas d'�chappatoire, maitriser VisualStudio c'est facile comme le C++
... tout d�pend de la force de motivation.
Quelques lignes de C++ ne font pas de toi un connaisseur du langage, de
m�me, quelques clics dans VS ne te permettront pas de le connaitre .
Senhon
> On Nov 30, 6:17 pm, es...@lain.home (Marc Espie) wrote:
>> In article
>> <8668bfdf-d729-4a25-bd0c-cd73b73fd...@j35g2000vbl.googlegroups.com>,
>> James Kanze <james.ka...@gmail.com> wrote:
>
>> >Aux l ves, il faudrait plut t l'interdire. Il vaut mieux leur
>> >apprendre d' crire du code correctement, pourqu'ils n'en ont
>> >pas besoin d'un d boggueur.
>
>> Avec ma population actuelle d'etudiants, je leur montre un
>> debugger. Il faut voir qu'ils n'ecrivent pas forcement du
>> code correct, mais qu'ils debugguent a grands coups de printf.
>> Alors, quitte a debugguer, autant que ca soit efficace...
>
> il n'y a pas grand choses � dire. Mais ne serait-il pas
> pr�f�rrable de leur enseigner comment �crire du code d'une fa�on
> � n'avoir besoin ni d'un ni de l'autre.
>
Oui il faudrait leur injecter l'exp�rience d'un programmeur averti en
intraveineuse.
Mais c'est vrai �a ! Pourquoi ces profs s'escriment-ils � leur enseigner
autre chose que la bonne fa�on d'�crire.
PS:
Plus s�rieusement : A tous les profs ma profonde admiration pour leur
courage dans la tache incommensurable qu'ils assument, pris entre l'enclume
et le marteau, on leur tapent sur la t�te de tous cot�s.
Marc Boyer
>>> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
Cf plus bas.
>>
>> Et ça fait quoi, la touche F12 ? Personne ici ne la connaît (et
>> ils sont pour la plupart des spécialistes du dévelopement sous
>> Windows).
>
> Cela te place directement sur la définition d'un élément.
M-. en [x]emacs/CEDET
Ctr-BtDroit en Eclipse
Oui, c'est super utile, mais c'est une fonctionnalité d'IDE,
pas de débogueur.
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
0c61c942-ea8a-48d9...@a32g2000yqm.googlegroups.com...
> On Dec 1, 10:19 am, "Senhon" <N...@Nul.Nul> wrote:
>> message de groupe de discussion :
>> ig28h5pns410ne2jgmoq42umc8qs4kr...@4ax.com...
>> > On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG <hey...@gmail.com>:
>
>
> fichiers sont dans le projet, etc.
He bien, non ! Les d�clarations des fichiers dans les projets sont
automatis�s.
> Travail qui est bien plus facile sous vim que avec la souris.
C'est ce que je disais, tu essaies de faire comme avec vim. Le parall�le
programmation C et programmation C++ me parait fort � propos.
Utiliser VS comme vim n'a en soit pas d'int�r�t.
Par contre j'ai compris que dans ton cas actuel il ne soit pas simple
d'appr�hender tout le potentiel de VS.
Pour ce faire il faudrait �tre l'initiateur du projet. Et encore du premier
coup cela me semble tr�s improbable, il faudra se casser la t�te, faire
plusieurs tentatives, pour parvenir � un r�sultat significatif.
Les macros de VS c'est du VB, avec l'aide des "objet automation", tu
programmes ton outil comme tu le souhaites.
Senhon
"Marc Boyer" <Marc....@cert.onera.fr.invalid> a écrit dans le message de
groupe de discussion : hf3950$up0$1...@news.cict.fr...
> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
>>>> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
>>>> rencontré nulle part ailleurs, vaut le détour.
>
> Cf plus bas.
>
>>>
>>> Et ça fait quoi, la touche F12 ? Personne ici ne la connaît (et
>>> ils sont pour la plupart des spécialistes du dévelopement sous
>>> Windows).
>>
>> Cela te place directement sur la définition d'un élément.
>
> M-. en [x]emacs/CEDET
> Ctr-BtDroit en Eclipse
>
> Oui, c'est super utile, mais c'est une fonctionnalité d'IDE,
> pas de débogueur.
Lorsque l'on est dans l'IDE je ne voit pas comment on peut déterminer si une
fonctionnalité est à attribuer à une partie ou à une autre.
L'avantage de l'IDE : c'est d'être à la fois , et éditeur, et compilateur,
et debugger.
Marc Boyer
>
> "Marc Boyer" <Marc....@cert.onera.fr.invalid> a écrit dans le message de
> groupe de discussion : hf3950$up0$1...@news.cict.fr...
>> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
>>>>> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
>>>>> rencontré nulle part ailleurs, vaut le détour.
>>>>
>>>> ils sont pour la plupart des spécialistes du dévelopement sous
>>>> Windows).
>>>
>>> Cela te place directement sur la définition d'un élément.
>>
>> M-. en [x]emacs/CEDET
>> Ctr-BtDroit en Eclipse
>>
>> Oui, c'est super utile, mais c'est une fonctionnalité d'IDE,
>> pas de débogueur.
>
> Lorsque l'on est dans l'IDE je ne voit pas comment on peut déterminer si une
> fonctionnalité est à attribuer à une partie ou à une autre.
Disons que je suis habitué dans le monde Unix-like à ce que ce qui se
prétent IDE permette de paramétrer les différentes parties.
Tiens, mon client de mail, c'est Thunderbird, et mon editeur de mail,
c'est xemacs.
Mon compilo, c'est souvent gcc, et mon éditeur/IDE, xemacs.
Le client Usenet, c'est slrn, et l'éditeur de news, c'est vi.
> L'avantage de l'IDE : c'est d'être à la fois , et éditeur, et compilateur,
> et debugger.
Voui, le lien éditeur/compilateur est primordial.
En fait, sans rechercher spécialement la polémique, comme tu as l'air
de bien connaitre VC++, je me demandais quelles fonctionnalités
de son débogueur tu trouvais vraiment unique et qui pourrait me
faire sauter le pas.
Senhon
"Senhon" <N...@Nul.Nul> a écrit dans le message de groupe de discussion :
4b152a62$0$30345$426a...@news.free.fr...
>
> "Marc Boyer" <Marc....@cert.onera.fr.invalid> a écrit dans le message de
> groupe de discussion : hf3950$up0$1...@news.cict.fr...
>> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
>>>>> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
>>>>> rencontré nulle part ailleurs, vaut le détour.
>>
>> Cf plus bas.
>>
>>>>
>>>> Et ça fait quoi, la touche F12 ? Personne ici ne la connaît (et
>>>> ils sont pour la plupart des spécialistes du dévelopement sous
>>>> Windows).
>>>
>>> Cela te place directement sur la définition d'un élément.
>>
>> M-. en [x]emacs/CEDET
Je parlais disposer de cette fonctionnalité directement dans un debugger, je
pensais GDB/DDD.
>> Ctr-BtDroit en Eclipse
Pour Eclipse je suis victime de ce que je disais.
J'ai connu Visual C, puis Visual Studio, et la seule fois ou j'ai été
confronté à Eclipse ( d'ailleurs c'était avec du java), j'ai fait un rejet,
habitué tel que je l'étais à la chaine VS, j'ai trouvé ça nul, pas pratique,
compliqué. Mais j'ai conscience de ce que le problème vient de mon
orientation d'esprit, forgé depuis des années par certains automatismes non
directement transposable dans Eclipse. Du coup je ne saurais dire si
Ctr-BtDroit correspond à F12 dans VS, je m'en remets à toi.
Senhon
"Marc Boyer" <Marc....@cert.onera.fr.invalid> a écrit dans le message de
> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
>>
>
> En fait, sans rechercher spécialement la polémique, comme tu as l'air
> de bien connaitre VC++, je me demandais quelles fonctionnalités
> de son débogueur tu trouvais vraiment unique et qui pourrait me
> faire sauter le pas.
C'est ses possibilités de personnalisation.
Pardon pour la répétition: Grâce aux macros ( utilisation de l'interface
automation par du VB ) il est possible de réaliser TON outil de
programmation, qui agit comme tu le lui a programmé, suivant ta méthodologie
propre.
Malheureusement, je connais qu'un peu VS (VC++ étant la génération d'avant
automation, cependant disposant déjà de macros). Peut-être, un peu plus que
la moyenne dans ce NG.
Il reste tout ce qui concerne l'extension directement avec des compléments
en C++, ou des plug-ins, que je ne connais pas.
Fabien LE LEZ
>VB
Pour la prochaine version, ils pensent passer � Brainfuck.
Marc Boyer
>
> "Marc Boyer" <Marc....@cert.onera.fr.invalid> a écrit dans le message de
> groupe de discussion : hf3ajg$up0$2...@news.cict.fr...
>> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
>>
>> En fait, sans rechercher spécialement la polémique, comme tu as l'air
>> de bien connaitre VC++, je me demandais quelles fonctionnalités
>> de son débogueur tu trouvais vraiment unique et qui pourrait me
>> faire sauter le pas.
>
> C'est ses possibilités de personnalisation.
>
> Pardon pour la répétition: Grâce aux macros ( utilisation de l'interface
> automation par du VB ) il est possible de réaliser TON outil de
> programmation, qui agit comme tu le lui a programmé, suivant ta méthodologie
> propre.
Mais c'est le debogueur que tu personnalises ou l'éditeur ?
Sous [x]emacs, tu personnalises en emacs-lisp. Tu peux faire ta commande
'new-class' qui te demande le nom de la classe, crée le .hpp, le .cpp,
les #include, l'ajoute au svn, etc...
gdb se scripte assez bien, mais je ne sache pas qu'on puisse
y définir des fonctions.
Après, qu'on préfère écrire ses macros en VB ou en emacs-lisp,
c'est chacun son gout.
Jean-Marc Bourguet
> Pardon pour la r�p�tition: Gr�ce aux macros ( utilisation de l'interface
> automation par du VB ) il est possible de r�aliser TON outil de
> programmation, qui agit comme tu le lui a programm�, suivant ta
> m�thodologie propre.
C'est le strict minimum pour un editeur de programmeur. On a ca au moins
depuis teco... je ne sais pas quand. Pour rappel, emacs a commence comme
un ensemble de macros teco et le developpement du PDP-10 -- sur lequel
emacs a ete concu -- a ete arrete en 1983.
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
AG
> Si on se trouve avec une erreur qui n'est pas détectée par les
> tests unitaires,
nouveau code de débug...
Alexandre.
Marc Boyer
>
> "Senhon" <N...@Nul.Nul> a écrit dans le message de groupe de discussion :
> 4b152a62$0$30345$426a...@news.free.fr...
>>
>> "Marc Boyer" <Marc....@cert.onera.fr.invalid> a écrit dans le message de
>> groupe de discussion : hf3950$up0$1...@news.cict.fr...
>>> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
>>>>>> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
>>>>>> rencontré nulle part ailleurs, vaut le détour.
>>>
>>> Cf plus bas.
>>>
>>>>>
>>>>> Et ça fait quoi, la touche F12 ? Personne ici ne la connaît (et
>>>>> ils sont pour la plupart des spécialistes du dévelopement sous
>>>>> Windows).
>>>>
>>>> Cela te place directement sur la définition d'un élément.
>>>
>>> M-. en [x]emacs/CEDET
>
> Je parlais disposer de cette fonctionnalité directement dans un debugger, je
> pensais GDB/DDD.
Il faut alors faire GDB/DDD/[x]emacs
>>> Ctr-BtDroit en Eclipse
>
> Pour Eclipse je suis victime de ce que je disais.
> J'ai connu Visual C, puis Visual Studio, et la seule fois ou j'ai été
> confronté à Eclipse ( d'ailleurs c'était avec du java), j'ai fait un rejet,
> habitué tel que je l'étais à la chaine VS, j'ai trouvé ça nul, pas pratique,
> compliqué. Mais j'ai conscience de ce que le problème vient de mon
> orientation d'esprit, forgé depuis des années par certains automatismes non
> directement transposable dans Eclipse. Du coup je ne saurais dire si
> Ctr-BtDroit correspond à F12 dans VS, je m'en remets à toi.
En fait, je me remets au C++, et je me demandais s'il y avait des
choses plus pertinentes que mon xemacs/ctags.
Les deux trucs de base, c'est la completion automatique, et
retrouver la declaration et la définition d'un symbole.
Voilà, en eclipse, c'est Ctrl-Espace et Ctrl-ClicDroit.
En xemacs/ctags, c'est M-/ et M-.
En emacs/CEDET, ils ont visiblement pas choisi les raccourcis, et
il faut se les choisir.
Senhon
"Jean-Marc Bourguet" <j...@bourguet.org> a �crit dans le message de groupe de
discussion : pxb8wdm...@news.bourguet.org...
> "Senhon" <N...@Nul.Nul> writes:
>
>> Pardon pour la r�p�tition: Gr�ce aux macros ( utilisation de l'interface
>> automation par du VB ) il est possible de r�aliser TON outil de
>> programmation, qui agit comme tu le lui a programm�, suivant ta
>> m�thodologie propre.
>
> C'est le strict minimum pour un editeur de programmeur. On a ca au moins
> depuis teco... je ne sais pas quand. Pour rappel, emacs a commence comme
> un ensemble de macros teco et le developpement du PDP-10 -- sur lequel
> emacs a ete concu -- a ete arrete en 1983.
VS n'est pas qu'un �diteur.
Avec emacs tu debugges ?
Bon tant pis je ne suis pas pay� pour vendre VS.
Et je ne me sens pas de taille pour d�fendre MS envers et contre tous.
En fait, que vous trouviez emacs, vim voir m�me ed, comme outil de
d�veloppement ad�quat pour vos besoins, je trouve �a tr�s bien.
Senhon
"Marc Boyer" <Marc....@cert.onera.fr.invalid> a écrit dans le message de
> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
>>
>> "Senhon" <N...@Nul.Nul> a écrit dans le message de groupe de discussion :
>> 4b152a62$0$30345$426a...@news.free.fr...
>>>
>
> choses plus pertinentes que mon xemacs/ctags.
> Les deux trucs de base, c'est la completion automatique, et
> retrouver la declaration et la définition d'un symbole.
> Voilà, en eclipse, c'est Ctrl-Espace et Ctrl-ClicDroit.
> En xemacs/ctags, c'est M-/ et M-.
> En emacs/CEDET, ils ont visiblement pas choisi les raccourcis, et
> il faut se les choisir.
Pardon d'avoir laisser dériver le fil, mais je ne saurais répondre à tes
questions.
Pour recadrer, mon intervention faisait suite à un post de James Kanze, qui
se trouvais aux prises avec VS et un programme dont il n'est pas l'auteur.
Jean-Marc Bourguet
> "Jean-Marc Bourguet" <j...@bourguet.org> a �crit dans le message de groupe de
> discussion : pxb8wdm...@news.bourguet.org...
> > "Senhon" <N...@Nul.Nul> writes:
> >
> >> Pardon pour la r�p�tition: Gr�ce aux macros ( utilisation de l'interface
> >> automation par du VB ) il est possible de r�aliser TON outil de
> >> programmation, qui agit comme tu le lui a programm�, suivant ta
> >> m�thodologie propre.
> >
> > C'est le strict minimum pour un editeur de programmeur. On a ca au moins
> > depuis teco... je ne sais pas quand. Pour rappel, emacs a commence comme
> > un ensemble de macros teco et le developpement du PDP-10 -- sur lequel
> > emacs a ete concu -- a ete arrete en 1983.
>
> VS n'est pas qu'un �diteur.
> Avec emacs tu debugges ?
Je lance gdb dans emacs et c'est de tout ceux que j'ai essaie le plus
confortable des environnements (mais c'est un choix par defaut, je
travaille comme je travaillais il y a quinze ans et je suis surpris du
manque de progres dans les outils). J'utilise beaucoup moins le debuggeur
que certains, mais plus que James ne pretend le faire.
> Bon tant pis je ne suis pas pay� pour vendre VS. Et je ne me sens pas de
> taille pour d�fendre MS envers et contre tous. En fait, que vous
> trouviez emacs, vim voir m�me ed, comme outil de d�veloppement ad�quat
> pour vos besoins, je trouve �a tr�s bien.
Je ne connais pas VS. VS n'est certainement pas adequat pour mes besoins:
il n'est disponible que sur une plateforme qui ne fait pas partie de mes
cibles. Je n'ai aucune idee sur ce qu'il peut apporter ou pas -- j'ai une
liste des choses que j'aimerais bien dans mon environnement et que je n'ai
pas, il est certain que VS en propose certaines(*) --, mais quand je vois
"vendre" des choses que j'ai depuis avant que VS existe dans mon
environnement comme des progres sans pareil (que ce soit les macros, les
templates ou autre chose), j'ai l'impression que tout le monde n'a pas les
memes scrupules que moi a ne comparer que des choses qu'ils connaissent.
A+
(*) La vraie question, c'est si ce que VS m'apporterait compenserait ce que
je n'aurais plus. Pour le moment, la reponse est non puisque le support
d'au moins une de mes cibles est quand meme la premiere exigence que j'ai
pour essayer un nouvel outil. (La deuxieme est la capacite a l'essayer
sans changer la maniere de travailler de mes collegues et sans passer 3
semaines a chercher a le configurer pour cela -- chose qui a elimine pas
mal d'autres IDE sous Linux).
James Kanze
wrote:
> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
> >>> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
> >>> rencontré nulle part ailleurs, vaut le détour.
> Cf plus bas.
> >> Et ça fait quoi, la touche F12 ? Personne ici ne la connaît
> >> (et ils sont pour la plupart des spécialistes du
> >> dévelopement sous Windows).
> > Cela te place directement sur la définition d'un élément.
> M-. en [x]emacs/CEDET
> Ctr-BtDroit en Eclipse
Et Ctr-] in vim. (Pas que je ne l'ai jamais trouvé si important
que ça.)
> Oui, c'est super utile, mais c'est une fonctionnalité d'IDE,
> pas de débogueur.
C'est surtout une fonctionalité de l'éditeur, je crois.
--
James Kanze
James Kanze
> "Marc Boyer" <Marc.Bo...@cert.onera.fr.invalid> a écrit dans le message de
> groupe de discussion : hf3950$up...@news.cict.fr...
> > Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
> >>>> Rien que l'usage de la touche F12, fonctionnalité que je n'ai
> >>>> rencontré nulle part ailleurs, vaut le détour.
> > Cf plus bas.
> >>> Et ça fait quoi, la touche F12 ? Personne ici ne la connaît (et
> >>> ils sont pour la plupart des spécialistes du dévelopement sous
> >>> Windows).
> >> Cela te place directement sur la définition d'un élément.
> > M-. en [x]emacs/CEDET
> > Ctr-BtDroit en Eclipse
> > Oui, c'est super utile, mais c'est une fonctionnalité d'IDE,
> > pas de débogueur.
> Lorsque l'on est dans l'IDE je ne voit pas comment on peut
> déterminer si une fonctionnalité est à attribuer à une partie
> ou à une autre. L'avantage de l'IDE : c'est d'être à la fois
> , et éditeur, et compilateur, et debugger.
C'est aussi le désavantage. On a un outil qui fait moyenement
tout, mais rien très bien. (Je ne crois pas qu'il faut que ce
soit le cas, mais dans la pratique, ou bien c'est le cas, ou
bien l'integration montre ses coutures.)
--
James Kanze
James Kanze
> "Marc Boyer" <Marc.Bo...@cert.onera.fr.invalid> a écrit dans le message de
> groupe de discussion : hf3ajg$up...@news.cict.fr...
> > Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
> > En fait, sans rechercher spécialement la polémique, comme tu
> > as l'air de bien connaitre VC++, je me demandais quelles
> > fonctionnalités de son débogueur tu trouvais vraiment unique
> > et qui pourrait me faire sauter le pas.
> C'est ses possibilités de personnalisation.
Alors, c'est emacs qu'il te faut.
> Pardon pour la répétition: Grâce aux macros (utilisation de
> l'interface automation par du VB ) il est possible de réaliser
> TON outil de programmation, qui agit comme tu le lui a
> programmé, suivant ta méthodologie propre.
En emacs, pratiquement tout est un « macro », ou plutôt une
fonction lisp. Y compris les bindings du clavier.
> Malheureusement, je connais qu'un peu VS (VC++ étant la
> génération d'avant automation, cependant disposant déjà de
> macros). Peut-être, un peu plus que la moyenne dans ce NG. Il
> reste tout ce qui concerne l'extension directement avec des
> compléments en C++, ou des plug-ins, que je ne connais pas.
L'avantage éventuel de VS, c'est qu'il y en a des plug-ins.
C'est évidemment la première plateforme ciblée pour ce genre de
chose.
--
James Kanze
James Kanze
wrote:
> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
> > groupe de discussion : hf3ajg$up...@news.cict.fr...
> >> Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
> >> En fait, sans rechercher spécialement la polémique, comme
> >> tu as l'air de bien connaitre VC++, je me demandais quelles
> >> fonctionnalités de son débogueur tu trouvais vraiment
> >> unique et qui pourrait me faire sauter le pas.
> > C'est ses possibilités de personnalisation.
> > Pardon pour la répétition: Grâce aux macros ( utilisation de
> > l'interface automation par du VB ) il est possible de
> > réaliser TON outil de programmation, qui agit comme tu le
> > lui a programmé, suivant ta méthodologie propre.
> Mais c'est le debogueur que tu personnalises ou l'éditeur ?
C'est le IDE:-).
> Sous [x]emacs, tu personnalises en emacs-lisp. Tu peux faire
> ta commande 'new-class' qui te demande le nom de la classe,
> crée le .hpp, le .cpp, les #include, l'ajoute au svn, etc...
Et quand tu ouvres un nouveau fichier, il te génère le
boilerplating. De même que vim.
> gdb se scripte assez bien, mais je ne sache pas qu'on puisse y
> définir des fonctions.
Selon la doc, tu peux, mais je ne connais pas jusqu'où.
> Après, qu'on préfère écrire ses macros en VB ou en emacs-lisp,
> c'est chacun son gout.
Moi, dès qu'ils deviennent compliqués, je les écris en bash, awk
ou C++. La commande vim qui me sers le plus dans les macros, je
crois, c'est ! (pipe la région en question à travers une
commande shell). C'est un avantage de VS que de pouvoir utiliser
le même langage de customisation de a jusqu'à z, mais tous les
outils Unix qui se respectent connaissent le !, pour ensuite
pouvoir exploiter tout ce qu'il y a sur la machine.
--
James Kanze
James Kanze
Surtout, à partir des informations en provenance du client. La
première chose à faire, toujours, c'est de pouvoir reproduire
l'erreur (ce qui n'est pas toujours évident, selon le type
d'application). Une fois reproduite, on écrit un test qui le
révèle systèmatiquement, d'une part d'être sûr par la suite
qu'on l'a corrigée, et de l'autres pour les besoins de la
regression. Ça, c'est avant de commencer à chercher d'où elle
vient.
Ensuite, selon les personnes, on pourrait se servir du
déboggueur pour essayer d'isoler le composant en cause. Dans la
plupart des applications sur lesquelles j'ai travaillé dans la
passée, en revanche, une bonne analyse des fichiers de log
suffisait.
--
James Kanze
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message de groupe de
> discussion :
> 0c61c942-ea8a-48d9-9fe0-c604470d3...@a32g2000yqm.googlegroups.com...
> > On Dec 1, 10:19 am, "Senhon" <N...@Nul.Nul> wrote:
> >> "Fabien LE LEZ" <grams...@gramster.com> a écrit dans le
> >> message de groupe de discussion :
> >> ig28h5pns410ne2jgmoq42umc8qs4kr...@4ax.com...
> >> > On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG <hey...@gmail.com>:
> > À un moment ou à autre, il faut bien que tu précises à VS quels
> > fichiers sont dans le projet, etc.
> He bien, non ! Les déclarations des fichiers dans les projets sont
> automatisés.
Alors, il est vraiment génial, parce qu'il peut lire dans ma
tête. (Je peux dire à GNU make de prendre tous les .cc dans un
répertoire -- c'est une chose à éviter.)
> > Travail qui est bien plus facile sous vim que avec la souris.
> C'est ce que je disais, tu essaies de faire comme avec vim.
Ou d'autre chose. Ce qui est certain, c'est que pendant que tu
saisis le code, il ne faut pas éloigner les mains de la position
de base sur le clavier, au prix d'une perte de productivité
importante.
> Le parallèle programmation C et programmation C++ me parait
> fort à propos. Utiliser VS comme vim n'a en soit pas
> d'intérêt.
Dans le mesure où on ne le peut pas, parce qu'il n'en a pas les
fonctionalités de base qu'il faut.
> Par contre j'ai compris que dans ton cas actuel il ne soit pas
> simple d'appréhender tout le potentiel de VS. Pour ce faire
> il faudrait être l'initiateur du projet. Et encore du premier
> coup cela me semble très improbable, il faudra se casser la
> tête, faire plusieurs tentatives, pour parvenir à un résultat
> significatif.
> Les macros de VS c'est du VB, avec l'aide des "objet
> automation", tu programmes ton outil comme tu le souhaites.
Et les macros de vim, c'est tout ce qui m'offre le système. Y
compris du code que j'ai écris en C++, des scripts de shell, et
que sais-je.
--
James Kanze
Michael DOUBEZ
> On Tue, 1 Dec 2009 02:39:41 -0800 (PST), Michael Doubez
> <michael...@free.fr>:
>
>> Et je ne vois pas la relation avec la recursion, programmer un outil
>> de programmation est un processus it�ratif.
>
> L'id�e de programmer un outil pour pouvoir programmer, est r�cursive.
Ca me parait plut�t it�ratif dans la mesure ou une version ant�rieur
permet de g�n�rer une version suivante mais on ne reviens pas � la
version pr�c�dente (sauf quand on upgrade de vista a XP :o).
--
Michael
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
965f06ec-1b80-40be...@r5g2000yqb.googlegroups.com...
> On Dec 1, 2:38 pm, "Senhon" <N...@Nul.Nul> wrote:
>> groupe de discussion : hf3950$up...@news.cict.fr...
>
>> Lorsque l'on est dans l'IDE je ne voit pas comment on peut
>> ou � une autre. L'avantage de l'IDE : c'est d'�tre � la fois
>> , et �diteur, et compilateur, et debugger.
>
> C'est aussi le d�savantage. On a un outil qui fait moyenement
> tout, mais rien tr�s bien. (Je ne crois pas qu'il faut que ce
> soit le cas, mais dans la pratique, ou bien c'est le cas, ou
> bien l'integration montre ses coutures.)
Peux-tu pr�ciser de quel produit tu parles ?
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message de groupe de
> discussion :
> 965f06ec-1b80-40be-b040-f7a865039...@r5g2000yqb.googlegroups.com...
> > On Dec 1, 2:38 pm, "Senhon" <N...@Nul.Nul> wrote:
> >> "Marc Boyer" <Marc.Bo...@cert.onera.fr.invalid> a écrit
> >> dans le message de groupe de discussion :
> >> hf3950$up...@news.cict.fr...
> >> > Le 01-12-2009, Senhon <N...@Nul.Nul> a écrit :
> >> Lorsque l'on est dans l'IDE je ne voit pas comment on peut
> >> déterminer si une fonctionnalité est à attribuer à une partie
> >> ou à une autre. L'avantage de l'IDE : c'est d'être à la fois
> >> , et éditeur, et compilateur, et debugger.
> > C'est aussi le désavantage. On a un outil qui fait moyenement
> > tout, mais rien très bien. (Je ne crois pas qu'il faut que ce
> > soit le cas, mais dans la pratique, ou bien c'est le cas, ou
> > bien l'integration montre ses coutures.)
> Peux-tu préciser de quel produit tu parles ?
Pratiquement tous les IDE. Les bons éditeurs, ce sont les
éditeurs, non des sous-produit d'un IDE. De même pour les bons
deboggueurs, etc. Or, ou bien, l'IDE integre son propre éditeur
(comme VS), et c'est moins bien que les éditeurs spécialisés, ou
bien, il integre un éditeur existant (Sun Studios, par exemple),
et l'integration est moins que parfait.
Je ne crois pas que ce soit quelque chose d'inévitable. Surtout
que les sources des éditeurs qu'integre Sun Studios sont
libres. Sun pourrait les modifier pour assurer une integration
complete -- à condition de mettre tout Sun Studios sous GPL, ce
que Sun n'est pas pret à faire. Sinon, Microsoft a bien des
ressources pour donner à l'éditeur de VS toutes les
fonctionalités de emacs ou de vim, sans utiliser les sources de
ces éditeurs. Mais il ne le fait pas, ne me démande pas
pourquoi.
--
James Kanze
Senhon
> On Dec 1, 2:27 pm, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
> wrote:
>
>
> C'est surtout une fonctionalit� de l'�diteur, je crois.
non de l'IDE.
Dans un "environnement de d�veloppement int�gr�", je ne vais pas m'enliser
dans une discussion pour diff�rentier le debugger de l'�diteur.
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
965f06ec-1b80-40be...@r5g2000yqb.googlegroups.com...
> On Dec 1, 2:38 pm, "Senhon" <N...@Nul.Nul> wrote:
>> groupe de discussion : hf3950$up...@news.cict.fr...
>
>> Lorsque l'on est dans l'IDE je ne voit pas comment on peut
>> ou � une autre. L'avantage de l'IDE : c'est d'�tre � la fois
>
> C'est aussi le d�savantage. On a un outil qui fait moyenement
> tout, mais rien tr�s bien. (Je ne crois pas qu'il faut que ce
> soit le cas, mais dans la pratique, ou bien c'est le cas, ou
> bien l'integration montre ses coutures.)
De quel outil es-tu en train de parler ?
Michael Doubez
Je connais des personnes qui ne jurent que par eclipse. Je ne l'ai
essayé qu'une fois et il me paraissait prometteur mais je n'ai pas
pris le temps d'apprendre a m'en servir.
Et puis je me suis laissé dire qu'on pouvait intégrer vim dedans :)
--
Michael
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
df2de202-0c22-4fa3...@r24g2000yqd.googlegroups.com...
> On Dec 1, 2:29 pm, "Senhon" <N...@Nul.Nul> wrote:
>> discussion :
>> 0c61c942-ea8a-48d9-9fe0-c604470d3...@a32g2000yqm.googlegroups.com...
>
>> > On Dec 1, 10:19 am, "Senhon" <N...@Nul.Nul> wrote:
>> >> message de groupe de discussion :
>> >> ig28h5pns410ne2jgmoq42umc8qs4kr...@4ax.com...
>> >> > On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG <hey...@gmail.com>:
>
>> > fichiers sont dans le projet, etc.
>
>> automatis�s.
>
> Alors, il est vraiment g�nial, parce qu'il peut lire dans ma
> t�te. (Je peux dire � GNU make de prendre tous les .cc dans un
> r�pertoire -- c'est une chose � �viter.)
Nous sommes d'accord il est g�nial.
Il est possible gr�ce aux macros d'ajouter une souplesse difficilement
atteignable autrement.
>> > Travail qui est bien plus facile sous vim que avec la souris.
>
>> C'est ce que je disais, tu essaies de faire comme avec vim.
>
> Ou d'autre chose. Ce qui est certain, c'est que pendant que tu
> saisis le code, il ne faut pas �loigner les mains de la position
> de base sur le clavier, au prix d'une perte de productivit�
> importante.
>
>> Le parall�le programmation C et programmation C++ me parait
>> fort � propos. Utiliser VS comme vim n'a en soit pas
>> d'int�r�t.
>
> Dans le mesure o� on ne le peut pas, parce qu'il n'en a pas les
> fonctionalit�s de base qu'il faut.
Pas compris, de quels fonctionnalit�s parles-tu ?
>
>> Par contre j'ai compris que dans ton cas actuel il ne soit pas
>> simple d'appr�hender tout le potentiel de VS. Pour ce faire
>> il faudrait �tre l'initiateur du projet. Et encore du premier
>> coup cela me semble tr�s improbable, il faudra se casser la
>> t�te, faire plusieurs tentatives, pour parvenir � un r�sultat
>> significatif.
>
>> Les macros de VS c'est du VB, avec l'aide des "objet
>> automation", tu programmes ton outil comme tu le souhaites.
>
> Et les macros de vim, c'est tout ce qui m'offre le syst�me. Y
> compris du code que j'ai �cris en C++, des scripts de shell, et
> que sais-je.
Bah, si tu le dis que tu peux faire aussi bien qu'un IDE.
Oui, c'est th�oriquement faisable, d'ailleurs VS, je ne sais pas en quoi il
�crit, mais, il a �t� �crit, par je ne sais combien de d�veloppeurs, tester
pas je ne sais combien d'�quipes qualification.
De ton cot� tu as d�cid� que ce n'�tait un produit pour toi, soit, c'est ton
droit le plus absolu.
Marc Boyer
Oui et non.
Ca suppose une connaissance sémantique du langage, et à mon
sens, un éditeur ne connait ni C ni C++.
L'intégration (IDE) passe par la possibilité qu'à l'éditeur
à aller discuter avec un analyseur de code.
Senhon
Effectivement partant de z�ro, je pense, malgr� toute l'estime que je te
porte, que 3 semaines est une gageure.
J'ai commenc� avec VC 1.52 ( il y a maintenant pas loin d'une quinzaine
d'ann�es ) ... que j'avais trouv� g�nial � l'�poque. Cela ne m'a pas
emp�cher de gal�rer avec VS2008 ... en tout cas j'ai pass� plus de 3
semaines pour obtenir un r�sultat qui me satisfait, mais encore am�liorable.
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
df2de202-0c22-4fa3...@r24g2000yqd.googlegroups.com...
> On Dec 1, 2:29 pm, "Senhon" <N...@Nul.Nul> wrote:
>> de
>> discussion :
>> 0c61c942-ea8a-48d9-9fe0-c604470d3...@a32g2000yqm.googlegroups.com...
>
Ho ! la co�ncidence, dans la revue Programmez qui vient de sortir :
<citation>
Une table ronde organis�e lors de la derni�re PDC � Los Angeles et
consacr�e au futur du d�veloppement, a eu un r�sultat surprenant. En effet
les d�veloppeurs v�t�rans (et expert) de Redmond, ont insist� sur la valeur
de l'�criture de code � l'ancienne. (Emacs pas mort ;-).
Quelques morceaux choisis:
� Je me battrais si vous essayiez de m'enlever mon �diteur de texte �, a par
exemple affirm� Don Box (COM, Soap, Windows Communication Foundation,
Oslo,...)
� Les environnements de programmation graphiques sont utilisables quand ils
n'ont pas d'utilit�, mais inutilisables lorsqu'ils seraient utiles [...] �
(Jeffrey Snover, cr�ateur de PowerShell)
<citation/>
M�me chez Microsoft le d�bat n'est pas tranch�.
James Kanze
wrote:
> Le 01-12-2009, James Kanze <james.ka...@gmail.com> a écrit :
> > On Dec 1, 2:27 pm, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
> > wrote:
> >> Oui, c'est super utile, mais c'est une fonctionnalité
> >> d'IDE, pas de débogueur.
> > C'est surtout une fonctionalité de l'éditeur, je crois.
> Oui et non.
> Ca suppose une connaissance sémantique du langage, et à mon
> sens, un éditeur ne connait ni C ni C++.
> L'intégration (IDE) passe par la possibilité qu'à l'éditeur
> à aller discuter avec un analyseur de code.
Je comprends ce que tu veux dire, mais dans la pratique,
personne n'appellerait vim un IDE, mais il comprend bien un peu
de C++ (à travers des descriptions de syntaxe, qui servent à
l'indentation et le coloriage), et il communique avec un
analyseur de code qui génère les tags.
En somme, il n'est plus très clair où se trouve la limite.
--
James Kanze
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message
> de groupe de discussion :
> df2de202-0c22-4fa3-879b-b1b9da447...@r24g2000yqd.googlegroups.com...
[...]
> >> He bien, non ! Les déclarations des fichiers dans les
> >> projets sont automatisés.
> > Alors, il est vraiment génial, parce qu'il peut lire dans ma
> > tête. (Je peux dire à GNU make de prendre tous les .cc dans un
> > répertoire -- c'est une chose à éviter.)
> Nous sommes d'accord il est génial.
> Il est possible grâce aux macros d'ajouter une souplesse
> difficilement atteignable autrement.
Un macro qui me lit dans la tête ?
(En ce qui concerne les macros, est-ce que tu as bien compris
que tous les éditeurs dont on parle se programme. À cet égard,
je ne crois pas qu'on puisse dépasser emacs.)
[...]
> >> Le parallèle programmation C et programmation C++ me parait
> >> fort à propos. Utiliser VS comme vim n'a en soit pas
> >> d'intérêt.
> > Dans le mesure où on ne le peut pas, parce qu'il n'en a pas
> > les fonctionalités de base qu'il faut.
> Pas compris, de quels fonctionnalités parles-tu ?
Pour commencer, éditer sans avoir à déplacer mes mains de la
position de base sur le clavier. (En fait, je crois que c'est
possible, mais je ne sais pas le faire, je ne connais personne
qui ne le sait, et je n'en trouve pas de documentation.)
Passer un block de texte à travers un filtre écrit dans un autre
langage (n'importe quel autre langage). Changer de mode sans
déplacer les mains du clavier, pour entrer les commentaires en
mode texte.
> >> Par contre j'ai compris que dans ton cas actuel il ne soit
> >> pas simple d'appréhender tout le potentiel de VS. Pour ce
> >> faire il faudrait être l'initiateur du projet. Et encore du
> >> premier coup cela me semble très improbable, il faudra se
> >> casser la tête, faire plusieurs tentatives, pour parvenir à
> >> un résultat significatif.
> >> Les macros de VS c'est du VB, avec l'aide des "objet
> >> automation", tu programmes ton outil comme tu le souhaites.
> > Et les macros de vim, c'est tout ce qui m'offre le système.
> > Y compris du code que j'ai écris en C++, des scripts de
> > shell, et que sais-je.
> Bah, si tu le dis que tu peux faire aussi bien qu'un IDE.
Non, je dis ça parce que c'est ce que je fais constamment.
> Oui, c'est théoriquement faisable, d'ailleurs VS, je ne sais
> pas en quoi il écrit, mais, il a été écrit, par je ne sais
> combien de développeurs, tester pas je ne sais combien
> d'équipes qualification. De ton coté tu as décidé que ce
> n'était un produit pour toi, soit, c'est ton droit le plus
> absolu.
Ni Vim ni emacs ne sont des produits écrits par moi.
--
James Kanze
Fabien LE LEZ
<james...@gmail.com>:
>Pour commencer, �diter sans avoir � d�placer mes mains de la
>position de base sur le clavier. (En fait, je crois que c'est
>possible,
Bien s�r. On peut tout faire, ne serait-ce qu'en �crivant un nouveau
driver pour le clavier.
luther13
variables.
Un bon debuggueur permet aussi de:
- Modifier � la vol�e la valeur d'une variable lors d'un breakproint
- Verifier la valeur d'une expression.
C'est � mon sens, 2 choses utiles qui ne sont pas faisables par std::cout.
"AG" <hey...@gmail.com> a �crit dans le message de news:
44b90110-2501-4d24...@o31g2000vbi.googlegroups.com...
On Nov 30, 5:10 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
> Ces deux-l� sont extr�mement rares en C++ :
> - � ma connaissance, la seule utilit� de malloc() est de
> permettre la cr�ation de son propre op�rateur new, ce qu'on ne fait
> pas tous les jours ;
> - les histoires de '\0', c'est la cuisine interne de
> std::string, et a priori, ce n'est pas toi (ni moi) qui l'�cris.
Oui, tu auras devin� que j'avais le C en t�te lorsque j'ai �crit
cela...
> As-tu rencontr� un exemple dans la vraie vie ?
�a m'est arriv� de mettre plusieurs jours � trouver un bug dans du
code que je n'ai pas �crit. Et lorsque le code fait 40k lignes, je ne
vais pas me lancer dans les tests unitaires. Et je pense que cette
situation est fr�quente.
Je suis tout � fait d'accord que la m�thodologie c'est tests
unitaires et compagnie, bonne parole prodigu�e. Je suis aussi
d'accord que pour d�tecter tous les probl�mes de deadlock et de
synchro, c'est pas l'id�al (mais l� on s'�loigne du C++...). Et je
suis aussi d'accord que Valgrind aide beaucoup. Mais je ne n�gligerais
pas le d�bugger pour autant.
Pour moi gdb/ddd ne sont pas pratiques. Celui de Visual Studio l'est.
Dommage que le thread ait �t� d�vi� du sujet initial. j'aurais pens�
qu'il amuserait plus que �a. Je vous posterai ma trouvaille.
AG.
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
5e8c2c51-deda-47bb...@d21g2000yqn.googlegroups.com...
> On Dec 2, 8:50 am, "Senhon" <N...@Nul.Nul> wrote:
>> de groupe de discussion :
>> df2de202-0c22-4fa3-879b-b1b9da447...@r24g2000yqd.googlegroups.com...
>
> [...]
>> difficilement atteignable autrement.
>
> Un macro qui me lit dans la t�te ?
A un certain moment quelque chose va quitter ta t�te pour arriver dans un
fichier.
A ce moment l�, un outil pratique va te permettre de faire � ta place une
quantit� non n�gligeables d'actions.
>
> (En ce qui concerne les macros, est-ce que tu as bien compris
> que tous les �diteurs dont on parle se programme. � cet �gard,
> je ne crois pas qu'on puisse d�passer emacs.)
>
Bon, d'accord, emacs est le meilleur �diteur.
> [...]
>
>> Oui, c'est th�oriquement faisable, d'ailleurs VS, je ne sais
>> pas en quoi il �crit, mais, il a �t� �crit, par je ne sais
>> combien de d�veloppeurs, tester pas je ne sais combien
>> d'�quipes qualification. De ton cot� tu as d�cid� que ce
>> n'�tait un produit pour toi, soit, c'est ton droit le plus
>> absolu.
>
> Ni Vim ni emacs ne sont des produits �crits par moi.
Pourtant je l'aurais pari� :-)
Et ni l'un ni l' autre ne sont des debugger graphique.
James Kanze
> L'utilité du debuggueur n'est pas seulement de voir les
> valeurs de variables.
> Un bon debuggueur permet aussi de:
> - Modifier à la volée la valeur d'une variable lors d'un breakproint
> - Verifier la valeur d'une expression.
> C'est à mon sens, 2 choses utiles qui ne sont pas faisables
> par std::cout.
La deuxième, certes que oui. Pour la première, il faut se servir
de std::cin.
L'utilité du déboggueur, c'est surtout quand tu ne connais pas
le code assez pour savoir quelles expressions tu dois afficher.
Dans ce cas-là, c'est assez fastidieux d'avoir à insérer des
sorties et récompiler, seulement pour constater que l'expression
que tu as affichée n'était pas celle qu'il te fallait.
En principe, ça peut arriver aussez dans le code que tu connais,
mais dans les faits, c'est assez rare. Si on a une bonne idée de
comment le code fonctionne, on reconnaît la plupart du temps
d'où vient l'erreur simplement d'après les symptomes, une fois
qu'on les a cernés assez pour pouvoir rendre l'erreur
reproduisable.
--
James Kanze
Michael Doubez
Je rajouterais (dans ce que j'utilise avec vim):
- la selection en carré
- le marquage de position
- l'insertion en colonne
- les registres de copier/coller
- les raccourcis et combinaisons de touche infinis
- localement à un type de fichier (en fonction de l'extension ou à la
demande)
+ la correction automatique d'erreur courrante de typo (inlcude ->
include)
+ Le chargement de macros/templates locales
--
Michael
Michael Doubez
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message de groupe de
> discussion :
> 5e8c2c51-deda-47bb-b3a5-93e60fadd...@d21g2000yqn.googlegroups.com...
>
> > On Dec 2, 8:50 am, "Senhon" <N...@Nul.Nul> wrote:
> >> de groupe de discussion :
> >> df2de202-0c22-4fa3-879b-b1b9da447...@r24g2000yqd.googlegroups.com...
>
> > [...]
> >> difficilement atteignable autrement.
>
> > Un macro qui me lit dans la tête ?
>
> A un certain moment quelque chose va quitter ta tête pour arriver dans un
> fichier.
> A ce moment là, un outil pratique va te permettre de faire à ta place une
> quantité non négligeables d'actions.
A un certain moment quelque chose a quitté la tête de quelqu'un pour
faire quelque chose et ce quelqu'un en a fait une extension que je
peux utiliser.
Et je vais l'utiliser avec la souplesse que m'autorise l'éditeur.
> > (En ce qui concerne les macros, est-ce que tu as bien compris
> > que tous les éditeurs dont on parle se programme. À cet égard,
> > je ne crois pas qu'on puisse dépasser emacs.)
>
> Bon, d'accord, emacs est le meilleur éditeur.
La question n'est pas tranché :)
http://en.wikipedia.org/wiki/Editor_war
> > [...]
>
> >> Oui, c'est théoriquement faisable, d'ailleurs VS, je ne sais
> >> pas en quoi il écrit, mais, il a été écrit, par je ne sais
> >> combien de développeurs, tester pas je ne sais combien
> >> d'équipes qualification. De ton coté tu as décidé que ce
> >> n'était un produit pour toi, soit, c'est ton droit le plus
> >> absolu.
>
> > Ni Vim ni emacs ne sont des produits écrits par moi.
>
> Pourtant je l'aurais parié :-)
Mais il sont open source et on peux les modifier (en théorie parce
qu'en pratique il faut quand même s'investir).
> Et ni l'un ni l' autre ne sont des debugger graphique.
Ah bon ?
Clewn pour vim:
http://sourceforge.net/project/screenshots.php?group_id=111038
ou vimgdb (en version text)
http://www.flickr.com/photos/kent-chen/4037721844/sizes/l/
(X)emacs a un très bon support pour gdb en standard:
http://www.linuxjournal.com/article/7876
Et puis sous gdb, pour avoir une belle fenêtre il suffit de faire:
wh (ou CTRL-X CTRL-A)
Et utiliser focus (src/cmd) pour changer de fenêtre.
--
Michael
Senhon
"Michael Doubez" <michael...@free.fr> a �crit dans le message de groupe
de discussion :
cbc267ec-222d-41c2...@p35g2000yqh.googlegroups.com...
> On 3 d�c, 09:50, "Senhon" <N...@Nul.Nul> wrote:
>> "James Kanze" <james.ka...@gmail.com> a �crit dans le message de groupe
>> de
>> discussion :
>> 5e8c2c51-deda-47bb-b3a5-93e60fadd...@d21g2000yqn.googlegroups.com...
>>
>>
>>
>> > Ni Vim ni emacs ne sont des produits �crits par moi.
>> Et ni l'un ni l' autre ne sont des debugger graphique.
>
Par anticipation : pardon pour le capillotractage
> Ah bon ?
Ben oui :-))
> Clewn pour vim:
> http://sourceforge.net/project/screenshots.php?group_id=111038
> ou vimgdb (en version text)
> http://www.flickr.com/photos/kent-chen/4037721844/sizes/l/
>
> (X)emacs a un tr�s bon support pour gdb en standard:
> http://www.linuxjournal.com/article/7876
>
> Et puis sous gdb, pour avoir une belle fen�tre il suffit de faire:
> wh (ou CTRL-X CTRL-A)
> Et utiliser focus (src/cmd) pour changer de fen�tre.
Plus s�rieusement :
Je ne veux surtout pas dire que seul VS permet de bosser avec plaisir.
Mais je pense qu'un __int�gr�__ comme VS m�rite mieux que d'�tre vu comme
�diteur peu pratique, alors que c'est une merveille.
Michael Doubez
> "Michael Doubez" <michael.dou...@free.fr> a écrit dans le message de groupe
> de discussion :
> > On 3 déc, 09:50, "Senhon" <N...@Nul.Nul> wrote:
> >> "James Kanze" <james.ka...@gmail.com> a écrit dans le message de groupe
> >> de
> >> discussion :
> >> 5e8c2c51-deda-47bb-b3a5-93e60fadd...@d21g2000yqn.googlegroups.com...
>
> >> > Ni Vim ni emacs ne sont des produits écrits par moi.
> >> Et ni l'un ni l' autre ne sont des debugger graphique.
>
> Par anticipation : pardon pour le capillotractage
>
> > Ah bon ?
>
> Ben oui :-))
Je pense voir que tu joues sur les mots mais dans ce cas ...
Pas plus que VS ne l'est. Le compilateur C++ est en fait sous forme de
lib externe qui peut être exploitée par cl.exe ou VS; et , je n'en
suis pas sûr, il me semble que c'est vrai aussi pour le debugger avec
WinDbg.
En fait VS est un FrontEnd :) Ce qui parrait logique pour un IDE.
[snip]
> Plus sérieusement :
>
> Je ne veux surtout pas dire que seul VS permet de bosser avec plaisir.
> Mais je pense qu'un __intégré__ comme VS mérite mieux que d'être vu comme
> éditeur peu pratique, alors que c'est une merveille.
C'est peut être une merveille d'intégration mais un pauvre éditeur. Et
l'édition est, en fin de compte, une bonne partie du travail.
De plus, quand on le compare avec d'autres IDE comme eclipse (ou pour
le C/C++ uniquement CodeBlock), il ne me semble pas apporter tant que
ça mais ce n'est pas le genre d'environement que j'utilise tous les
jours.
Je ne crache pas sur VS, je le met juste à sa juste place qui est
d'être un IDE. D'ailleurs il est possible de mettre un vim-like dans
VS (VIEmu à 100$) pour l'édition.
En fait, le seul reproche que je lui ferais est son système de
configuration qui est tellement éclaté que je trouve difficile de
localiser un paramètre.
--
Michael
Senhon
"Michael Doubez" <michael...@free.fr> a �crit dans le message de groupe
de discussion :
e2a03617-f5e9-474e...@j19g2000yqk.googlegroups.com...
> On 3 d�c, 11:56, "Senhon" <N...@Nul.Nul> wrote:
>> "Michael Doubez" <michael.dou...@free.fr> a �crit dans le message de
>> groupe
>> de discussion :
>> > On 3 d�c, 09:50, "Senhon" <N...@Nul.Nul> wrote:
>> >> "James Kanze" <james.ka...@gmail.com> a �crit dans le message de
>> >> groupe
>> >> de
>> >> discussion :
>> >> 5e8c2c51-deda-47bb-b3a5-93e60fadd...@d21g2000yqn.googlegroups.com...
>>
>> >> > Ni Vim ni emacs ne sont des produits �crits par moi.
>> >> Et ni l'un ni l' autre ne sont des debugger graphique.
>>
>> Par anticipation : pardon pour le capillotractage
>>
>> > Ah bon ?
>>
>> Ben oui :-))
>
> Je pense voir que tu joues sur les mots mais dans ce cas ...
Oui, j'avais essayer de pr�venir, et j'avais rajouter in smiley.
>
> Pas plus que VS ne l'est. Le compilateur C++ est en fait sous forme de
> lib externe qui peut �tre exploit�e par cl.exe ou VS; et , je n'en
> suis pas s�r, il me semble que c'est vrai aussi pour le debugger avec
> WinDbg.
Joli :-)
>
> En fait VS est un FrontEnd :) Ce qui parrait logique pour un IDE.
>
> [snip]
>> Plus s�rieusement :
>>
>> Je ne veux surtout pas dire que seul VS permet de bosser avec plaisir.
>> Mais je pense qu'un __int�gr�__ comme VS m�rite mieux que d'�tre vu comme
>> �diteur peu pratique, alors que c'est une merveille.
>
> C'est peut �tre une merveille d'int�gration mais un pauvre �diteur
Ok, c'est bon, ... il va �tre difficile de s'entendre sur ce qu'est un bon
�diteur.
>. Et
> l'�dition est, en fin de compte, une bonne partie du travail.
>
> De plus, quand on le compare avec d'autres IDE comme eclipse (ou pour
> le C/C++ uniquement CodeBlock), il ne me semble pas apporter tant que
> �a mais ce n'est pas le genre d'environement que j'utilise tous les
> jours.
Je ne sais pas si c'est ton cas : mais l� j'aurais tendance � dire : "tu ne
l'a pas assez pratiquer, et c'est pour cette raison que tu le juges pi�tre
�diteur".
> Je ne crache pas sur VS, je le met juste � sa juste place qui est
> d'�tre un IDE. D'ailleurs il est possible de mettre un vim-like dans
> VS (VIEmu � 100$) pour l'�dition.
Comme quoi, il peut en faire des choses ! Personnellement, cela ne me
surprend pas.
Par contre ce qui m'interpelle c'est penser que derri�re ce comportement (
celui de vouloir garder � tout prix une interface utilisateur ) il peut y
avoir des passionn�s pr�t � s'investir pour retrouver leur outil de
pr�dilection. ( NB : J'ai bien vu que pour le cas que tu cites la passion
est peut-�tre un peu p�cuniaire aussi :-) .
> En fait, le seul reproche que je lui ferais est son syst�me de
> configuration qui est tellement �clat� que je trouve difficile de
> localiser un param�tre.
Houlala, effectivement, si d�j�, rien que la configuration te pose un souci
...
Alain Ketterlin
> Je travaille dans une équipe de personnes pour lesquels le débugger
> n'est pas l'outil qui tombe sous le sens lorsqu'il s'agit de trouver
> les bugs des outils qu'ils ont développé.
>
> Afin de les sensibiliser, je recherche un exemple de bug difficile
> (voir impossible) a détecter via des printf()/cout qui n'afficheraient
> que les contenus des variables. (Je me rends bien compte qu'on doit
> pouvoir tout débugger avec printf()/cout, mais il faut parfois
> afficher les adresses des variable (en plus de leur valeur), voir
> parfois la mémoire à certains endroits.)
Quelqu'un en a peut-être déjà parlé, j'avoue que je n'ai pas lu tout le
thread...
Le top, c'est les "watchpoints" de gdb (et d'autres debuggers
certainement). Ca te permet de surveiller un morceau de mémoire (y
compris si tu n'as plus de variable qui y pointe). Et si tu reste
raisonnable, c'est fait en hard.
Pour l'exemple, tu fais deux tableaux sur la pile, et une écriture qui
déborde du premier dans le deuxième, qui est sous surveillance.
On peut sûrement faire cela avec des printf.
-- Alain.
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message
> de groupe de discussion :
> 5e8c2c51-deda-47bb-b3a5-93e60fadd...@d21g2000yqn.googlegroups.com...
> > On Dec 2, 8:50 am, "Senhon" <N...@Nul.Nul> wrote:
> >> "James Kanze" <james.ka...@gmail.com> a écrit dans le message
> >> de groupe de discussion :
> >> df2de202-0c22-4fa3-879b-b1b9da447...@r24g2000yqd.googlegroups.com...
> > [...]
> >> Nous sommes d'accord il est génial.
> >> Il est possible grâce aux macros d'ajouter une souplesse
> >> difficilement atteignable autrement.
> > Un macro qui me lit dans la tête ?
> A un certain moment quelque chose va quitter ta tête pour
> arriver dans un fichier. A ce moment là, un outil pratique va
> te permettre de faire à ta place une quantité non négligeables
> d'actions.
Oui. Et c'est là que brille les outils Unix (en général).
> > (En ce qui concerne les macros, est-ce que tu as bien
> > compris que tous les éditeurs dont on parle se programme. À
> > cet égard, je ne crois pas qu'on puisse dépasser emacs.)
> Bon, d'accord, emacs est le meilleur éditeur.
Le meilleur éditeur, je n'irais pas jusqu'à là. En fait, je
préfère vim. Mais c'est certainement le plus configurable, et le
plus extensible. (Ensuite, il faut se poser la question : est-ce
qu'il vaut mieux encore une fonctionnalité de plus dans
l'éditeur, ou plutôt un programme général, qu'on peut invoquer
depuis l'éditeur, ou ailleurs.)
> > [...]
> >> Oui, c'est théoriquement faisable, d'ailleurs VS, je ne
> >> sais pas en quoi il écrit, mais, il a été écrit, par je ne
> >> sais combien de développeurs, tester pas je ne sais combien
> >> d'équipes qualification. De ton coté tu as décidé que ce
> >> n'était un produit pour toi, soit, c'est ton droit le plus
> >> absolu.
> > Ni Vim ni emacs ne sont des produits écrits par moi.
> Pourtant je l'aurais parié :-)
> Et ni l'un ni l' autre ne sont des debugger graphique.
Ce qui n'est important que dans la mesure où on se sert des
débogueurs graphiques. (Mais a propos : comment activer les
fonctionalités graphiques de VS ? Ou est-ce que tu veux dire
simplement qu'il est integrée dans un environement graphique,
qui m'oblige constamment à me déplacer les mains du clavier, et
qui ne me permet pas à voir ce qui m'intéresse, parce qu'il n'y
a pas d'entrée pour ça dans les menus, et qu'il n'y a pas de
ligne de commande pour entrer les expressions arbitraires ?)
--
James Kanze
James Kanze
> On 3 déc, 11:56, "Senhon" <N...@Nul.Nul> wrote:
[...]
> > Je ne veux surtout pas dire que seul VS permet de bosser
> > avec plaisir. Mais je pense qu'un __intégré__ comme VS
> > mérite mieux que d'être vu comme éditeur peu pratique, alors
> > que c'est une merveille.
> C'est peut être une merveille d'intégration mais un pauvre
> éditeur. Et l'édition est, en fin de compte, une bonne partie
> du travail.
C'est un peu ce que je disais avant : dans les IDE, ou bien les
outils de base ne sont pas à la hauteur, ou bien l'integration
n'est pas si total que ça. Dans le cas de VS, l'integration,
c'est le top. Malheureusement, les outils de base ne le sont
pas : le débogueur est loin de valoir ce qu'on connaît comme
débogueur stand-alone, et quant à l'éditeur, n'en parlons pas.
> De plus, quand on le compare avec d'autres IDE comme eclipse
> (ou pour le C/C++ uniquement CodeBlock), il ne me semble pas
> apporter tant que ça mais ce n'est pas le genre d'environement
> que j'utilise tous les jours.
Si tu tiens à l'integration total, VS est quand mėme dans un
autre catégorie par rapport à Eclipse ou Sun Studios. C'est un
peu comme si la configurabilité est ton seul critère, il n'y a
qu'emacs comme éditeur. Dans la pratique, en revanche, je trouve
que l'integration n'apporte pas autant que ça (au moins quand
les parties individueles sont particulièrement faiblardes, comme
l'éditeur de VS), et la configurabilité n'est pas la fin des
fins dans un éditeur (pourvu qu'il me permet à piper des blocs
de texte à travers des filtres externes, afin que je puisse
faire n'importe quoi qui lui manque).
--
James Kanze
James Kanze
> On 2 déc, 18:18, James Kanze <james.ka...@gmail.com> wrote:
[...]
> > > > Dans le mesure où on ne le peut pas, parce qu'il n'en a pas
> > > > les fonctionalités de base qu'il faut.
> > > Pas compris, de quels fonctionnalités parles-tu ?
> > Pour commencer, éditer sans avoir à déplacer mes mains de la
> > position de base sur le clavier. (En fait, je crois que c'est
> > possible, mais je ne sais pas le faire, je ne connais personne
> > qui ne le sait, et je n'en trouve pas de documentation.)
> > Passer un block de texte à travers un filtre écrit dans un autre
> > langage (n'importe quel autre langage). Changer de mode sans
> > déplacer les mains du clavier, pour entrer les commentaires en
> > mode texte.
> Je rajouterais (dans ce que j'utilise avec vim):
> - la selection en carré
> - le marquage de position
> - l'insertion en colonne
> - les registres de copier/coller
> - les raccourcis et combinaisons de touche infinis
> - localement à un type de fichier (en fonction de l'extension ou à la
> demande)
> + la correction automatique d'erreur courrante de typo (inlcude ->
> include)
> + Le chargement de macros/templates locales
Et sans doute d'autres:-). Pour commencer, le fait d'utiliser
le même éditeur pour la documentation et pour le codage. (Mais
on peut probablement écrire du HTML avec l'éditeur de VS.) Mais
la chose la plus importante quand je saisis du code, c'est de ne
pas avoir à me déplacer les doigts du clavier. Et la deuxième,
c'est bien de pouvoir utiliser des autres outils du système sur
le texte.
Prenons quelques exemples simple :
-- J'ouvre un nouveau fichier .hh (ou .h ou .hpp, comme on
veut). Du coup, dès que j'ai fini d'entrer le nom du
fichier, il est initialisé avec quelque chose du genre :
/
****************************************************************************/
/* File:
SlidingWindow.hh */
/* Author: J.
Kanze */
/* Date:
13/05/2008 */
/* Copyright (c) 2008 James
Kanze */
/*
------------------------------------------------------------------------
*/
//!@file SlidingWindow.hh
#ifndef GB_SlidingWindow_hh_20080513kCaQSjjepcdkxiepOjTNfMTj
#define GB_SlidingWindow_hh_20080513kCaQSjjepcdkxiepOjTNfMTj
#endif
// Local Variables: --- for emacs
// mode: c++ --- for emacs
// tab-width: 8 --- for emacs
// End: --- for emacs
// vim: set ts=8 sw=4 filetype=cpp: --- for vim
Là dedans, il y a des sorties d'un programme écrit en C++,
une lecture de /dev/random avec formattage après au moyen de
tr et je ne me rappelle plus quoi d'autre. (D'ailleurs, le
texte dépend du répertoire où l'en-tête est créé, de façon à
utiliser des conventions différentes selon le projet.)
-- Je vais définir une classe nouvelle. Alors, je passe en mode
texte (une seule touche), pour supprimer l'indentation selon
les règles C++, et j'entre la description de la classe en
format libre, sans m'occuper du formattage. Ensuite, une
touche de nouveau pour quitter le commentaire, et le texte
est formatté et mis en commentaire automatiquement.
De même, j'ai un programme pour aligner les =, qui sert aussi à
aligner les initialisateurs d'un tableau de struct. Et ce n'est
pas rare que je me sers d'awk et compagnie pour générer des
tableaux ; c'est beaucoup moins fatiguant, et surtout il mène à
moins d'erreurs, que d'entrer tout à la main.
--
James Kanze
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
8eed8ff8-13d3-4bc6...@m26g2000yqb.googlegroups.com...
> On Dec 3, 8:50 am, "Senhon" <N...@Nul.Nul> wrote:
>> de groupe de discussion :
>> 5e8c2c51-deda-47bb-b3a5-93e60fadd...@d21g2000yqn.googlegroups.com...
>
>> > On Dec 2, 8:50 am, "Senhon" <N...@Nul.Nul> wrote:
>> >> de groupe de discussion :
>> >> df2de202-0c22-4fa3-879b-b1b9da447...@r24g2000yqd.googlegroups.com...
>
>> > [...]
>> >> difficilement atteignable autrement.
>
>> > Un macro qui me lit dans la t�te ?
>
>> A un certain moment quelque chose va quitter ta t�te pour
>> arriver dans un fichier. A ce moment l�, un outil pratique va
>> te permettre de faire � ta place une quantit� non n�gligeables
>
> Oui. Et c'est l� que brille les outils Unix (en g�n�ral).
Bon soit, les outils Unix brillent plus.
>
>> > (En ce qui concerne les macros, est-ce que tu as bien
>> > compris que tous les �diteurs dont on parle se programme. �
>> > cet �gard, je ne crois pas qu'on puisse d�passer emacs.)
>
>> Bon, d'accord, emacs est le meilleur �diteur.
>
> Le meilleur �diteur, je n'irais pas jusqu'� l�. En fait, je
> pr�f�re vim. Mais c'est certainement le plus configurable, et le
> plus extensible. (Ensuite, il faut se poser la question : est-ce
> qu'il vaut mieux encore une fonctionnalit� de plus dans
> l'�diteur, ou plut�t un programme g�n�ral, qu'on peut invoquer
> depuis l'�diteur, ou ailleurs.)
Bon soit, il n'y a que vim ou emacs qui font �a mieux que les autres.
>
>> > [...]
>
>> >> Oui, c'est th�oriquement faisable, d'ailleurs VS, je ne
>> >> sais pas en quoi il �crit, mais, il a �t� �crit, par je ne
>> >> sais combien de d�veloppeurs, tester pas je ne sais combien
>> >> d'�quipes qualification. De ton cot� tu as d�cid� que ce
>> >> n'�tait un produit pour toi, soit, c'est ton droit le plus
>> >> absolu.
>
>> > Ni Vim ni emacs ne sont des produits �crits par moi.
>
>> Pourtant je l'aurais pari� :-)
>
>> Et ni l'un ni l' autre ne sont des debugger graphique.
>
> Ce qui n'est important que dans la mesure o� on se sert des
> d�bogueurs graphiques. (Mais a propos : comment activer les
> fonctionalit�s graphiques de VS ? Ou est-ce que tu veux dire
> simplement qu'il est integr�e dans un environement graphique,
> qui m'oblige constamment � me d�placer les mains du clavier, et
> qui ne me permet pas � voir ce qui m'int�resse, parce qu'il n'y
> a pas d'entr�e pour �a dans les menus, et qu'il n'y a pas de
> ligne de commande pour entrer les expressions arbitraires ?)
Ce que je veux dire c'est : d�glingue tout ce que tu veux de VS, m�me sans
savoir. M�me jusqu'� l'absurde.
Je ne suis pas commercial, je n'ai rien � vendre.
Je ne sui pas formatteur VS, non plus.
Tu n'as pas su trouver :
- comment ouvrir la fen�tre de commande-ligne
- tu ne sais pas comment travailler en gardant les mains sur le clavier.
- l'environnement graphique te limite plus qu'il ne t'apporte.
A ce niveau, je dis stop, laisse tomber ... au moins pour l'instant. Un jour
peut-�tre, tu auras une meilleur orientation, moins braqu�, et l� les choses
iront plus facilement.
Si cela peut te rassurer :
- la fen�tre commande-ligne j'ai pas cherch� � comprendre ce qu'elle
fait l�, pour moi c'est une relique du pass�, je ne l'ai jamais utilis�e
- Je suis comme toi, si je dois quitter le clavier des doigts cela
m'agace. Mais je n'ai pas ce ressenti lors de l'utilisation de VS, bien au
contraire.
- Je ne connais pas ton mat�riel, sur le mien j'affiche 2 sources, de
front sur toute la hauteur, sans que cela se chevauche horizontalement, sans
que cela se masque ou g�ne � la lecture, plus les fen�tres propres � VS que
j'ai choisis de visualiser, et il me reste encore de la place, c'est
tellement agr�able que de songer � un retour en arri�re et c'est la d�prime
assurer.
Je ne suis pas pr�dicateur non plus, pour chercher � vouloir te convertir �
truc que tu veux pas.
De Vim je n'en dirait aucun mal, et si c'est ce qui te plait, pour moi cela
me va tr�s bien.
Senhon
"James Kanze" <james...@gmail.com> a écrit dans le message de groupe de
discussion :
4a1092a0-dbfb-4b56...@c3g2000yqd.googlegroups.com...
> On Dec 3, 12:07 pm, Michael Doubez <michael.dou...@free.fr> wrote:
>> On 3 déc, 11:56, "Senhon" <N...@Nul.Nul> wrote:
>
> [...]
>> > Je ne veux surtout pas dire que seul VS permet de bosser
>> > avec plaisir. Mais je pense qu'un __intégré__ comme VS
>> > mérite mieux que d'être vu comme éditeur peu pratique, alors
>> > que c'est une merveille.
>
>> C'est peut être une merveille d'intégration mais un pauvre
>> éditeur. Et l'édition est, en fin de compte, une bonne partie
>> du travail.
>
> C'est un peu ce que je disais avant : dans les IDE, ou bien les
> outils de base ne sont pas à la hauteur, ou bien l'integration
> n'est pas si total que ça. Dans le cas de VS, l'integration,
> c'est le top. Malheureusement, les outils de base ne le sont
> pas : le débogueur est loin de valoir ce qu'on connaît comme
> débogueur stand-alone, et quant à l'éditeur, n'en parlons pas.
Ou tout simplement que tu ne sais pas t'en servir.
Alexandre Bacquart
Ou plus simplement encore que tu ne sais pas te servir d'Emacs (sur
lequel, soit dit en passant, on débuggait du C avec gdb (une référence
encore aujourd'hui) bien avant que M$ décide de faire le moindre
clickodrome).
En fait, je crois que le moment où les gens qui considèrent les shell
comme des "reliques du passé" font tilt, c'est le jour où ils voient un
habitué du shell faire en 10 secondes ce qui aurait pris 2 heures avec
n'importe quelle interface graphique (encore faut-il comprendre ce qui
se passe, n'est-ce pas). Voir un Emacs/Vim-guru coder aussi, ça peut
réveiller son homme ;)
--
Alex
Senhon
"Alexandre Bacquart" <tek...@free.DELETEME.fr> a écrit dans le message de
groupe de discussion : 4b17f6a5$0$18404$426a...@news.free.fr...
> Senhon wrote:
>>
>> "James Kanze" <james...@gmail.com> a écrit dans le message de groupe
>> de discussion :
>> 4a1092a0-dbfb-4b56...@c3g2000yqd.googlegroups.com...
>>> On Dec 3, 12:07 pm, Michael Doubez <michael.dou...@free.fr> wrote:
>>>> On 3 déc, 11:56, "Senhon" <N...@Nul.Nul> wrote:
>>>
>>> [...]
>>>> > Je ne veux surtout pas dire que seul VS permet de bosser
>>>> > avec plaisir. Mais je pense qu'un __intégré__ comme VS
>>>> > mérite mieux que d'être vu comme éditeur peu pratique, alors
>>>> > que c'est une merveille.
>>>
>>>> C'est peut être une merveille d'intégration mais un pauvre
>>>> éditeur. Et l'édition est, en fin de compte, une bonne partie
>>>> du travail.
>>>
>>> C'est un peu ce que je disais avant : dans les IDE, ou bien les
>>> outils de base ne sont pas à la hauteur, ou bien l'integration
>>> n'est pas si total que ça. Dans le cas de VS, l'integration,
>>> c'est le top. Malheureusement, les outils de base ne le sont
>>> pas : le débogueur est loin de valoir ce qu'on connaît comme
>>> débogueur stand-alone, et quant à l'éditeur, n'en parlons pas.
>>
>> Ou tout simplement que tu ne sais pas t'en servir.
>
> Ou plus simplement encore que tu ne sais pas te servir d'Emacs (sur
Oui, très exactement, je le connais pas. Et c'est bien pour cela que je n'en
dirais pas de mal.
Et c'est ce point qui me chagrine quand je lis des contres vérités juste
parce que c'est graphique et cliquable, ou bien juste parce que c'est
propriétaire et pas open source.
> lequel, soit dit en passant, on débuggait du C avec gdb (une référence
> encore aujourd'hui) bien avant que M$ décide de faire le moindre
> clickodrome).
>
> En fait, je crois que le moment où les gens qui considèrent les shell
> comme des "reliques du passé" font tilt, c'est le jour où ils voient un
Je n'ai pas dis le shell est une relique du passé.
J'ai dis : la fenêtre commande-ligne de VS, je n'en ai jamais eu besoin.
> habitué du shell faire en 10 secondes ce qui aurait pris 2 heures avec
Et vice-versa.
Surtout que je n'ai aucun soucis avec les scripts, à choisir je préfère
écrire un script que de taper en direct live au prompt.
> n'importe quelle interface graphique (encore faut-il comprendre ce qui
> se passe, n'est-ce pas). Voir un Emacs/Vim-guru coder aussi, ça peut
> réveiller son homme ;)
Pour moi, il est trop tard.
Aujourd'hui, si je dois faire un développement pour linux, je préfère le
faire avec VS paramétré pour qu'il compile en parallèle et pour Windows et
pour linux.
Cela réglant rapidement les problèmes de portage.
Et je dis bien j'appui sur la touche F7 et ca compile windows et linux dans
la même foulé.
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message de groupe de
> discussion :
> 4a1092a0-dbfb-4b56-b617-01e1c9e69...@c3g2000yqd.googlegroups.com...
Peut-être. Mais alors, aucun des personnes autour de moi non
plus. Mais j'ai bien dit ce qui me manquait, et personne n'ait
pû me montrer comment le faire. Et les points forts que tu
reclamais pour VS sont bien présent dans tous les éditeurs que
je connais.
--
James Kanze
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
d02c6c9f-6479-4c1f...@g26g2000yqe.googlegroups.com...>> > > > Dans le mesure o� on ne le peut pas, parce qu'il n'en a pas
>> > > > les fonctionalit�s de base qu'il faut.
>> > > Pas compris, de quels fonctionnalit�s parles-tu ?
>
>
> Prenons quelques exemples simple :
>
> -- J'ouvre un nouveau fichier .hh (ou .h ou .hpp, comme on
> fichier, il est initialis� avec quelque chose du genre :
>
> /
> ****************************************************************************/
> /* File:
> SlidingWindow.hh */
> /* Author: J.
> Kanze */
> /* Date:
> 13/05/2008 */
> /* Copyright (c) 2008 James
> Kanze */
> /*
> ------------------------------------------------------------------------
> */
> //!@file SlidingWindow.hh
>
> #ifndef GB_SlidingWindow_hh_20080513kCaQSjjepcdkxiepOjTNfMTj
> #define GB_SlidingWindow_hh_20080513kCaQSjjepcdkxiepOjTNfMTj
>
> #endif
> // Local Variables: --- for emacs
> // mode: c++ --- for emacs
> // tab-width: 8 --- for emacs
> // End: --- for emacs
> // vim: set ts=8 sw=4 filetype=cpp: --- for vim
>
Dans le m�me ordre : dans un source je tape la d�claration d'une classe.
L'appuie du raccourci ad-hoc va permettre :
- Si c'est une nouvelle classe, de cr�er et de renseigner les fichiers
de d�claration et de d�finition suivant un patron perso, et de l'ajouter �
une base de donn�e perso.
- La base de donn�e permet alors de retrouver le chemin, un param�trage
perso, et �viter les doublons, des classes d�j� cr�es.
- d'inclure aux endroits qui vont bien les "include" qui vont bien.
- d'ajouter au projet le(s) fichier(s) si cela n'a pas �t� d�j� fait
auparavant, permettant la compilation imm�diate, m�me si la classe ne
dispose que des constructeurs par d�faut que j'ai voulu dans le patron.
Les patrons que j'ai d�finis sont un peu plus "�toff�s" que celui produit
dans ici, mais bon, je le dis accessoirement, je ne sais pas si James Kanze
a d�voil� tout son patron.
Et le "param�trage perso" permet de traiter de 3 fa�ons diff�rentes la
marche � suivre.
Et ce par une combinaison de touche r�alis� d'une main.
Mais comme je le disais, c'est un engrenage ou une fois mis le doigts ... Du
coup �a commence � me trottiner dans la t�te que " pourquoi devoir lancer
cette op�ration par un raccourci, alors que cela pourrait se faire tout seul
".
J'ai aussi des raccourcis pour les fonction membres, l'ajout � la vol�e
d'une propri�t� sans devoir aller chercher le header, la transformation
d'une classe en classe g�n�rique.
D'autres traitements moins g�n�raux, plus adapt�s � mes applis, plus ou
moins complexes. En fait, tr�s rapidement je script, ce qui me permet de
rejouer ou de v�rifier que je n'ai pas taper un c....ie.
> De m�me, j'ai un programme pour aligner les =, qui sert aussi �
> aligner les initialisateurs d'un tableau de struct. Et ce n'est
> pas rare que je me sers d'awk et compagnie pour g�n�rer des
> tableaux ; c'est beaucoup moins fatiguant, et surtout il m�ne �
> moins d'erreurs, que d'entrer tout � la main.
C'est aussi mon avis la machine fait mieux que nous, donc plus elle fait
mieux c'est.
James Kanze
> "Alexandre Bacquart" <tek...@free.DELETEME.fr> a écrit dans le message de
[...]
> > Ou plus simplement encore que tu ne sais pas te servir
> > d'Emacs (sur
> Oui, très exactement, je le connais pas. Et c'est bien pour
> cela que je n'en dirais pas de mal. Et c'est ce point qui me
> chagrine quand je lis des contres vérités juste parce que
> c'est graphique et cliquable, ou bien juste parce que c'est
> propriétaire et pas open source.
Mais quelles contre-vérités ? On ne critique pas qu'il soit
graphique et cliquable -- tous les éditeurs que je connais
offrent ces possibilités aujourd'hui. On le critique parce qu'il
n'est que graphique et cliquable, alors qu'il ne faut pas avoir
besoin de s'éloigner les doigts de la position de base sur le
clavier. (Je critique emacs aussi un peu à cet égard, parce que
des coups de ALT-SHIFT-META et un caractère contortionne les
doigts d'une façon qui leur fait perdre la position de base.
Mais c'est toujours moins embêtant que d'avoir à prendre la
souris ou des touches de fleche.) On le critique parce qu'il
n'est pas integré dans un environement puissant -- cmd.exe a un
retard important par rapport à Bash ou le shell de Bourne, et
même cmd.exe n'est pas accessible directement depuis VS.
À titre d'exemple, d'un problème que j'ai eu hier : suite à la
modification d'un macro, il fallait que j'ajoute un ';' à la fin
de la ligne de toutes les lignes qui l'invoquaient dans le
projet. (Étant donné l'utilisation du macro, on pourrait être
assez sûr qu'une ligne qui l'invoquait ne faisait que ça.) Sous
Unix, je l'aurais fait en une quinzaine de sécondes, sans
quitter l'éditeur où j'étais, et sans éloigner mese mains du
clavier, avec quelque chose du genre :
:args ! find . -name '*.cpp' -o -name '*.h' | xargs egrep -l
'DECLARE_TOTO'
:argdo g/DECLARE_TOTO/s/$/;/
C'est du vim, sur une machine avec un shell Unixien, mais je
suis assez sûr qu'on peut faire la même chose en emacs (à
condition d'avoir le shell Unixien, évidemment). Sous Windows,
":args" avec ! ne semble ne pas marcher sous vim ; je suis donc
obligé à passer à une fenêtre de shell, et invoquer une nouvelle
instance de vim. Maintenant : comment le faire sous Visual
Studio ? (Je ne dis pas que c'est impossible, mais les gens qui
travaille à côté de moi, et qui semblent connaître VS très bien,
ne savaient pas le faire non plus.)
[...]
> Pour moi, il est trop tard.
> Aujourd'hui, si je dois faire un développement pour linux, je préfère le
> faire avec VS paramétré pour qu'il compile en parallèle et pour Windows et
> pour linux.
> Cela réglant rapidement les problèmes de portage. Et je dis
> bien j'appui sur la touche F7 et ca compile windows et linux
> dans la même foulé.
Ce que je peux dire d'expérience, c'est que tous les
programmeurs vraiment efficaces que j'ai vu se servaient des
outils Unix et la ligne de commande. Y compris sous Windows.
Pourquoi, je n'ai jamais réelement cherché à savoir, mais dans
la mesure où je n'ai jamais vu travailler réelement efficacement
sous Windows, ça ne m'a pas donné une motivation forte à bien
l'apprendre. (Par travailler, ici, j'entends développer des
logiciels. Pour beaucoup d'autres choses, on peut bien être plus
productif sous Windows que sous Unix -- Star Office est loin de
MS Office, par exemple.)
--
James Kanze
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
b8c53ed9-d381-453f...@n35g2000yqm.googlegroups.com...
> On Dec 3, 4:51 pm, "Senhon" <N...@Nul.Nul> wrote:
>> discussion :
>> 4a1092a0-dbfb-4b56-b617-01e1c9e69...@c3g2000yqd.googlegroups.com...
>> > On Dec 3, 12:07 pm, Michael Doubez <michael.dou...@free.fr> wrote:
>
>> > [...]
>> >> > Je ne veux surtout pas dire que seul VS permet de bosser
>> >> > m�rite mieux que d'�tre vu comme �diteur peu pratique, alors
>> >> > que c'est une merveille.
>
>> >> du travail.
>
>> > C'est un peu ce que je disais avant : dans les IDE, ou bien les
>> > n'est pas si total que �a. Dans le cas de VS, l'integration,
>> > c'est le top. Malheureusement, les outils de base ne le sont
>> > d�bogueur stand-alone, et quant � l'�diteur, n'en parlons pas.
>
>> Ou tout simplement que tu ne sais pas t'en servir.
>
> plus. Mais j'ai bien dit ce qui me manquait, et personne n'ait
> reclamais pour VS sont bien pr�sent dans tous les �diteurs que
> je connais.
Comme je le disais je ne suis pas formatteur chez MS.
Et comme tu sembles bien braqu�, je n'ai aucune envie de jouer au jeu cours
apr�s moi que je t'attrape.
Il y a, � mon avis, un minimum d'investissement personnel � effectuer.
J'en parles par exp�rience, j'ai eu le m�me rejet, que toi, avec Eclipse.
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message de groupe de
> discussion :
> 8eed8ff8-13d3-4bc6-8916-d847bb930...@m26g2000yqb.googlegroups.com...
> > On Dec 3, 8:50 am, "Senhon" <N...@Nul.Nul> wrote:
> >> "James Kanze" <james.ka...@gmail.com> a écrit dans le message
> >> de groupe de discussion :
> >> 5e8c2c51-deda-47bb-b3a5-93e60fadd...@d21g2000yqn.googlegroups.com...
> >> > On Dec 2, 8:50 am, "Senhon" <N...@Nul.Nul> wrote:
> >> >> "James Kanze" <james.ka...@gmail.com> a écrit dans le message
> >> >> de groupe de discussion :
> >> >> df2de202-0c22-4fa3-879b-b1b9da447...@r24g2000yqd.googlegroups.com...
> >> > [...]
> Ce que je veux dire c'est : déglingue tout ce que tu veux de
> VS, même sans savoir.
C'est que je suis bien obligé à m'en servir, actuellement, et je
constat une perte énorme de productivité de ma part. En partie,
sans doute, parce que je ne le connais pas, et que je ne sais
pas m'en servir bien. Mais ce que je constate, c'est que mes
collègues, qui viennent tous du monde Windows, n'en savent pas
non plus.
> Même jusqu'à l'absurde. Je ne suis pas commercial, je n'ai
> rien à vendre.
> Je ne sui pas formatteur VS, non plus.
> Tu n'as pas su trouver :
> - comment ouvrir la fenêtre de commande-ligne
J'ai plusieurs fenêtres console ouvertes en permanance, si c'est
ça que tu veux dire. Ce que je ne sais pas faire, c'est de
marquer un bloc dans une source sous l'éditeur VS, puis de le
filtrer à travers une commande (composée souvent, avec des
pipes) arbitraire disponible dans une fenêtre de commande.
> - tu ne sais pas comment travailler en gardant les mains sur le clavier.
Non. Je crois en fait que c'est possible, mais je ne sais pas le
faire, et mes collègues ne savent pas me le montrer.
Pour l'instant, je n'ai pas trouvé de tutorial sur l'éditeur,
qui t'apprend à faire même les choses les plus élémentaire sans
chercher chaque fois dans les menus.
> - l'environnement graphique te limite plus qu'il ne t'apporte.
> A ce niveau, je dis stop, laisse tomber ... au moins pour l'instant. Un jour
> peut-être, tu auras une meilleur orientation, moins braqué, et là les choses
> iront plus facilement.
L'interface graphique peut être très utile dans beaucoup de cas,
mais par la force de chose, elle ne sera jamais aussi puissant
qu'une interface ligne de commande ; dans l'interface graphique,
tu ne pourrais jamais faire que ce qui est prévu par
l'interface. Pour combiner les commandes d'une façon arbitraire,
il faut une ligne de commande.
Mais la présence d'une n'en exclut pas la présence de l'autre,
et si j'utilise prèsqu'exclusivement l'interface clavier quand
j'édite réelement du text (saisie ou modification d'un document
ou programme), j'utilise volentairement l'interface graphique
quand je butine, sans éditer, et il n'y a pratiquement pas
d'alternatifs pour des documents graphique (diagrammes UML,
etc.).
> Si cela peut te rassurer :
> - la fenêtre commande-ligne j'ai pas cherché à comprendre ce qu'elle
> fait là, pour moi c'est une relique du passé, je ne l'ai jamais utilisée
Alors, je te l'explique. Elle sert à faire toutes les choses qui
ne sont pas prévues dans l'interface graphique. D'une côté, tu
entres des commandes arbitraire ; de l'autre, tu choisis d'entre
des commandes prévues.
> - Je suis comme toi, si je dois quitter le clavier des doigts cela
> m'agace. Mais je n'ai pas ce ressenti lors de l'utilisation de VS, bien au
> contraire.
Ça, je veux bien le crois. Est-ce que tu pourrais m'aiguiller
vers un tutorial, ou même un document quelconque, qui explique
tous les commandes clavier ?
> - Je ne connais pas ton matériel,
Quatre écrans 19 pouce.
> sur le mien j'affiche 2 sources, de front sur toute la
> hauteur, sans que cela se chevauche horizontalement, sans que
> cela se masque ou gêne à la lecture,
Ça, je l'ai chez moi, à la maison. Ici, je pourrais en afficher
8, s'il me le fallait. (Mais dans la pratique, il me faut bien
afficher d'autres choses aussi.) Ce n'est pas là le problème.
(Je préfère la façon que Solaris gère de multiple écrans, plutôt
que celle de Linux ou de Windows, mais ce n'est pas un vrai
problème.)
> plus les fenêtres propres à VS que j'ai choisis de visualiser,
> et il me reste encore de la place, c'est tellement agréable
> que de songer à un retour en arrière et c'est la déprime
> assurer.
Ce qui n'a rien à voir. Moi aussi, je préfère avoir beaucoup
d'espace sur l'écran. (J'aime bien aussi passer d'une fenêtre à
l'autre sans quitter le clavier de mes mains. Et ça, c'est
quelque chose qui marche mieux sous Windows que sous Unix.)
> Je ne suis pas prédicateur non plus, pour chercher à vouloir
> te convertir à truc que tu veux pas. De Vim je n'en dirait
> aucun mal, et si c'est ce qui te plait, pour moi cela me va
> très bien.
De Vim, tu n'en dirais aucun mal, sauf si tu étais obligé de
t'en servir. C'est ma situation actuellement avec VS.
--
James Kanze
Michael Doubez
[snip]
> À titre d'exemple, d'un problème que j'ai eu hier : suite à la
> modification d'un macro, il fallait que j'ajoute un ';' à la fin
> de la ligne de toutes les lignes qui l'invoquaient dans le
> projet. (Étant donné l'utilisation du macro, on pourrait être
> assez sûr qu'une ligne qui l'invoquait ne faisait que ça.) Sous
> Unix, je l'aurais fait en une quinzaine de sécondes, sans
> quitter l'éditeur où j'étais, et sans éloigner mese mains du
> clavier, avec quelque chose du genre :
>
> :args ! find . -name '*.cpp' -o -name '*.h' | xargs egrep -l
> 'DECLARE_TOTO'
> :argdo g/DECLARE_TOTO/s/$/;/
>
> C'est du vim, sur une machine avec un shell Unixien, mais je
> suis assez sûr qu'on peut faire la même chose en emacs (à
> condition d'avoir le shell Unixien, évidemment). Sous Windows,
> ":args" avec ! ne semble ne pas marcher sous vim ; je suis donc
> obligé à passer à une fenêtre de shell, et invoquer une nouvelle
> instance de vim.
Uu ouvres une liste quickfix:
:vimgrep /DECLARE_TOTO/j **/*.h **/.cpp
Et tu itères sur tous les fichiers:
:while 1 | exec "g/DECLARE_TOTO/s/$/;/|update" | sil cng | endwhile
--
Michael
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
9c0a6654-783b-4987...@d20g2000yqh.googlegroups.com...
> On Dec 4, 8:03 am, "Senhon" <N...@Nul.Nul> wrote:
>> groupe de discussion : 4b17f6a5$0$18404$426a3...@news.free.fr...
>
> [...]
>> > Ou plus simplement encore que tu ne sais pas te servir
>> > d'Emacs (sur
>
>> cela que je n'en dirais pas de mal. Et c'est ce point qui me
>> c'est graphique et cliquable, ou bien juste parce que c'est
>
> Mais quelles contre-v�rit�s ? On ne critique pas qu'il soit
> graphique et cliquable -- tous les �diteurs que je connais
> offrent ces possibilit�s aujourd'hui. On le critique parce qu'il
> n'est que graphique et cliquable, alors qu'il ne faut pas avoir
Bon j'esp�re que ce coup-ci on est d'accord sur le graphique et clicquable
:-)
> besoin de s'�loigner les doigts de la position de base sur le
> clavier. (Je critique emacs aussi un peu � cet �gard, parce que
> des coups de ALT-SHIFT-META et un caract�re contortionne les
> doigts d'une fa�on qui leur fait perdre la position de base.
> Mais c'est toujours moins emb�tant que d'avoir � prendre la
> souris ou des touches de fleche.) On le critique parce qu'il
> n'est pas integr� dans un environement puissant -- cmd.exe a un
Bon c'est � partir de l� que je trouve que tu divagues, je m'attendait pas �
ce que tu me parles de CMD.EXE,
Tu peux pas me voir, mais je me marre, ... CMD.EXE, houlala, lala, trop
dr�le.
Si je peux me permettre un conseil, laisser tomber la voie du CMD.EXE, tu
tout � fait � l'oppos�.
> retard important par rapport � Bash ou le shell de Bourne, et
> m�me cmd.exe n'est pas accessible directement depuis VS.
>
> � titre d'exemple, d'un probl�me que j'ai eu hier : suite � la
> modification d'un macro, il fallait que j'ajoute un ';' � la fin
> de la ligne de toutes les lignes qui l'invoquaient dans le
> projet. (�tant donn� l'utilisation du macro, on pourrait �tre
> assez s�r qu'une ligne qui l'invoquait ne faisait que �a.) Sous
> Unix, je l'aurais fait en une quinzaine de s�condes, sans
> quitter l'�diteur o� j'�tais, et sans �loigner mese mains du
> clavier, avec quelque chose du genre :
>
> :args ! find . -name '*.cpp' -o -name '*.h' | xargs egrep -l
> 'DECLARE_TOTO'
> :argdo g/DECLARE_TOTO/s/$/;/
>
> C'est du vim, sur une machine avec un shell Unixien, mais je
> suis assez s�r qu'on peut faire la m�me chose en emacs (�
> condition d'avoir le shell Unixien, �videmment). Sous Windows,
> ":args" avec ! ne semble ne pas marcher sous vim ; je suis donc
> oblig� � passer � une fen�tre de shell, et invoquer une nouvelle
> instance de vim. Maintenant : comment le faire sous Visual
> Studio ?
Ce que j'aurais fait c'est : utiliser l'enregistrement de macro, tu le fais
une fois, la machine le r�p�te.
Surtout que dans les cas de recherches/remplacements, tu peux t'arr�ter au
fichier courant, au projet courant, � la solution enti�re.
( Il doit �tre encore possible de le faire aussi dans des r�pertoires dans
le genre du "find -name" mais comme je n'en ai plus besoin je ne saurais en
parler.)
Ce que permet VS dans ce genre de cas, c'est par exemple : t'apercevoir que
c'a modifi� aussi dans des endroits que tu ne voulais pas, alors par un jeu
de touche (ctrl-backspace) revenir en arri�re, �diter la macro pour la
compl�ter et la rejouer.
La conserver, peut-�tre en la parametrisant, pour te simplifier encore plus
la vie.
Bon c'est un exemple, mais un nombre que je saurais pas estimer, d'autres
scenarios sont envigeasables.
>(Je ne dis pas que c'est impossible, mais les gens qui
> travaille � c�t� de moi, et qui semblent conna�tre VS tr�s bien,
> ne savaient pas le faire non plus.)
Y'a comme un bug, toi ou eux.
>
> [...]
>> Pour moi, il est trop tard.
>> Aujourd'hui, si je dois faire un d�veloppement pour linux, je pr�f�re le
>> faire avec VS param�tr� pour qu'il compile en parall�le et pour Windows
>> et
>> pour linux.
>> Cela r�glant rapidement les probl�mes de portage. Et je dis
>> bien j'appui sur la touche F7 et ca compile windows et linux
>> dans la m�me foul�.
>
> Ce que je peux dire d'exp�rience, c'est que tous les
> programmeurs vraiment efficaces que j'ai vu se servaient des
> outils Unix et la ligne de commande. Y compris sous Windows.
> Pourquoi, je n'ai jamais r�element cherch� � savoir, mais dans
> la mesure o� je n'ai jamais vu travailler r�element efficacement
> sous Windows, �a ne m'a pas donn� une motivation forte � bien
> l'apprendre.
Oui, c'est bien ce que j'ai compris.
Je pense que dans les m�me circonstances j'aurais agis tout comme toi.
>(Par travailler, ici, j'entends d�velopper des
> logiciels. Pour beaucoup d'autres choses, on peut bien �tre plus
> productif sous Windows que sous Unix -- Star Office est loin de
> MS Office, par exemple.)
Et pourtant qu'est-ce qu'on � pas entendu comme stupidit�s � ce sujet, comme
avec IE/firefox, Windows/linux, propri�taire/open source..
Michael Doubez
Merci du retour sur le thread.
Je pensais aussi au masquage d'un membre par un variable locale.
Un printf sur la valeur montrera que tout va bien alors qu'un print de
*this montrera que l'état de l'objet ne change pas.
class Foo
{
public:
bool init()
{
// lignes pour noyer le poisson
char* ptr = new char[200];
// lignes ...
}
char peek()const
{
return *ptr;
}
private:
char* ptr;
};
int main()
{
Foo foo;
assert(foo.init());
cout<<foo.peek()<<std::endl;
}
--
Michael
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
c2fd7e3c-33e3-4954...@f16g2000yqm.googlegroups.com...
> On Dec 3, 4:43 pm, "Senhon" <N...@Nul.Nul> wrote:
>> de
>
>
> J'ai plusieurs fen�tres console ouvertes en permanance, si c'est
> �a que tu veux dire. Ce que je ne sais pas faire, c'est de
D'ou les CMD.EXE, ... tout s'explique.
Comme je disais dans une autre r�ponse, tu es �gar� bien loin, ce n'est pas
la bonne approche.
> marquer un bloc dans une source sous l'�diteur VS, puis de le
> filtrer � travers une commande (compos�e souvent, avec des
> pipes) arbitraire disponible dans une fen�tre de commande.
>
>> - tu ne sais pas comment travailler en gardant les mains sur le
>> clavier.
>
> Non. Je crois en fait que c'est possible, mais je ne sais pas le
> faire, et mes coll�gues ne savent pas me le montrer.
>
> Pour l'instant, je n'ai pas trouv� de tutorial sur l'�diteur,
Clique � tout va s'est la meilleur chose � faire :-))
> qui t'apprend � faire m�me les choses les plus �l�mentaire sans
> chercher chaque fois dans les menus.
>
>> - l'environnement graphique te limite plus qu'il ne t'apporte.
>> A ce niveau, je dis stop, laisse tomber ... au moins pour l'instant. Un
>> jour
>> peut-�tre, tu auras une meilleur orientation, moins braqu�, et l� les
>> choses
>> iront plus facilement.
>
> L'interface graphique peut �tre tr�s utile dans beaucoup de cas,
> mais par la force de chose, elle ne sera jamais aussi puissant
> qu'une interface ligne de commande ;
Houlala, ... comme par corriger cette appr�ciation fausse.
>dans l'interface graphique,
> tu ne pourrais jamais faire que ce qui est pr�vu par
> l'interface. Pour combiner les commandes d'une fa�on arbitraire,
> il faut une ligne de commande.
>
> Mais la pr�sence d'une n'en exclut pas la pr�sence de l'autre,
> et si j'utilise pr�squ'exclusivement l'interface clavier quand
Je ne peux rien pour toi, tu dois en passer par o� la plupart d'entre nous
sont oblig�s de passer (moi aussi cela va sans dire) : remets-toi en
cause.
Ton approche est contreproductive ( Mais alors a un un point ! )
> j'�dite r�element du text (saisie ou modification d'un document
> ou programme), j'utilise volentairement l'interface graphique
> quand je butine, sans �diter, et il n'y a pratiquement pas
> d'alternatifs pour des documents graphique (diagrammes UML,
> etc.).
>
>> Si cela peut te rassurer :
>> - la fen�tre commande-ligne j'ai pas cherch� � comprendre ce qu'elle
>> fait l�, pour moi c'est une relique du pass�, je ne l'ai jamais utilis�e
>
> Alors, je te l'explique. Elle sert � faire toutes les choses qui
> ne sont pas pr�vues dans l'interface graphique. D'une c�t�, tu
> entres des commandes arbitraire ; de l'autre, tu choisis d'entre
> des commandes pr�vues.
>
>> - Je suis comme toi, si je dois quitter le clavier des doigts cela
>> m'agace. Mais je n'ai pas ce ressenti lors de l'utilisation de VS, bien
>> au
>> contraire.
>
> �a, je veux bien le crois. Est-ce que tu pourrais m'aiguiller
> vers un tutorial, ou m�me un document quelconque, qui explique
> tous les commandes clavier ?
Un tutoriel ? je ne sais pas , j'en ai pas eu besoin.
De ce que je me souviens les raccourcis se trouvent afficher dans les menus.
Ce que je fais dans un cas comme celui-ci : j'utilise la touche F1 (aide)
Par exemple tu fais Outils/option/Clavier/F1 et tu tombe directement sur
"Comment : utiliser les combinaisons de touches de raccourci" .
L'aide fournie (je ne parle pas que pour les raccourcis) est colossale.
[....]
>
> De Vim, tu n'en dirais aucun mal, sauf si tu �tais oblig� de
> t'en servir.
:-)
Je ne dirais pas de mal de vim, ni m�me de vi ...
Des �diteurs d'avant vi, oui, je pourrais en dire du mal, mais depuis le
temps ... il y a prescription.
> C'est ma situation actuellement avec VS.
Malheureusement, je ne suis pas le bon interlocuteur, ce que je connais de
VS est somme toute limit�e.
J'ai juste cherch� ce dont j'avais besoin, un outil pratique pour �crire mes
programme dans les meilleurs conditions, les compiler sans me prendre la
t�te, et debugger avec un maximum de facilit�.
Au sujet du debugger (bon, ce sont mes sources que je debugge), ce dont j'ai
besoin c'est : pouvoir mettre un point d'arr�t, une fenetre qui m'affiche
les variables "en automatique", pour les autres variable non affich�e le
passage de la souris sur la variable me renseigne compl�tement, dans les cas
les plus tordus la fen�tre avec la pile d'appel, et la fameuse touche F12.
Pour moi ce qui compte avant tout, c'est mes programmes, je ne suis pas
experts VS.
VS dit papa-maman, mais je me contente d'une infime portion de ces
possibilit�s, juste pour avancer dans ma v�ritable passion.
Alexandre Bacquart
> � titre d'exemple, d'un probl�me que j'ai eu hier : suite � la
> modification d'un macro, il fallait que j'ajoute un ';' � la fin
> de la ligne de toutes les lignes qui l'invoquaient dans le
> assez s�r qu'une ligne qui l'invoquait ne faisait que �a.) Sous
> Unix, je l'aurais fait en une quinzaine de s�condes, sans
> clavier, avec quelque chose du genre :
>
> :args ! find . -name '*.cpp' -o -name '*.h' | xargs egrep -l
> 'DECLARE_TOTO'
> :argdo g/DECLARE_TOTO/s/$/;/
>
> C'est du vim, sur une machine avec un shell Unixien, mais je
Sans commande unix (il faut un environnement correct bien-s�r) et d'une
traite, voici un flux clavier au format Emacs :
M-x t a g s - q <tab> <return> \ ( D E C L A R E _
T O T O . * ) \ ) $ <return> \ 1 ; <return> !
Un trentaine de touches donc, avec autant de ! qu'il y a de fichiers si
on est s�r du r�sultat, ou avec y pour confirmer chaque ligne une par une.
C'est aussi possible sans tags (dired-do-query-replace-regexp).
--
Alex
James Kanze
En fait, je m'étais mal rappelé de syntaxe.
:args ` find . -name '*.cpp' -o -name '*.h' | xargs egrep -l `
:argdo g/DECLARE_TOTO/s/$/;/
marche très bien, même sous Windows.
--
James Kanze
James Kanze
> "James Kanze" <james.ka...@gmail.com> a crit dans le message de groupe de
> discussion :
> 9c0a6654-783b-4987-ae99-78d72a844...@d20g2000yqh.googlegroups.com...
> > On Dec 4, 8:03 am, "Senhon" <N...@Nul.Nul> wrote:
[...]
> Bon c'est partir de l que je trouve que tu divagues, je
> m'attendait pas ce que tu me parles de CMD.EXE, Tu peux pas me
> voir, mais je me marre, ... CMD.EXE, houlala, lala, trop dr
> le. Si je peux me permettre un conseil, laisser tomber la
> voie du CMD.EXE, tu tout fait l'oppos .
C'est ce que j'ai fait. Je l'ai remplacé par bash.
[...]
> Ce que j'aurais fait c'est : utiliser l'enregistrement de
> macro, tu le fais une fois, la machine le répéte.
Cette possibilité existe (et en vim, et en emacs). Mais il faut
toujours l'invoquer sur chaque fichier ; c'est le :argdo qui
m'intéresse ici, ainsi que le :g (qui fait executer la commande
sur chaque ligne où se trouve la chaîne cherchée). (Quand la
commande est plus complexe qu'un simple replacement, je crée
bien le macro, mais je me sers toujours de :argdo, et :g si
nécessaire, pour l'invoquer dans tous les fichiers, sur toutes
les lignes qu'il faut.)
> Ce que permet VS dans ce genre de cas, c'est par exemple :
> t'apercevoir que c'a modifi aussi dans des endroits que tu ne
> voulais pas, alors par un jeu de touche (ctrl-backspace)
> revenir en arrière, êditer la macro pour la complèter et la
> rejouer. La conserver, peut-être en la parametrisant, pour te
> simplifier encore plus la vie.
C'est effectivement bien. Le undo, ça existe évidemment à peu
près partout, mais je ne sais pas si on peut éditer les macros
saisi à la volée en vim. (On peut évidemment éditer les macros
qu'on définit dans son fichier de configuration. Vue que c'est
un fichier.)
> > [...]
> >(Par travailler, ici, j'entends d velopper des logiciels.
> >Pour beaucoup d'autres choses, on peut bien tre plus
> >productif sous Windows que sous Unix -- Star Office est loin
> >de MS Office, par exemple.)
> Et pourtant qu'est-ce qu'on pas entendu comme stupidit s ce
> sujet, comme avec IE/firefox, Windows/linux, propriètaire/open
> source..
Je sais. Ça m'énerve aussi. Mais ce n'est pas le cas chez moi
(qui préfère Solaris à Linux, de loin, et qui reconnais que même
Windows, c'est beaucoup plus stable que Linux).
--
James Kanze
James Kanze
> "James Kanze" <james.ka...@gmail.com> a crit dans le message de groupe de
> c2fd7e3c-33e3-4954-a208-740003222...@f16g2000yqm.googlegroups.com...
> > On Dec 3, 4:43 pm, "Senhon" <N...@Nul.Nul> wrote:
> >> "James Kanze" <james.ka...@gmail.com> a crit dans le message de groupe
> >> de
> > J'ai plusieurs fen tres console ouvertes en permanance, si c'est
> > a que tu veux dire. Ce que je ne sais pas faire, c'est de
> D'ou les CMD.EXE, ... tout s'explique. Comme je disais dans
> une autre r ponse, tu es gar bien loin, ce n'est pas la bonne
> approche.
En effet, je les ai remplacé par des fenêtres bash. (Mais
cmd.exe, ce n'est pas si mal que ça. Microsoft a fait d'énorme
progrès par rapport aux shell d'origine.)
> > marquer un bloc dans une source sous l' diteur VS, puis de
> > le filtrer travers une commande (compos e souvent, avec des
> > pipes) arbitraire disponible dans une fen tre de commande.
> >> - tu ne sais pas comment travailler en gardant les mains sur le
> >> clavier.
> > Non. Je crois en fait que c'est possible, mais je ne sais pas le
> > faire, et mes coll gues ne savent pas me le montrer.
> > Pour l'instant, je n'ai pas trouv de tutorial sur l' diteur,
> Clique tout va s'est la meilleur chose faire :-))
Le problème, c'est que pour cliquer, il faut que j'éloigne mes
mains du clavier.
[...]
> > L'interface graphique peut tre tr s utile dans beaucoup de
> > cas, mais par la force de chose, elle ne sera jamais aussi
> > puissant qu'une interface ligne de commande ;
> Houlala, ... comme par corriger cette appr ciation fausse.
Ce n'est pas une « appréciation », c'est une simple constatation
des faits. Tu peux exprimer beaucoup plus avec des caractères
classique qu'avec n'importe quel jeu de menus. (Tu ne te sers
pas de la souris pour entrer ton programme C++, quand mėme.)
> > dans l'interface graphique, tu ne pourrais jamais faire que
> > ce qui est pr vu par l'interface. Pour combiner les
> > commandes d'une fa on arbitraire, il faut une ligne de
> > commande.
> > Mais la pr sence d'une n'en exclut pas la pr sence de l'autre,
> > et si j'utilise pr squ'exclusivement l'interface clavier quand
> Je ne peux rien pour toi, tu dois en passer par o la plupart
> d'entre nous sont oblig s de passer (moi aussi cela va sans
> dire) : remets-toi en cause. Ton approche est
> contreproductive ( Mais alors a un un point ! )
Tellement contreproductive que ma productivité dépasse de loin
tous les gens qui travaillent avec la souris:-). (Pas à
l'instant, forcément, parce que j'apprends un nouvel
environement, mais en général, je constate que j'arrive beaucoup
plus rapidement que mes collegues.)
[...]
> >> - Je suis comme toi, si je dois quitter le clavier des doigts cela
> >> m'agace. Mais je n'ai pas ce ressenti lors de l'utilisation
> >> de VS, bien au contraire.
> > a, je veux bien le crois. Est-ce que tu pourrais m'aiguiller
> > vers un tutorial, ou m me un document quelconque, qui
> > explique tous les commandes clavier ?
> Un tutoriel ? je ne sais pas , j'en ai pas eu besoin.
> De ce que je me souviens les raccourcis se trouvent afficher dans les menus.
Oui. Mais que les raccourcis pour des choses accessibles depuis
les menus. Et les menus, par définition, c'est limité.
--
James Kanze
Senhon
"James Kanze" <james...@gmail.com> a �crit dans le message de groupe de
discussion :
24f6e302-405b-4ab9...@j24g2000yqa.googlegroups.com...
> On Dec 4, 10:12 am, "Senhon" <N...@Nul.Nul> wrote:
>> "James Kanze" <james.ka...@gmail.com> a crit dans le message de groupe de
>> discussion :
>> 9c0a6654-783b-4987-ae99-78d72a844...@d20g2000yqh.googlegroups.com...
>> > On Dec 4, 8:03 am, "Senhon" <N...@Nul.Nul> wrote:
>
> [...]
>> voie du CMD.EXE, tu tout fait l'oppos .
>
Pardon de m'�tre exprim� aussi mal, je voulais dire : la voie de
l'interpr�teur de commande n'est pas la bonne.
[...]
>
>
> C'est effectivement bien. Le undo, �a existe �videmment � peu
> pr�s partout, mais je ne sais pas si on peut �diter les macros
> saisi � la vol�e en vim. (On peut �videmment �diter les macros
> qu'on d�finit dans son fichier de configuration. Vue que c'est
> un fichier.)
L'enregistrement de macro � la vol�e, permet de mettre in pied � l'�trier
...
Jean-Marc Bourguet
> Pardon de m'�tre exprim� aussi mal, je voulais dire : la voie de
> l'interpr�teur de commande n'est pas la bonne.
Tu peux donner ton raisonnement?
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
Senhon
"James Kanze" <james...@gmail.com> a écrit dans le message de groupe de
discussion :
5f18b3b9-3357-41a2...@s20g2000yqd.googlegroups.com...
> On Dec 4, 10:56 am, "Senhon" <N...@Nul.Nul> wrote:
>> "James Kanze" <james.ka...@gmail.com> a crit dans le message de groupe de
>> discussion :
>> c2fd7e3c-33e3-4954-a208-740003222...@f16g2000yqm.googlegroups.com...
>
>
>
> cmd.exe, ce n'est pas si mal que ça. Microsoft a fait d'énorme
> progrès par rapport aux shell d'origine.)
Bash ou autre, c'est quand même mieux d'utiliser le produit mis en batterie.
Comme tu essayes de faire comme avant, tu es complétement à coté de la
plaque.
>
>
>> > Pour l'instant, je n'ai pas trouv de tutorial sur l' diteur,
>
>> Clique tout va s'est la meilleur chose faire :-))
>
> Le problème, c'est que pour cliquer, il faut que j'éloigne mes
> mains du clavier.
Dans la perspective d'utiliser un tutoriel serais-tu prêt à lacher ton
clavier ?
Cliquer à tout va, s'entendait comme : faire le tour du "propriétaire", dans
un but éducatif.
>
> Ce n'est pas une « appréciation », c'est une simple constatation
> des faits. Tu peux exprimer beaucoup plus avec des caractères
> classique qu'avec n'importe quel jeu de menus. (Tu ne te sers
> pas de la souris pour entrer ton programme C++, quand mėme.)
J'utilise tout ce qui est à ma portée, pour peu que se soit efficace.
>> > dans l'interface graphique, tu ne pourrais jamais faire que
>> > ce qui est pr vu par l'interface. Pour combiner les
>> > commandes d'une fa on arbitraire, il faut une ligne de
>> > commande.
>
>> > Mais la pr sence d'une n'en exclut pas la pr sence de l'autre,
>> > et si j'utilise pr squ'exclusivement l'interface clavier quand
>
>> Je ne peux rien pour toi, tu dois en passer par o la plupart
>> d'entre nous sont oblig s de passer (moi aussi cela va sans
>> dire) : remets-toi en cause. Ton approche est
>> contreproductive ( Mais alors a un un point ! )
>
> Tellement contreproductive que ma productivité dépasse de loin
> tous les gens qui travaillent avec la souris:-). (Pas à
> l'instant, forcément, parce que j'apprends un nouvel
> environement, mais en général, je constate que j'arrive beaucoup
> plus rapidement que mes collegues.)
Bon ben, c'est très bien, alors.
>
> [...]
>
>> > a, je veux bien le crois. Est-ce que tu pourrais m'aiguiller
>> > vers un tutorial, ou m me un document quelconque, qui
>> > explique tous les commandes clavier ?
>
>> Un tutoriel ? je ne sais pas , j'en ai pas eu besoin.
>> De ce que je me souviens les raccourcis se trouvent afficher dans les
>> menus.
>
> Oui. Mais que les raccourcis pour des choses accessibles depuis
> les menus. Et les menus, par définition, c'est limité.
Parce que tu sais utiliser Vim et emacs, il faudrait que VS fonctionne
suivant le même plan.
A ce sujet, n'as-tu pas vu passer un mail qui parlait d'une extension de VS
émulant VIM, peut-être, une bonne voie ...
James Kanze
> "James Kanze" <james.ka...@gmail.com> a écrit dans le message
> de groupe de discussion :
> 5f18b3b9-3357-41a2-a5d9-dcbf04045...@s20g2000yqd.googlegroups.com...
> > On Dec 4, 10:56 am, "Senhon" <N...@Nul.Nul> wrote:
> >> "James Kanze" <james.ka...@gmail.com> a crit dans le
> >> message de groupe de discussion :
> >> c2fd7e3c-33e3-4954-a208-740003222...@f16g2000yqm.googlegroups.com...
> > En effet, je les ai remplacé par des fenêtres bash. (Mais
> > cmd.exe, ce n'est pas si mal que ça. Microsoft a fait
> > d'énorme progrès par rapport aux shell d'origine.)
> Bash ou autre, c'est quand même mieux d'utiliser le produit
> mis en batterie. Comme tu essayes de faire comme avant, tu es
> complétement à coté de la plaque.
Sauf que je suis plus productif que les gens qui utiliser le
produit mis en batterie. Ce que je cherche, c'est d'améliorer ma
productivité sous Windows, de façon à l'amener au niveau de ma
productivité sous Unix, non de la réduire au niveau des
programmeurs Windows habituels, qui ne se servent pas des shells
et des autres outils puissants.
> >> > Pour l'instant, je n'ai pas trouv de tutorial sur l'
> >> > diteur,
> >> Clique tout va s'est la meilleur chose faire :-))
> > Le problème, c'est que pour cliquer, il faut que j'éloigne
> > mes mains du clavier.
> Dans la perspective d'utiliser un tutoriel serais-tu prêt à
> lacher ton clavier ?
Pendant l'utilisation du tutoriel, oui. Comme j'ai déjà dit par
ailleurs, quand je butine, j'utilise surtout la souris. Utiliser
la souris, c'est bien. Utiliser le clavier, c'est bien. Avoir à
passer de l'un à l'autre, ça un coût très élevé en termes de
productivité. Or, vue que je n'ai jamais vu en système où on
pouvait entrer du code avec la souris, quand je saisis du code,
il faut un système qui utilise prèsqu'exclusivement le clavier.
> Cliquer à tout va, s'entendait comme : faire le tour du
> "propriétaire", dans un but éducatif.
Est-ce que je dois cliquer aussi pour entrer du code ? (C'était
bien une solution offerte sur le Xerox Star -- l'ancêtre de tous
nos GUI. Mais autant que je sache, personne ne s'en servait.)
> > Ce n'est pas une « appréciation », c'est une simple
> > constatation des faits. Tu peux exprimer beaucoup plus avec
> > des caractères classique qu'avec n'importe quel jeu de
> > menus. (Tu ne te sers pas de la souris pour entrer ton
> > programme C++, quand mėme.)
> J'utilise tout ce qui est à ma portée, pour peu que se soit
> efficace.
Mais avoir constamment à déplacer les mains de la position de
base sur le clavier, ce n'est pas efficace. Regarde par exemple
les utilisateurs de vim, qui prèsque tous reprogramme le clavier
pour que la touche ESC soit accessible sans déplacer les mains.
(Vim utilise énormement la touche ESC.)
Chaque fois que tu changes du clavier à la souris, ou
vice-versa, il faut que tu regardes tes mains. En gros, il te
coûte en temps ce qu'il faut pour cinq ou six caractères frappés
au clavier.
--
James Kanze