Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Bug indétectable via printf() / cout

Bug indétectable via printf() / cout

148 réponses
Avatar
AG
Bonjour =E0 tous,

Je travaille dans une =E9quipe de personnes pour lesquels le d=E9bugger
n'est pas l'outil qui tombe sous le sens lorsqu'il s'agit de trouver
les bugs des outils qu'ils ont d=E9velopp=E9.

Afin de les sensibiliser, je recherche un exemple de bug difficile
(voir impossible) a d=E9tecter via des printf()/cout qui n'afficheraient
que les contenus des variables. (Je me rends bien compte qu'on doit
pouvoir tout d=E9bugger avec printf()/cout, mais il faut parfois
afficher les adresses des variable (en plus de leur valeur), voir
parfois la m=E9moire =E0 certains endroits.)

Je voudrais construire un exemple simple (notions de C++ pas trop
compliqu=E9es) et court (un seul fichier, 100 lignes max) pour qu'on
puisse l'=E9tudier en un quart d'heure, mais le d=E9bugger en un temps
presque infini sans d=E9bugger.

Il est possible que l'exemple, puisqu'il y a un bug, d=E9pende de la
plateforme mais c'est un peu in=E9vitable.

L'id=E9al serait que le plantage ait lieu bien apr=E8s le bug...=E7a rajout=
e
du piment. Bref, vous voyez l'id=E9e quoi...

J'avais plusieurs pistes d'exploitation de bug:

Piste 1:
Boucle for d=E9croissante sur un entier non sign=E9 : for(size_t i =3D N;
0<=3D i; i--)

Piste 2:
comparaison de double : double x; ... ; x =3D=3D 0.0

Piste 3:
retour de malloc() non test=E9

Piste 4:
caract=E8re de fin de ligne non test=E9 (\0)

Mais jusque l=E0, je crains qu'il ne soit trop facile de d=E9tecter le
bug

J'ai donc ensuite pens=E9 aux r=E9f=E9rences. Mais ce code est encore un pe=
u
trop voyant. Dans le main(), on peut facilement se demander pourquoi
f1 et f2 sont des r=E9f=E9rences, ce qui met directement la puce =E0
l'oreille. Peut =EAtre trouvez vous ce code bien trop compliqu=E9, ou
auriez vous en t=EAte un mani=E8re de "l'am=E9liorer" :-)

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 =3D N-1; position =3D buffer + pos_offset;
for(int i=3D0;i<N;i++) buffer[i]=3DT(0);};

T step(T &input)
{
*position =3D input;

if(pos_offset>0) // ici il y aurait peut =EAtre moyen de glisser le
bug de la piste 1
pos_offset--;
else
pos_offset =3D N-1;

position =3D 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 =3D fifo_circular<N,T>(); // h=E9 h=E9 h=E9

for(size_t i =3D 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 =3D 0; i < M; i++)
o << f.buffer[i] << " ";
return o;
}

int main(int argc, char * argv[])
{
int a =3D 1;
fifo_circular<5,int> & f1 =3D Init<5,int>(a); // ici, c'est un peu trop
voyant. On se demande pourquoi f1 est d=E9clar=E9 en tant que
r=E9f=E9rence...
a =3D 2;
fifo_circular<5,int> & f2 =3D Init<5,int>(a);

cout << "fifo f1: " << f1 << "\n";
cout << "fifo f2: " << f2 << "\n";

return 0;
}
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
9 10 11 12 13
Avatar
Senhon
"Marc Espie" a écrit dans le message de groupe de
discussion : hfimpd$2qhu$
In article <4b1cd9fc$0$12447$,
Senhon wrote:

"Jean-Marc Bourguet" a écrit dans le message de groupe
de
discussion :
"Senhon" writes:

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?




Raisonnement, est un bien grand mot, pour exprimer : utiliser le produit
mis
en place, c'est à dire, commencer par comprendre comment utiliser VS.
En admettant qu'il est possible d'utiliser la panoplie des possibilités de
l'IDE, et non d'ouvrir des console extérieurs à cet IDE.



