Discussion :

[couillotte]

Bonjour à tous,

Je rencontre souvent du code qui contient des déclarations du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 
#define maFonction do { \
... \
} while(uneCondition);

J'aimerais savoir en quoi est-ce plus avantageux que de déclarer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void maFonction() {
   do {
      ...
   } while(uneCondition);
}

Plus particulièrement,

1. Epargne-t-on vraiement des ressources, c'est à dire, est-ce que la fonction, une fois compilée, ne va pas être identique dans les deux cas, étant donné que "..." est le même code dans les deux cas?

2. Si oui, est-ce que le gain de vitesse ou de mémoire est-il important?

3. Est-ce que c'est considéré comme une bonne pratique?

En espérant qu'un guru me réponde assez vite,

Bonne journée
Couillotte

[Médinoc]

Pour des fonctions inline, elles sont en effet tous les avantages sur le #define, là où c'est applicable (il y a des choses que seul un #define peut faire, notamment tout ce qui implique les opérateurs # et ##).

Le problème majeur des fonctions inline en C, c'est qu'elles ne sont "officiellement" supportées que depuis le standard C99...

[oniric]

Hello,

je ne suis pas un fan de la pratique des macro fonctions. le principe des macros et macros fonctions c'est que code est remplacer directement dans ton block la ou se trouve l'appel de ta macro. Il n'y a donc pas d'appel de fonction (donc pas d'empilement memoire etc) donc gain de temps.

gros defaut, il n'y a aucun controle de typage etc à l'appel de ta macro fonction vu qu'il va remplacer directement dans ton block le code de ta macro, du coup parfois les messages d'erreur sont peu clair voir absent.

exemple plus clair :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#define MIN(x,y) ((x) > (y) ? (y) : (x))
#define MAX(x,y) ((x) < (y) ? (y) : (x))
 
int main(int argc, char **argv)
{
  int l = 0;
  for (int i = 0; i < argc; i++)
  {
    for (l = 0; argv[i][l] != '\0'; l++)
      printf("min=%d, max=%d\n", MIN(i,l), MAX(i,l));
  }
  return 0;
}

ici on peut voir sur ce code useless, qu'il va y avoir bcp d'appel à MIN MAX.
Si ca n'avait pas été des macro fonctions à chaque passage dans la 2eme boucle il y aurai bcp d'empilement/depilement de fonction (tu peux voir les empilements d'appel de fonction si tu le desir dans un debuggeur digne de ce nom, genre gdb):

1. empilement: appel à printf
2. empilement: appel à la fonction min ()
3. depilement : retour à printf
4. empilement : appel à max ()
5. depilement : retour à printf
6. depilement : retour au main

ce qui est evidement une perte de temps machine, donc baisse de performance.

par contre si on prend des macro fonctions comme données ci dessus, le code est traduit à la pré compilation et donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
int main(int argc, char **argv)
{
  int l = 0;
  for (int i = 0; i < argc; i++)
  {
    for (l = 0; argv[i][l] != '\0'; l++)
      printf("min=%d, max=%d\n", (i) > (l) ? (i) : (l), (i) < (l) ? (i) : (l));
  }
  return 0;
}

ce code n'est qu'ensuite evalué, et il possede bcp moins d'appel de fonction et sera donc plus performant.

je me repete ce genre de programmation est à utilisé dans des cas bien precis lorsqu'on sait ce que l'on veut faire et pourquoi on le fait, sinon c'est deconseillé.

[khaledbenamor]

L'avantage est donc simplifier le code source de programme.

[3DArchi]

L'avantage est donc simplifier le code source de programme.

Non, non. Ca complexifie le code source (car ça le rend plus difficilement lisible et debuggable), mais par contre c'est supposé optimiser le code généré.
Par contre, je ne sais pas si cette dernière assertion reste pertinente avec les compilateurs modernes, et notamment si ceux-ci ne font pas des optimisations 'inline' automatique pour du code C. Auquel cas, mieux vaut oublier ces indigestes macros.

[souviron34]

L'avantage est donc simplifier le code source de programme.

Non, non. Ca complexifie le code source (car ça le rend plus difficilement lisible et debuggable), mais par contre c'est supposé optimiser le code généré.
Par contre, je ne sais pas si cette dernière assertion reste pertinente avec les compilateurs modernes, et notamment si ceux-ci ne font pas des optimisations 'inline' automatique pour du code C. Auquel cas, mieux vaut oublier ces indigestes macros.

Totalement d'accord avec 3DArchi.

J'ai eu une fois à débugger et améliorer un très gros code basé sur ce type de truc, c'est à s'arracher les cheveux , que ce soit pour retracer l'endroit où c'est défini (dans un .h ? dans lequel ? dans le source ?), pour debugger, et quand en plus ça définit des appels de certaines fonctions avec des paramètres particuliers, c'est une horreur absolue

C'est souvent utilisé dans la bibliothèque standard, sauf que c'est pour le bien de tous (fonction simple).

C'est à déconseiller plus que fortement dans la programmation normale...

(à mon avis)

[koala01]

Salut,

Pour des fonctions inline, elles sont en effet tous les avantages sur le #define, là où c'est applicable (il y a des choses que seul un #define peut faire, notamment tout ce qui implique les opérateurs # et ##).

Le problème majeur des fonctions inline en C, c'est qu'elles ne sont "officiellement" supportées que depuis le standard C99...

A l'heure actuelle, reste-t-il encore énormément de compilo qui ne respecte pas le standard C99

Je peux comprendre que l'on ne modifie pas un (vieux) code existant pour "si peu", avec le travail que cela peut représenter...

Mais, dans un code "actuel", et avec un compilateur datant... d'après 1999 (en gros), l'idéal n'est-il pas de préférer les fonctions inlinées quand elle se justifie (AKA: quand un profiler nous indique que nous aurions effectivement un gain à le faire)

Pour le reste, je suis - moi aussi - tout à fait d'accord avec 3DArchi..

Il faut toujours se rappeler qu'un code est beaucoup plus souvent lu / débuggé qu'il n'est écrit...

Avec ce genre de definition, tu va avoir l'impression de faire quelque chose de plus efficace, car tu "aura moins de code à écrire".

Mais au final, tu va rapidement te rendre compte que ce code de rendra le débuggage très compliqué, si:

• ce n'est pas un code que tu as écrit toi même
• tu as écrit ce code depuis un temps suffisemment long pour... avoir eu l'occasion d'en oublier une partie

[matafan]

Comme indiqué dans la première réponse il y a quand même des choses qu'on ne peut faire qu'avec des macros. Manipuler les symboles qui sont passés à la macro par exemple.

[couillotte]

Merci à tous pour toutes ces précisions ... je récapitule:

1. On épargne en appels de fonctions, à condition que le compilateur n'optimise pas avec des "inline".

2. C'est utile lorsque la vitesse d'execution est un critère important.

3. Ce n'est pas forcément une bonne pratique car le code devient moins lisible (je préfère de loin une bonne vieille fonction dont on a tous l'habitude) et moins facile à débugger...

J'oublie quelquechose?

++
Couillotte

[3DArchi]

Merci à tous pour toutes ces précisions ... je récapitule:

1. On épargne en appels de fonctions, à condition que le compilateur n'optimise pas avec des "inline".

2. C'est utile lorsque la vitesse d'execution est un critère important.

3. Ce n'est pas forcément une bonne pratique car le code devient moins lisible (je préfère de loin une bonne vieille fonction dont on a tous l'habitude) et moins facile à débugger...

J'oublie quelquechose?

++
Couillotte

Je resterais prudent sur les aspects vitesse d'exécution. Aujourd'hui, entre les optimisations du compilo, puis les gestions de cache, intuitivement je dirais que dans 90% des cas, tu ne gagnes rien!