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
7 8 9 10 11
Avatar
James Kanze
On Dec 3, 4:51 pm, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe de
discussion :

> On Dec 3, 12:07 pm, Michael Doubez wrote:
>> On 3 déc, 11:56, "Senhon" 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.



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
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 3, 9:22 am, Michael Doubez wrote:
On 2 déc, 18:18, James Kanze 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 ?




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



[....]

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.
Avatar
James Kanze
On Dec 4, 8:03 am, "Senhon" wrote:
"Alexandre Bacquart" a écrit dans le message de
groupe de discussion : 4b17f6a5$0$18404$



[...]
> 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 Win dows 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
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 3, 4:51 pm, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe
de
discussion :

> On Dec 3, 12:07 pm, Michael Doubez wrote:
>> On 3 déc, 11:56, "Senhon" 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.



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.



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




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



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



>> > [...]
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 clavi er.



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 j our
peut-être, tu auras une meilleur orientation, moins braqué, et là l es 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 utili sé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 a u
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
Avatar
Michael Doubez
On 4 déc, 10:01, James Kanze wrote:
[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
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 4, 8:03 am, "Senhon" wrote:
"Alexandre Bacquart" a écrit dans le message de
groupe de discussion : 4b17f6a5$0$18404$



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



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..
Avatar
Michael Doubez
On 3 déc, 15:42, Alain Ketterlin wrote:
AG writes:
> 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'afficheraien t
> 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 t out 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.



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
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 3, 4:43 pm, "Senhon" wrote:
"James Kanze" 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.

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.
Avatar
Alexandre Bacquart
James Kanze wrote:
À 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).



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
7 8 9 10 11