C'est un peu le souci de ces outils. Un IDE de plus -> un langage de
macros
de plus. Il y a eventuellement un peu d'unification a ce niveau, cote
visual basic, mais c'est terriblement etrique par rapport a la philosophie
correspondante cote Unix.

- d'abord, parce que l'idee d'avoir des petits outils utilisables de
n'importe
ou predate windows de quelques annees, et que des choses comme le shell,
sed,
ou vi, sont incroyablement efficaces encore aujourd'hui (ne serait-ce que
parce
que ca a son origine sur des machines ridiculement petites par rapport aux
standards actuels, et que donc, sur une machine moderne, c'est tres, tres,
tres rapide et peu gourmand en memoire).

- ensuite parce qu'on a le choix. Les outils en question ont ete concus
pour
etre interoperables. Et il y a d'autres outils equivalents. Tu n'aimes pas
le Bourne Shell ? tu peux faire du bash, du zsh, du korn-shell. Tu n'aimes
pas
vim ? tu peux faire du emacs. Tu veux un langage de macros ? tout ce petit
monde sait marcher avec perl, ruby, python, ou lua... le seul echec en la
matiere, c'est gcc... une certaine paranoia de ses developpeurs les a
conduit
a developper un compilo ou frontend et backend sont intimement lies (des
fois
que quelqu'un utilise la frontend g++ avec un backend PROPRIETAIRE), et il
manque donc plein d'outils intermediaires qui seraient sympa (comme des
analyseurs de code un peu intelligents). Vive llvm...

Evidemment, ca fait un peu peur au debut, vu la plethore de choix. Mais si
je compare aux IDE "modernes", c'est nettement mieux quand on a le temps
d'acquerir de l'experience. Deja, tu peux choisir l'outil qui
te plait le plus. Ensuite tu peux le customiser en utilisant ton
experience des outils que tu connais deja. Sur les IDE "modernes"
en face, soit tu as du lock-in (ouais, vive visual basic... encore
que $crosoft change un peu avec .NET, mais bon), soit les gens sont
tellement persuades d'avoir invente la solution ideale que rien
d'autre n'est bon (eclipse: hors de java, point de salut... mais
bon, emacs est a peu pres aussi grave dans le meme genre).



Wahou ! belle compréhension de la situation.
Avatar
Michael Doubez
On 7 déc, 10:21, James Kanze wrote:
On Dec 7, 8:58 am, "Senhon" wrote:

> "James Kanze" a écrit dans le message
> de groupe de discussion :
>
> > On Dec 4, 10:56 am, "Senhon" wrote:
> >> "James Kanze" a crit dans le
> >> message de groupe de discussion :
> >>
> > 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.



[snip]

Suite à ce thread, j'ai regardé d'un peu plus près mon Visual Studio
(2008) et il apparait qu'il y a une interface ligne de command (CTRL-
ALT-A) par laquelle on peut passer des commandes et créer des alias de
commandes (que je suppose, on peut mettre dans des raccourcis
clavier).
On peut aussi s'en servir pour debugger.

Je ne sais pas dans quelle mesure c'est scriptable mais il y a un
outils pour faciliter la definition d'alias: VSTweak power toy.
http://code.msdn.microsoft.com/VSTweak

Je n'ai pas trouvé de personne (MVP) qui partage sa configuration VS
pour accroitre la productivité.

--
Michael
Avatar
Michael Doubez
On 7 déc, 12:02, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe de
discussion :


> On Dec 7, 8:58 am, "Senhon" wrote:
>> "James Kanze" a écrit dans le message
>> de groupe de discussion :


[snip]
> 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.)

D'accord VIM est très bien.
Au sujet de l'émulation de VIM dans VS ?



