Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
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
5 6 7 8 9
Avatar
Senhon
"Jean-Marc Bourguet" a écrit dans le message de groupe de
discussion :
"Senhon" writes:

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





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



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

On Dec 1, 2:29 pm, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe
de
discussion :








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é.
Avatar
James Kanze
On Dec 2, 9:21 am, Marc Boyer
wrote:
Le 01-12-2009, James Kanze a écrit :



> On Dec 1, 2:27 pm, Marc Boyer
> 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
Avatar
James Kanze
On Dec 2, 8:50 am, "Senhon" wrote:
"James Kanze" a écrit dans le message
de groupe de discussion :




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




"AG" a écrit dans le message de news:

On Nov 30, 5:10 pm, Fabien LE LEZ 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 '', 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.
Avatar
Senhon
"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 :




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


(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.
Avatar
James Kanze
On Dec 2, 10:56 pm, "luther13" wrote:
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
Avatar
Michael Doubez
On 2 déc, 18:18, James Kanze wrote:
On Dec 2, 8:50 am, "Senhon" wrote:
> "James Kanze" a écrit dans le message
> de groupe de discussion :
>
    [...]
> >> 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.



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
Avatar
Michael Doubez
On 3 déc, 09:50, "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 :
>>

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



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

On 3 déc, 09:50, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe
de
discussion :




> 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_id1038
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.
5 6 7 8 9