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
8 9 10 11 12
Avatar
James Kanze
On Dec 4, 9:54 am, Michael Doubez wrote:
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



En fait, je m'étais mal rappelé de syntaxe.

:args ` find . -name '*.cpp' -o -name '*.h' | xargs egrep -l `
:argdo g/DECLARE_TOTO/s/$/;/

marche très bien, même sous Windows.

--
James Kanze
Avatar
James Kanze
On Dec 4, 10:12 am, "Senhon" wrote:
"James Kanze" a crit dans le message de groupe de
discussion :

> On Dec 4, 8:03 am, "Senhon" wrote:



[...]
Bon c'est partir de l que je trouve que tu divagues, je
m'attendait pas ce que tu me parles de CMD.EXE, Tu peux pas me
voir, mais je me marre, ... CMD.EXE, houlala, lala, trop dr
le. Si je peux me permettre un conseil, laisser tomber la
voie du CMD.EXE, tu tout fait l'oppos .



C'est ce que j'ai fait. Je l'ai remplacé par bash.

[...]
Ce que j'aurais fait c'est : utiliser l'enregistrement de
macro, tu le fais une fois, la machine le répéte.



Cette possibilité existe (et en vim, et en emacs). Mais il faut
toujours l'invoquer sur chaque fichier ; c'est le :argdo qui
m'intéresse ici, ainsi que le :g (qui fait executer la commande
sur chaque ligne où se trouve la chaîne cherchée). (Quand la
commande est plus complexe qu'un simple replacement, je crée
bien le macro, mais je me sers toujours de :argdo, et :g si
nécessaire, pour l'invoquer dans tous les fichiers, sur toutes
les lignes qu'il faut.)

Ce que permet VS dans ce genre de cas, c'est par exemple :
t'apercevoir que c'a modifi aussi dans des endroits que tu ne
voulais pas, alors par un jeu de touche (ctrl-backspace)
revenir en arrière, êditer la macro pour la complèter et la
rejouer. La conserver, peut-être en la parametrisant, pour te
simplifier encore plus la vie.



C'est effectivement bien. Le undo, ça existe évidemment à peu
près partout, mais je ne sais pas si on peut éditer les macros
saisi à la volée en vim. (On peut évidemment éditer les macros
qu'on définit dans son fichier de configuration. Vue que c'est
un fichier.)

> [...]
>(Par travailler, ici, j'entends d velopper des logiciels.
>Pour beaucoup d'autres choses, on peut bien tre plus
>productif sous Windows que sous Unix -- Star Office est loin
>de MS Office, par exemple.)



Et pourtant qu'est-ce qu'on pas entendu comme stupidit s ce
sujet, comme avec IE/firefox, Windows/linux, propriètaire/open
source..



Je sais. Ça m'énerve aussi. Mais ce n'est pas le cas chez moi
(qui préfère Solaris à Linux, de loin, et qui reconnais que même
Windows, c'est beaucoup plus stable que Linux).

--
James Kanze
Avatar
James Kanze
On Dec 4, 10:56 am, "Senhon" wrote:
"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.



En effet, je les ai remplacé par des fenêtres bash. (Mais
cmd.exe, ce n'est pas si mal que ça. Microsoft a fait d'énorme
progrès par rapport aux shell d'origine.)

> marquer un bloc dans une source sous l' diteur VS, puis de
> le filtrer travers une commande (compos e souvent, avec des
> pipes) arbitraire disponible dans une fen tre de commande.



>> - tu ne sais pas comment travailler en gardant les mains sur le
>> clavier.



> Non. Je crois en fait que c'est possible, mais je ne sais pas le
> faire, et mes coll gues ne savent pas me le montrer.



> Pour l'instant, je n'ai pas trouv de tutorial sur l' diteur,



Clique tout va s'est la meilleur chose faire :-))



Le problème, c'est que pour cliquer, il faut que j'éloigne mes
mains du clavier.

[...]
> L'interface graphique peut tre tr s utile dans beaucoup de
> cas, mais par la force de chose, elle ne sera jamais aussi
> puissant qu'une interface ligne de commande ;



Houlala, ... comme par corriger cette appr ciation fausse.



Ce n'est pas une « appréciation », c'est une simpl e constatation
des faits. Tu peux exprimer beaucoup plus avec des caractères
classique qu'avec n'importe quel jeu de menus. (Tu ne te sers
pas de la souris pour entrer ton programme C++, quand mėme.)

> dans l'interface graphique, tu ne pourrais jamais faire que
> ce qui est pr vu par l'interface. Pour combiner les
> commandes d'une fa on arbitraire, il faut une ligne de
> commande.



> Mais la pr sence d'une n'en exclut pas la pr sence de l'autre,
> et si j'utilise pr squ'exclusivement l'interface clavier quand



Je ne peux rien pour toi, tu dois en passer par o la plupart
d'entre nous sont oblig s de passer (moi aussi cela va sans
dire) : remets-toi en cause. Ton approche est
contreproductive ( Mais alors a un un point ! )



Tellement contreproductive que ma productivité dépasse de loin
tous les gens qui travaillent avec la souris:-). (Pas à
l'instant, forcément, parce que j'apprends un nouvel
environement, mais en général, je constate que j'arrive beaucoup
plus rapidement que mes collegues.)

[...]
>> - Je suis comme toi, si je dois quitter le clavier des doigts cela
>> m'agace. Mais je n'ai pas ce ressenti lors de l'utilisation
>> de VS, bien au contraire.



> a, je veux bien le crois. Est-ce que tu pourrais m'aiguiller
> vers un tutorial, ou m me un document quelconque, qui
> explique tous les commandes clavier ?



Un tutoriel ? je ne sais pas , j'en ai pas eu besoin.
De ce que je me souviens les raccourcis se trouvent afficher dans les men us.



Oui. Mais que les raccourcis pour des choses accessibles depuis
les menus. Et les menus, par définition, c'est limité.

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

On Dec 4, 10:12 am, "Senhon" wrote:
"James Kanze" a crit dans le message de groupe de
discussion :

> On Dec 4, 8:03 am, "Senhon" wrote:



[...]
le. Si je peux me permettre un conseil, laisser tomber la
voie du CMD.EXE, tu tout fait l'oppos .



C'est ce que j'ai fait. Je l'ai remplacé par bash.



Pardon de m'être exprimé aussi mal, je voulais dire : la voie de
l'interprèteur de commande n'est pas la bonne.

[...]



C'est effectivement bien. Le undo, ça existe évidemment à peu
près partout, mais je ne sais pas si on peut éditer les macros
saisi à la volée en vim. (On peut évidemment éditer les macros
qu'on définit dans son fichier de configuration. Vue que c'est
un fichier.)




L'enregistrement de macro à la volée, permet de mettre in pied à l'étrier
...
Avatar
Jean-Marc Bourguet
"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?

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Senhon
"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.


> Pour l'instant, je n'ai pas trouv de tutorial sur l' diteur,



Clique tout va s'est la meilleur chose faire :-))



Le problème, c'est que pour cliquer, il faut que j'éloigne mes
mains du clavier.



Dans la perspective d'utiliser un tutoriel serais-tu prêt à lacher ton
clavier ?
Cliquer à tout va, s'entendait comme : faire le tour du "propriétaire", dans
un but éducatif.



Ce n'est pas une « appréciation », c'est une simple constatation
des faits. Tu peux exprimer beaucoup plus avec des caractères
classique qu'avec n'importe quel jeu de menus. (Tu ne te sers
pas de la souris pour entrer ton programme C++, quand mėme.)



J'utilise tout ce qui est à ma portée, pour peu que se soit efficace.


> dans l'interface graphique, tu ne pourrais jamais faire que
> ce qui est pr vu par l'interface. Pour combiner les
> commandes d'une fa on arbitraire, il faut une ligne de
> commande.



> Mais la pr sence d'une n'en exclut pas la pr sence de l'autre,
> et si j'utilise pr squ'exclusivement l'interface clavier quand



Je ne peux rien pour toi, tu dois en passer par o la plupart
d'entre nous sont oblig s de passer (moi aussi cela va sans
dire) : remets-toi en cause. Ton approche est
contreproductive ( Mais alors a un un point ! )