Vim peut être intégré (en théorie, je ne l'ai jamais fait) dans VS
comme un objet MDI.
http://vim.wikia.com/wiki/Calling_gvim_from_MS_Visual_Studio

Sinon, il y a la solution payante ou modifer vim pour le rendre un peu
plus intégré à VS (merger les tabs ...)

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

Je ne sais pas pourquoi tu fais une fixette avec cette souris.
Sur un mode semi-sérieux, il t'es possible de débrancher la souris et de
continuer d'utiliser Windows/VS. AMHA,  cela doit être possible, mais non
envisageable.



Une image vaut un discours:
http://www.youtube.com/watch?vüpQ7koECgk&feature=related


La souris je l'utilise pour selectionner des champs, des blocs, pour
naviguer le cas échéant, mais comme je te le disais, je crée mes pr ojets,
mes classes, mes fonctions, mes attributs,à l'aide de raccourcis qui
appellent des macros qui me déchargent d'un boulot monstrueux.

A titre d'exemple, je peux monter une classe, avec ces fonctions membres,
ses attributs, juste en affichant à l'écran que le .CPP, sans jamais ouvrir
ne serait-ce qu'une seule fois le header.  Les macros analysent
syntaxiquement pour écrire __correctement__ dans les deux fichiers(ajou ter
dans l'un, modifier dans l'autre), ajouter les includes si besoin est, et
sauf coquilles de ma part, c'est immédiatement compilable. Et ce, sans
quitter le clavier des mains.
Bon cela je peux le faire aujourd'hui pour les cas les plus fréquents, il y
aura toujours des cas que je n'ai pas encore traites où je dois quitter
l'édition du fichier courant.



C'est vrai qu'avoir un analyseur syntaxique intégré est plus puissant
et vraiment un avantage pour l'automatisation. Et l'avantage d'une
solution intégré est que tu maitrise tous les éléments du projet (e x:
vim ou emacs n'ont pas la notion des flags utilisés sur un code).

--
Michael
Avatar
espie
In article ,
Michael Doubez wrote:
C'est vrai qu'avoir un analyseur syntaxique intégré est plus puissant
et vraiment un avantage pour l'automatisation. Et l'avantage d'une
solution intégré est que tu maitrise tous les éléments du projet (ex:
vim ou emacs n'ont pas la notion des flags utilisés sur un code).



Pour emacs, je suis meme pas sur que ca soit vrai, vu tout ce qui existe.
Pour vim, on peut tres bien envisager de le coupler avec unifdef ou un
equivalent, qui te permettrait par exemple de voir ce qui est reellement
compile (ou de pouvoir utiliser la sortie d'un des multiples modes de gcc
qui te donne les definitions de macros, par exemple).

Apres, il y a aujourd'hui llvm, qui sans doute finira par te donner tout
ce genre d'integration si tu le souhaites...
Avatar
James Kanze
On Dec 7, 11:02 am, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe de
discussion :




> On Dec 7, 8:58 am, "Senhon" wrote:
>> "James Kanze" a écrit dans le message
>> de groupe de discussion :
>>



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



Bon, si tu es plus productifs que le programmeurs Windows
habituels, et que tout le monde est content ...



Je suis plus productif que ceux qui se limitent à VS. J'en
connais des programmeurs Windows productifs, mais ils se servent
tous d'un shell et des commandes ligne de commande.

[...]
> Est-ce que je dois cliquer aussi pour entrer du code ?



Hé, mais t'es serieux là ?



Oui et non. C'est toi que me dit qu'il faut tout faire avec la
souris.

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



Je ne sais pas pourquoi tu fais une fixette avec cette souris.
Sur un mode semi-sérieux, il t'es possible de débrancher la
souris et de continuer d'utiliser Windows/VS. AMHA, cela doit
être possible, mais non envisageable.



Je crois aussi que c'est possible, mais je n'arrive pas à
trouver une documentation qui explique comment. (Et ce que je
cherche, c'est sans souris ET sans les fleches du clavier, parce
que sur mon clavier, pour utiliser les fleches il faut aussi
déplacer la main. Mais c'est un moindre mal, parce que les
fleches ont quand même une position fixe par rapport au
clavier.)

La souris je l'utilise pour selectionner des champs, des
blocs, pour naviguer le cas échéant, mais comme je te le
disais, je crée mes projets, mes classes, mes fonctions, mes
attributs,à l'aide de raccourcis qui appellent des macros qui
me déchargent d'un boulot monstrueux.



Pour la création des projets, etc., je ne vois pas trop de
problèmes. Mais pour sélectionner un champs dans un fichier de
sources, ça ralentira beaucoup d'avoir à me servir de la souris.

A titre d'exemple, je peux monter une classe, avec ces
fonctions membres, ses attributs, juste en affichant à l'écran
que le .CPP, sans jamais ouvrir ne serait-ce qu'une seule fois
le header. Les macros analysent syntaxiquement pour écrire
__correctement__ dans les deux fichiers(ajouter dans l'un,
modifier dans l'autre), ajouter les includes si besoin est, et
sauf coquilles de ma part, c'est immédiatement compilable. Et
ce, sans quitter le clavier des mains.
Bon cela je peux le faire aujourd'hui pour les cas les plus
fréquents, il y aura toujours des cas que je n'ai pas encore
traites où je dois quitter l'édition du fichier courant.



Ça ressemble un peu à comment Rose fonctionne. Dans ce cas-là,
ça peut être intéressant. (Mais le vrai intérêt de Rose, c'est
la documentation graphique des rapports entre les classes.)

Toutes fois est-il que je ne saisis pas comment ça peut marcher.
Comment fais-tu, par exemple, savoir dans les macros les noms
et les types des variables membres ?

--
James Kanze
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 7, 11:02 am, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe
de
discussion :





[...]
> Est-ce que je dois cliquer aussi pour entrer du code ?



Hé, mais t'es serieux là ?



Oui et non. C'est toi que me dit qu'il faut tout faire avec la
souris.



Non je n'ai jamais, au grand jamais dis qu'il fallait saisir du texte avec
la souris.
Tu demandais un tutoriel, je t'ai de cliquer pour faire apparaitre les
raccourcis. Et d'utiliser l'aide ( touche F1).

La souris je l'utilise pour selectionner des champs, des
blocs, pour naviguer le cas échéant, mais comme je te le
disais, je crée mes projets, mes classes, mes fonctions, mes
attributs,à l'aide de raccourcis qui appellent des macros qui
me déchargent d'un boulot monstrueux.



Pour la création des projets, etc., je ne vois pas trop de
problèmes. Mais pour sélectionner un champs dans un fichier de
sources, ça ralentira beaucoup d'avoir à me servir de la souris.



Houlala, j'ai parler de sélectionner des champs, d'accord :
- mais c'était pour donner un exemple, je sui pas en permanence en train
de sélectionner des champs, cela m'arrive, mais y a pas de quoi s'en
émouvoir.
- Et puis la sélection d'un champ ou d'un bloc peut se faire sans la
souris.

Une nouvelle fois, tu te bloques sur la souris, alors que le PB est plutôt
"philosophie du produit".


A titre d'exemple, je peux monter une classe, avec ces
fonctions membres, ses attributs, juste en affichant à l'écran
que le .CPP, sans jamais ouvrir ne serait-ce qu'une seule fois
le header. Les macros analysent syntaxiquement pour écrire
__correctement__ dans les deux fichiers(ajouter dans l'un,
modifier dans l'autre), ajouter les includes si besoin est, et
sauf coquilles de ma part, c'est immédiatement compilable. Et
ce, sans quitter le clavier des mains.
Bon cela je peux le faire aujourd'hui pour les cas les plus
fréquents, il y aura toujours des cas que je n'ai pas encore
traites où je dois quitter l'édition du fichier courant.



Ça ressemble un peu à comment Rose fonctionne. Dans ce cas-là,
ça peut être intéressant. (Mais le vrai intérêt de Rose, c'est
la documentation graphique des rapports entre les classes.)

Toutes fois est-il que je ne saisis pas comment ça peut marcher.
Comment fais-tu, par exemple, savoir dans les macros les noms
et les types des variables membres ?



Un cas simple, dans un .CPP je tape , par exemple : <Declarateur> <NomObjet>
, (eventuellement suivi d'une initialisation) suivi d'un jeu de touches
pour, être précis 2.
La macro qui est lancée va lire la ligne sur laquelle je suis, extraire le
nom de <Declarateur> (qui peux être une déclaration quelconque : pointeur,
référence, classe, classe paramétrée ), puis avec le fichier en cours
d'édition va déterminer le nom du header et ajouter cette nouvelle
déclaration de l'objet. Et va modifier le fichier courant en supprimant le
<Declateur>.
De même pour une fonction membre, mais là c'est un peu plus complexe, mais
dans la même optique, je tape une ligne et un raccourci, et c'a mouline à ma
place.
Comme je disais : la machine, ce genre d'opérations répétitives le fait
mieux et plus vite que moi, alors je perds un peu de temps pour écrire les
macros et après c'est que du bonheur. Heu ... surtout le bonheur, de me dire
"tiens, on peut faire encore mieux...".
Avatar
James Kanze
On Dec 7, 5:18 pm, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe de
discussion :




> On Dec 7, 11:02 am, "Senhon" wrote:
>> "James Kanze" a écrit dans le
>> message de groupe de discussion :
>>



>> [...]
>> La souris je l'utilise pour selectionner des champs, des
>> blocs, pour naviguer le cas échéant, mais comme je te le
>> disais, je crée mes projets, mes classes, mes fonctions, mes
>> attributs,à l'aide de raccourcis qui appellent des macros qui
>> me déchargent d'un boulot monstrueux.



> Pour la création des projets, etc., je ne vois pas trop de
> problèmes. Mais pour sélectionner un champs dans un fichier de
> sources, ça ralentira beaucoup d'avoir à me servir de la souris.



Houlala, j'ai parler de sélectionner des champs, d'accord :
- mais c'était pour donner un exemple, je sui pas en permanence en train
de sélectionner des champs, cela m'arrive, mais y a pas de quoi s'en
émouvoir.
- Et puis la sélection d'un champ ou d'un bloc peut se faire sans l a
souris.



Une nouvelle fois, tu te bloques sur la souris, alors que le
PB est plutôt "philosophie du produit".



D'après ce que je vois (autour de moi, et avec quelques
exceptions), il me semble que la philosophie du produit, c'est
de choisir des actions prédéfinies des menus, en se servant de
la souris. Je sais qu'il offre d'autres possibilités, mais dans
la pratique, c'est ce que je vois avec les utilisateurs des IDE
(non seulement VS). Tandis que l'utilisation des commandes
sur mesure, prédéfinies, semble plutôt l'appenage des
utilisateurs de la ligne de commande.

Enfin, ça, c'est les utilisateurs que j'ai vu. Rien ne dit que
tout le monde soit comme ça ; en fait, tu sembles utiliser VS
comme les power users de Unix utilisent leurs outils ligne de
commande. Mais il faut dire que quand tu entends parler de VS
(ou Eclipse, ou Sun Studio), c'est toujours présenté avec des
Wizards et al. qui permet à faire des travaux simples sans trop
penser, de la façon prévue d'avance. Regarde donc tous les
postings dans les groupes qui parlent d'une mode debug et d'une
mode release (et qui dit bêtement qu'en mode release, assert est
un no-op), simplement parce que c'est ce que VS offre par
défaut. Il ne leur vient pas à l'ésprit qu'il faut définir les
modes dont on a besoin (et pour la plupart des applications, ça
veut dire une seule mode, parce qu'on veut tester et débogguer
ce qu'on livre, et non quelque chose à peu près semblable), en
fonction des exigeances de son application et son procès de
développement.

>> A titre d'exemple, je peux monter une classe, avec ces
>> fonctions membres, ses attributs, juste en affichant à
>> l'écran que le .CPP, sans jamais ouvrir ne serait-ce qu'une
>> seule fois le header. Les macros analysent syntaxiquement
>> pour écrire __correctement__ dans les deux fichiers(ajouter
>> dans l'un, modifier dans l'autre), ajouter les includes si
>> besoin est, et sauf coquilles de ma part, c'est
>> immédiatement compilable. Et ce, sans quitter le clavier
>> des mains. Bon cela je peux le faire aujourd'hui pour les
>> cas les plus fréquents, il y aura toujours des cas que je
>> n'ai pas encore traites où je dois quitter l'édition du
>> fichier courant.



> Ça ressemble un peu à comment Rose fonctionne. Dans ce cas-là,
> ça peut être intéressant. (Mais le vrai intérêt de Rose, c'es t
> la documentation graphique des rapports entre les classes.)



> Toutes fois est-il que je ne saisis pas comment ça peut marcher.
> Comment fais-tu, par exemple, savoir dans les macros les noms
> et les types des variables membres ?



Un cas simple, dans un .CPP je tape , par exemple : <Declarateur> <NomObj et>
, (eventuellement suivi d'une initialisation) suivi d'un jeu de touches
pour, être précis 2.
La macro qui est lancée va lire la ligne sur laquelle je suis, extraire le
nom de <Declarateur> (qui peux être une déclaration quelconque : poin teur,
référence, classe, classe paramétrée ), puis avec le fichier en c ours
d'édition va déterminer le nom du header et ajouter cette nouvelle
déclaration de l'objet. Et va modifier le fichier courant en supprimant le
<Declateur>.



Je ne suis pas sûr d'avoir compris ce que tu fais exactement,
mais ce n'est pas grave. Si j'ai bien compris, c'est un macro
d'éditeur que tu as défini (et non quelque chose fourni en
standard par Microsoft). Dans ce cas-là, tout ce que je peux
dire, c'est que tu es en train de travailler dans la vieille
tradition Unix, et surtout emacs. (Le vrai emacsien réécrit
l'éditeur.) Que tu puisses le faire dans VS, c'est bien ;
peut-être VS n'est pas si mauvais que ça. Mais ce n'est pas
comme ça que la plupart des utilisateurs que j'ai vu
travallent ; ce mode de travailler semble bien être plutôt celui
de Unix (dont la philosophie de base est de faire fonctionner
ensemble de petits outils au moyen des scripts écrits par
l'utilisateur). Et c'est clair que ça dépasse le « pointer et
cliquer » que vendent les IDE.

De même pour une fonction membre, mais là c'est un peu plus
complexe, mais dans la même optique, je tape une ligne et un
raccourci, et c'a mouline à ma place.
Comme je disais : la machine, ce genre d'opérations
répétitives le fait mieux et plus vite que moi, alors je perds
un peu de temps pour écrire les macros et après c'est que du
bonheur. Heu ... surtout le bonheur, de me dire "tiens, on
peut faire encore mieux...".



Ce que tu viens de décrire, c'est bien la philosophie Unix,
telle que Kernighan et Pike l'expliquait il y a bien d'années
dans _The Unix Programming Environement_ (et qui c'est un peu
perdu depuis -- la philosophie « pointer et cliquer » envahit
Unix aussi).

--
James Kanze
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 7, 5:18 pm, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe
de
discussion :




> On Dec 7, 11:02 am, "Senhon" wrote:
>> "James Kanze" a écrit dans le
>> message de groupe de discussion :
>>




D'après ce que je vois (autour de moi, et avec quelques
exceptions), il me semble que la philosophie du produit, c'est
de choisir des actions prédéfinies des menus, en se servant de
la souris. Je sais qu'il offre d'autres possibilités, mais dans
la pratique, c'est ce que je vois avec les utilisateurs des IDE
(non seulement VS). Tandis que l'utilisation des commandes
sur mesure, prédéfinies, semble plutôt l'appenage des
utilisateurs de la ligne de commande.



Ont-il au moins la bonne version, s'il utilise VS 200x Express, tout n'est
pas inclus ?

[....]

Je ne suis pas sûr d'avoir compris ce que tu fais exactement,
mais ce n'est pas grave. Si j'ai bien compris, c'est un macro
d'éditeur que tu as défini (et non quelque chose fourni en
standard par Microsoft).



C'est bien ça, ce sont des macros écrites avec mes petits doigts.

Dans ce cas-là, tout ce que je peux
dire, c'est que tu es en train de travailler dans la vieille
tradition Unix, et surtout emacs. (Le vrai emacsien réécrit
l'éditeur.) Que tu puisses le faire dans VS, c'est bien ;
peut-être VS n'est pas si mauvais que ça.



Nous sommes d'accord.

Mais ce n'est pas
comme ça que la plupart des utilisateurs que j'ai vu
travallent ; ce mode de travailler semble bien être plutôt celui
de Unix



Moi aussi j'ai autour de moi une quantité de personnes qui font du
développement juste à titre alimentaire ( je ne veux pas les accabler ).
Du coup, il se contente très vite et n'iront pas forcément se casser la tête
...
Avatar
James Kanze
On Dec 9, 7:49 am, "Senhon" wrote:
"James Kanze" a écrit dans le message
de groupe de discussion :

> On Dec 7, 5:18 pm, "Senhon" wrote:
>> "James Kanze" a écrit dans le
>> message de groupe de discussion :
>>



>> > On Dec 7, 11:02 am, "Senhon" wrote:
>> >> "James Kanze" a écrit dans le
>> >> message de groupe de discussion :
>> >> .



> D'après ce que je vois (autour de moi, et avec quelques
> exceptions), il me semble que la philosophie du produit,
> c'est de choisir des actions prédéfinies des menus, en se
> servant de la souris. Je sais qu'il offre d'autres
> possibilités, mais dans la pratique, c'est ce que je vois
> avec les utilisateurs des IDE (non seulement VS). Tandis que
> l'utilisation des commandes sur mesure, prédéfinies, semble
> plutôt l'appenage des utilisateurs de la ligne de commande.



Ont-il au moins la bonne version, s'il utilise VS 200x
Express, tout n'est pas inclus ?



C'est que j'ai chez moi, mais au travail, on a toujours eu la
version professionnelle.

[....]
> Je ne suis pas sûr d'avoir compris ce que tu fais
> exactement, mais ce n'est pas grave. Si j'ai bien compris,
> c'est un macro d'éditeur que tu as défini (et non quelque
> chose fourni en standard par Microsoft).



C'est bien ça, ce sont des macros écrites avec mes petits
doigts.



> Dans ce cas-là, tout ce que je peux dire, c'est que tu es en
> train de travailler dans la vieille tradition Unix, et
> surtout emacs. (Le vrai emacsien réécrit l'éditeur.) Que tu
> puisses le faire dans VS, c'est bien ; peut-être VS n'est
> pas si mauvais que ça.



Nous sommes d'accord.



> Mais ce n'est pas comme ça que la plupart des utilisateurs
> que j'ai vu travallent ; ce mode de travailler semble bien
> être plutôt celui de Unix



Moi aussi j'ai autour de moi une quantité de personnes qui
font du développement juste à titre alimentaire ( je ne veux
pas les accabler ). Du coup, il se contente très vite et
n'iront pas forcément se casser la tête ...



Peut-être le problème que certains (comme moi-même) apercoivent
avec les IDE, c'est qu'ils permettent ce genre de dévelopement.
Tandis que devant la ligne de commande Unix, il faut bien
apprendre un peu. (Bien que j'ai connu quelques uns qui s'en
sortaient là aussi avec un strict minimum. Si on ne veut pas
apprendre, on n'apprend pas, quelque soit l'environement. Et
vice versa.)

--
James Kanze
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 9, 7:49 am, "Senhon" wrote:

Peut-être le problème que certains (comme moi-même) apercoivent
avec les IDE, c'est qu'ils permettent ce genre de dévelopement.



Vaste débat : est-ce le produit ou l'usage ?

Tandis que devant la ligne de commande Unix, il faut bien
apprendre un peu.



Attitude un peu nostalgique, non ?

(Bien que j'ai connu quelques uns qui s'en
sortaient là aussi avec un strict minimum. Si on ne veut pas
apprendre, on n'apprend pas, quelque soit l'environement. Et
vice versa.)


9 10 11 12 13