Directive de compilation
Le
Zlika
Bonjour à tous.
Mon programme utilise massivement un objet "Matrice" que j'ai crée.
Cet objet effectue de nombreuses vérifications afin de s'assurer que l'on
lit/écrit bien dans les limites du tableau. ça évite les débordements
mémoire mais ça à l'inconvénient d'etre lent.
L'idée que j'ai (mais je ne sais pas si c'est possible) serait d'utiliser
une directive de compilation permettant de ne compiler les bouts de codes
effectuant les vérifications que si on compile le programme en mode debug
(-g).
Par exemple, ça donnerai un truc genre:
#ifdef __debug__
if ((i<n_lignes)&&(j<n_colonnes))
mat[i][j] = element;
#endif
J'ai cherché sur le net mais je n'ai pas trouvé une telle directive de
compilation. Est-ce qu'elle existe? Sinon, comment faire la meme chose sans?
Merci
Zlika
Mon programme utilise massivement un objet "Matrice" que j'ai crée.
Cet objet effectue de nombreuses vérifications afin de s'assurer que l'on
lit/écrit bien dans les limites du tableau. ça évite les débordements
mémoire mais ça à l'inconvénient d'etre lent.
L'idée que j'ai (mais je ne sais pas si c'est possible) serait d'utiliser
une directive de compilation permettant de ne compiler les bouts de codes
effectuant les vérifications que si on compile le programme en mode debug
(-g).
Par exemple, ça donnerai un truc genre:
#ifdef __debug__
if ((i<n_lignes)&&(j<n_colonnes))
mat[i][j] = element;
#endif
J'ai cherché sur le net mais je n'ai pas trouvé une telle directive de
compilation. Est-ce qu'elle existe? Sinon, comment faire la meme chose sans?
Merci
Zlika
Poser une question
On utilise souvent la macro NDEBUG. Elle est utilisée, par exemple,
par assert(), qui n'est pas compilée si NDEBUG est définie.
Attention, c'est l'inverse de l'exemple que tu donnes: si NDEBUG est
définie, c'est qu'on n'est *pas* en mode debug. Utilise donc ifndef
au lieu de ifdef.
Tu peux écrire:
#ifndef NDEBUG
verifications();
#endif
Ou simplement:
assert(verifications());
Pour compiler une version release, tu peux ajouter #define NDEBUG dans
ton source, ou (mieux) demander au compilateur de définir la macro
lui-même. Par exemple avec l'option -DNDEBUG (voir la doc de ton
compilo).
--
André Heinen
Mon e-mail, encodé ROT13: n qbg urvara ng rhebcrnayvax qbg pbz
La FAQ: http://www.cmla.ens-cachan.fr/Utili...s/C++/FAQ/
Est-ce que cette macro NDEBUG (et l'option -DNDEBUG) font partie de la norme
ou est-ce uniquement compatible avec GCC?
Zlika
en compte par la macro assert() et est définie en C dans assert.h
--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo
Pierre Maurette
Je précise pour l'OP que si la macro elle-même est standard, la façon
dont on demande au compilo de définir une macro dépend évidemment du
compilo utilisé. Avec un des miens, c'est -DNDEBUG. Avec un autre,
c'est /DNDEBUG. Avec d'autres encore, on doit changer quelque chose
dans une boîte de dialogue.
Autrement dit, tu peux écrire un source standard qui conviendra pour
tous les compilos, mais la façon de le compiler variera.
--
André Heinen
Mon e-mail, encodé ROT13: n qbg urvara ng rhebcrnayvax qbg pbz
La FAQ: http://www.cmla.ens-cachan.fr/Utili...s/C++/FAQ/
En théorie, c'est juste. Dans la pratique, je n'ai jamais vu un
compilateur qui n'accepte pas -DNDEBUG quand on l'invoque en
ligne de commande (même si, sous Windows, la forme « préférée »
est /DNDEBUG).
Si ceci était le seul problème, on pourrait s'en tirer avec
-DNDEBUG. Dans la pratique, il faut prèsque toujours une
dizaines d'options pour avoir quelque chose de bien. Alors, du
coup, il y a tant de dépendances dans les fichiers make qu'on
n'est plus à un changement de - en / près.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34