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
6 7 8 9 10
Avatar
Michael Doubez
On 3 déc, 11:56, "Senhon" wrote:
"Michael Doubez" a écrit dans le message de gr oupe
de discussion :
> On 3 déc, 09:50, "Senhon" wrote:
>> "James Kanze" a écrit dans le message de gro upe
>> 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  :-))



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

On 3 déc, 11:56, "Senhon" wrote:
"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 :-))



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
...
Avatar
Alain Ketterlin
AG writes:

Je travaille dans une équipe de personnes pour lesquels le débu gger
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'afficheraie nt
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'a i 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.
Avatar
James Kanze
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 :
>>



> [...]
>> 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
Avatar
James Kanze
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, a lors
> 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 pa s.

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
Avatar
James Kanze
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 ?



> 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 à l a
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ço n à
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
Avatar
Senhon
"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 :
>>



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



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.
Avatar
Senhon
"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.
Avatar
Alexandre Bacquart
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.



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
Avatar
Senhon
"Alexandre Bacquart" a écrit dans le message de
groupe de discussion : 4b17f6a5$0$18404$
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.



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é.
6 7 8 9 10