Tellement contreproductive que ma productivité dépasse de loin
tous les gens qui travaillent avec la souris:-). (Pas à
l'instant, forcément, parce que j'apprends un nouvel
environement, mais en général, je constate que j'arrive beaucoup
plus rapidement que mes collegues.)



Bon ben, c'est très bien, alors.


[...]

> a, je veux bien le crois. Est-ce que tu pourrais m'aiguiller
> vers un tutorial, ou m me un document quelconque, qui
> explique tous les commandes clavier ?



Un tutoriel ? je ne sais pas , j'en ai pas eu besoin.
De ce que je me souviens les raccourcis se trouvent afficher dans les
menus.



Oui. Mais que les raccourcis pour des choses accessibles depuis
les menus. Et les menus, par définition, c'est limité.




Parce que tu sais utiliser Vim et emacs, il faudrait que VS fonctionne
suivant le même plan.
A ce sujet, n'as-tu pas vu passer un mail qui parlait d'une extension de VS
émulant VIM, peut-être, une bonne voie ...
Avatar
James Kanze
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.

>> > Pour l'instant, je n'ai pas trouv de tutorial sur l'
>> > diteur,



>> Clique tout va s'est la meilleur chose faire :-))



> Le problème, c'est que pour cliquer, il faut que j'éloigne
> mes mains du clavier.



