une petite question
 
pour l'utilisation des deux expressions suivantes :

 
le resultat lors de l'execution du programme est le même mais en est-t-il de même pour la memoire ?

const sans hésiter :
- typage
- aussi rapide que la macro
- tu peux prendre l'addresse
- const implique une portée statique, donc au final, tu les avantages, mais ça ne coute rien de plus

Une macro (le #define) n'est qu'une chaîne de caractères qui sera remplacée à chaque occurence dans ton code. Donc en terme d'occupation mémoire nada! Par contre, impossible de debogguer (aucune existence physique) et non typé. Quand on fait du C++, il FAUT abandonner le #define du C (sauf flags de compilation ou pour des usages particuliers). Je te recommande "Effective C++" de Scott Meyers pour connaître les bons trucs pour programmer en C++.

 
 
tu pourras peut-être expliquer comment on arrive à trouver la donnée a l'exécution, dans ce cas ...

on parle de mode debug hein
 
autrement, une constante const n'a aucune existance physique non-plus ...

(C++) always const for me  
(C) always #define
 
L'utilisation de const est moins interessante en C-ANSI qu'en C++.

 
Une declaration comme, par exemple const int N=5
est equivalante a :
 
en C++ :     static const int N=5
en C-ANSI :  extern const int N=5
 
Ce qui empeche en C-ANSI de placer la definition d'une constante dans un fichier d'en-tete.
(Probleme a l'edition de liens si ce fichier est importe (#include) par plusieurs modules)

Pas clair ton histoire "trouver la données à l'exécution"...  
 
Une variable occupe un espace mémoire du programme, un #define non: il fait partie intégrante du programme. J'ai jamais pu voir la valeur affectée à mon #define avec le debugger (VC++ 6.0). Si tu y arrives fais moi signe.  

Si je ne m'abuse, ca se retrouve dans le segment de données du programme (.text, non ?) et lorsqu'on fait un #define sur une chaine, par exemple, pour chaque objet (.o) compilé ayant le #define, on aura une occurrence de ladite chaine dans le code produit, alors qu'avec un extern const, la chaine ne s'y trouvera évidemment qu'une fois. Je suis d'accord sur le fait que ca n'encombre pas les zones de mémoire qu'on utilise pour les variables, mais les données en question se retrouvent bien chargées en mémoire à terme et y occuppent toujours de la place.

tu penses bien que les chaines sont unifiées et que t'en as pas 36 copies hein

j'ai vérifié avant de faire ca, tu mets ton #define dans un .h et deux fichiers C qui l'incluent, et avec gcc (enfin, mingw pour mes tests) on se retrouve avec la chaine en double dans l'exe ...
 
Edit : j'imagine qu'il ne peut pas faire le lien entre les différentes versions de la chaine dans les différents .c simplement parce qu'il n'a pas de symbole associé

Exact theShOckKwAvE (t'a pas un nom plus simple?). Au final le #define prend certainement plus de place... sur le disque, en mémoire je ne suis vraiment pas sûr.
C'est pour cette raison que le premier qui arrive à débugger la valeur du #define il me fait signe!
De toute façon les constantes par #define c'est bon pour le C, en C++ faut utiliser les variables const.

le #define remplace  l'expression dans le code avant la compilation (preprocesseur)!
ce qui doit impliquer plussieurs declaration d'une meme  
variable je pense (à voir a la compil)
 
avantage du const qui lui a une portée locale(internal linkage) donc une seul reference a l'interieur d'un meme bloc/classe de plus il est typé ce qui implique des verifs de la part du compilo(+ clean)!
en gros ce qu'a dit Taz.
 
 
En C++ c'est du const pour declarer des constantes!
et le #define pour plein d'autre chose flag de compil, debut/fin de sous-routines de methodes  
pour eviter des redondances de codes etc...

on doit pas avoir le meme gcc

j'ai précisé que c'était mingw, et j'ai fait ca sur un exemple assez simple :
 

et qu'est-ce qui te dit que la chaine est 2x présente dans le binaire ?

Tu l'édites en hexadécimal non?
 
En tout cas avec Visual c'est clairement ce qu'il se passe.

éditeur hexa
et la chaine incriminée apparait en un exemplaire pour chaque fichier compilé incluant common.h. De même, si je rajoute n fichiers du style

j'obtiens n occurrences supplémentaires de la chaine dans le fichier exécutable

Il y a une option de compilation dans gcc qui sert à controler si oui ou non il faut dupliquer les strings dans l'exe obtenu dans ce cas. Ce n'est pas fait par défaut parceque certaines personnes s'ammusent à modifier ces chaines et que si on les réunies cela fait des bugs difficiles à comprendre.

bah avec les vieilles versions de gcc oui. maintenant on est en 2005

toujours est-il que, même pour du C, je préfère éviter les #define et mettre des extern aux endroits appropriés. Sinon, ma version de minGW est assez récente (date d'un mois ou deux) donc j'imagine que cette fonctionnalité du compilo (rassembler les lignes identiques) n'est toujours pas activée par défaut
 
Edit : bon, ok, je viens de vérifier, j'ai la 3.4.2 ... en clair, j'ai récupéré ma version une ou deux semaines avant qu'ils ne passent à la 3.4.4, peut-être que ca a changé depuis

Remarquez que les macros ont des applications contre le piratage plutôt intéressantes.

-fstring-no-duplciate pour gcc < 3.4.4

d'facon l'informatique ca sux surtout la programmation et surtout le C++

meme en C++ , #define joue un role important :  
 
elle remplace les fonctions inline ce qui est interressant  
 
pour un bon programmeur       !!

Options -fmerge-constants et -fmerge-all-constants de gcc 4.0. C'est assez recent pour toi ou il faut que j'aille chercher ma machine à voyager dans le temps pour prendre une version future ?

ben ça le fait par défaut chez moi en O2

 
je dirais plutot l'inverse : l'inline du c++ remplace les #define de fonction du C.

 
Comment perdre toute crédibilité en 1 leçon.
 
C'est quoi deja le Smiley "Fortune" ???

 
vous ferez mieux si vous essayez de visiter le faq de [url]
 
http://c.developpez.com/faq/cpp[/url] .
 
 
 

Bon puisque tu veux jouer à ça LIT CORRECTEMENT LA PAGE QUI SUIT:
 
http://c.developpez.com/faq/cpp/?p [...] LINE_macro

adm1n1s7ra7eur : je crosi que sur ce poitn tu n'as rien à m'apprendre ... et bon developpez.com 'na jamasi été un site de reference vraiment correct ...

 
  , tu es sur de que tu viens de dire    
 
 

 
LIT ET RELIT ce paragraphe    
 
 

oui ...
 
Et ce n'est pas parce que les fonctions inline générent du code blaot qu'il faut ls abnnir. Hein
Apprendre à inliner ca aide beaucoup. Alors s'il te plait remballe tes et va faire joujou ailleurs

FANTASTIQUE! Monsieur veut m'apprendre comment le précompilateur traite les MACROS C.
 
Bon je laisse tomber ça en vaut pas la peine.

 
 

 
une macro poserait le même problème, hein ...

Oui une macro pose exactement le même problème, le code est duppliqué à chaque occurence. Enfin apparement ça peut se régler sur certains compilos.

En plus, le compilateur n'est pas tenu d'honorer l'inlining s'il trouve ça pénalisant (surtout pour les architectures "pauvres" en registres).
C'est un sacré avantage par rapport aux macros.

 
 
un avis personnel : les fonctions inline n'ont pas d'important role  
 
à jouer    .
 
je prefere utiliser les macros  .
 
si je suis obligé à utiliser des fonctions ,j'essaie d'éloigner le  
 
compilo et d'y faire du code assembleur    comme ça le temps  
 
d'execution sera court .