Dans la perspective d'utiliser un tutoriel serais-tu prêt à
lacher ton clavier ?



Pendant l'utilisation du tutoriel, oui. Comme j'ai déjà dit par
ailleurs, quand je butine, j'utilise surtout la souris. Utiliser
la souris, c'est bien. Utiliser le clavier, c'est bien. Avoir à
passer de l'un à l'autre, ça un coût très élevà © en termes de
productivité. Or, vue que je n'ai jamais vu en système où on
pouvait entrer du code avec la souris, quand je saisis du code,
il faut un système qui utilise prèsqu'exclusivement le clavier.

Cliquer à tout va, s'entendait comme : faire le tour du
"propriétaire", dans un but éducatif.



Est-ce que je dois cliquer aussi pour entrer du code ? (C'était
bien une solution offerte sur le Xerox Star -- l'ancêtre de tous
nos GUI. Mais autant que je sache, personne ne s'en servait.)

> Ce n'est pas une « appréciation », c'est une simple
> constatation des faits. Tu peux exprimer beaucoup plus avec
> des caractères classique qu'avec n'importe quel jeu de
> menus. (Tu ne te sers pas de la souris pour entrer ton
> programme C++, quand mėme.)



J'utilise tout ce qui est à ma portée, pour peu que se soit
efficace.



Mais avoir constamment à déplacer les mains de la position de
base sur le clavier, ce n'est pas efficace. Regarde par exemple
les utilisateurs de vim, qui prèsque tous reprogramme le clavier
pour que la touche ESC soit accessible sans déplacer les mains.
(Vim utilise énormement la touche ESC.)

Chaque fois que tu changes du clavier à la souris, ou
vice-versa, il faut que tu regardes tes mains. En gros, il te
coûte en temps ce qu'il faut pour cinq ou six caractères frappà ©s
au clavier.

--
James Kanze
Avatar
Senhon
"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.
Avatar
espie
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).
Avatar
Senhon
"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 ...
Mais tu m'a l'air de franchement galérer.

[...]

Est-ce que je dois cliquer aussi pour entrer du code ?



Hé, mais t'es serieux là ?

(C'était
bien une solution offerte sur le Xerox Star -- l'ancêtre de tous
nos GUI. Mais autant que je sache, personne ne s'en servait.)



Pas étonnant.



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 ?


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.

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.

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