Discussion :

[Maitre_Kanter]

Bonjour tout le monde,

j'essaye de trouver une solution au problème de macro C ci-dessous.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
#define    INDEX_1   1
#define    INDEX_2   2
 
unsigned char   LBa_MonBuffer1[4] = {1,2,3,4};
unsigned char   LBa_MonBuffer2[4] = {4,3,2,1};
 
unsigned char LBa_output[4] = {0};
 
#define   MA_SUPER_MACRO( source, index, destination ) \
{ \
    memset(destination,0,sizeof(destination) ); \
    memcpy(destination,source ## index , sizeof(destination) ); \
}\
/** Ce qui suit est fonctionnel **/
MA_SUPER_MACRO( LBa_MonBuffer, 1, LBa_output ); /** Resultat : LBa_output= 1,2,3 et 4 **/
MA_SUPER_MACRO( LBa_MonBuffer, 2, LBa_output ); /** Resultat : LBa_output = 4,3,2 et 1 **/
 
/** Ce qui suit est NON fonctionnel **/
MA_SUPER_MACRO( LBa_MonBuffer, INDEX_1, LBa_output ); /** Resultat attendu : LBa_output= 1,2,3 et 4 **/

Quelqu'un pourrait me dire si ce que j'essaye de faire est possible ?

Je vous remercie tous !

Arnaud

[Matt_Houston]

Essaie en ajoutant un niveau d'indirection qui va forcer l'évaluation de la macro INDEX_1 avant concaténation :

Code :

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

1
2
3
4
#define MA_SUPER_MACRO_( source, index, destination ) \
        ...
 
#define MA_SUPER_MACRO( source, index, destination ) MA_SUPER_MACRO_( source, index, destination )

Soit dit en passant, à quoi bon memset un buffer que l'on va memcpy de toute manière ?

[picodev]

Bonjour,

ta macro ressemble trop à une fonction pour ne pas en faire … une fonction ! surtout que depuis les fonctions static inline les macros qui «font du code» perdent beaucoup de leur attrait.
De plus, comme tu présentes ça j'ai l'impression que tu vas tôt ou tard essayer de passer une variable comme paramètre index à ta macro → c'est voué à l'échec car le préprocesseur est une des premières phases de la compilation et n'existe plus au runtime.

Ça sent le problème XY. Il serait sans doute préférable de créer un tableau de buffers que tu accéderais par une variable plutôt que de t'embourber dans une macro. Je dis ça mais je ne connais pas le pourquoi de comment tu as aboutit à cette solution, ne connaissant pas non plus le problème de départ.

Si tu tiens absolument à faire une «macro code» la solution classique est :

Code :

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

1
2
3
#define FOO do { \
              ... \
            } while(0)

ou éventuellement d'utiliser une extension de ton compilateur, gcc propose par exemple :

Code :

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

1
2
3
#define FOO ({ \
              ...\
            })

[Maitre_Kanter]

Bonjour et merci picodev,

voici mes réponses:

[...]De plus, comme tu présentes ça j'ai l'impression que tu vas tôt ou tard essayer de passer une variable comme paramètre index à ta macro[...]

Non, je ne chercherai pas à passer une variable en paramètre INDEX...

[...]Je dis ça mais je ne connais pas le pourquoi de comment tu as aboutit à cette solution, ne connaissant pas non plus le problème de départ.[...]

C'est vrai que je n'ai pas exprimé mon problème à la base. Mon souci est purement d'ordre "culture générale": J'essaie de trouver une réponse à : "Est-ce que le compilateur est capable d'expandre un define avant l'expansion de MA_SUPER_MACRO ?"

[...]surtout que depuis les fonctions static inline les macros qui «font du code» perdent beaucoup de leur attrait.[...]

Tu m’intéresses quand tu parles de fonctions static inline. Je ne connais pas, je vais chercher.

Merci !

[Maitre_Kanter]

...
Soit dit en passant, à quoi bon memset un buffer que l'on va memcpy de toute manière ?

Bonjour et merci Matt_Houston,
cette macro n'est qu'un exemple, quelque chose que j'ai écris pour illustrer ma question.
Alors memset et memcpy peu importe...

[fearyourself]

Pouvons-nous commencer par demander l'utilité de la question? Les macros n'ont plus leur grande utilité à par pour rendre le code moins lisible, ajouter des sources d'erreurs, et penser que le programmeur sait plus sur comment optimisé le code qu'un compilateur bien réglé...

[Maitre_Kanter]

Bonjour,

[...]Les macros n'ont plus leur grande utilité à par pour rendre le code moins lisible, ajouter des sources d'erreurs[...]

Je ne cherche pas du tout à optimiser du code. Dire que les macros rendent le code moins lisible signifie peut être que le programmeur n'a pas trouvé un bon nom à sa macro.

Si je lis : MACRO_IS_BITn_RESET(BYTE,BITn), nous sommes tout à fait capable je pense de savoir ce qu'est censé faire la macro... non ?

C'est sûr que dans l'exemple pris pour illustrer ma question, ce n'est pas le cas je te l'accorde.

[...]et penser que le programmeur sait plus sur comment optimisé le code qu'un compilateur bien réglé.[...]

Je vais parler de ce que je connais: l'embarqué. Les compilateurs sont écris par des humains et de ce que je peux voir quelque fois dans les résultats de compilation, c'est qu'un compilateur n'est jamais parfait même réglé par le meilleur programmeur du monde. Rien ne vaut l'humain. Après tout dépend de ce que recherche le programmeur en embarqué que je suis , performance, taille de code et sécurité.

[fearyourself]

Je vais parler de ce que je connais: l'embarqué. Les compilateurs sont écris par des humains et de ce que je peux voir quelque fois dans les résultats de compilation, c'est qu'un compilateur n'est jamais parfait même réglé par le meilleur programmeur du monde. Rien ne vaut l'humain. Après tout dépend de ce que recherche le programmeur en embarqué que je suis , performance, taille de code et sécurité.

Tant qu'à faire on peut rester et programmer en assembleur ou binaire alors ;-)

Je pense que ce que je suis en train de dire est qu'il y a généralement 25k choses à faire avant de commencer à penser à mettre les choses sous forme de macros. Je pense aussi que j'ai eu trop de bugs liés à des soucis de macros et que j'ai passé trop de temps à comprendre comment la cascade de macros provoquait le code généré et pourquoi cela devenait du code entièrement faux...

Pour ce qui est du code embarqué: oui souvent on ramène à ça quand on parle contre les macros... Et oui, dans le cas embarqué, souvent les compilateurs sont moins matures que pour le cas non embarqué. Mais cela ne veut pas dire que les macros sont à être utilisés à tout bout de champs. Avant C99, il y avait quelques raisons pour utiliser des macros mais je dirai encore une fois: souvent les programmeurs tentent d'écrire du code rapide quand en fait écrire du code propre, testé, maintenable est nettement plus intéressant pour la boîte, les utilisateurs, les autres programmeurs.

On sort du sujet mais je pense que quand on voit des sujets sur des macros, il faut rappeler que leur utilisation est à prendre avec grande grande grande précaution

[Maitre_Kanter]

Essaie en ajoutant un niveau d'indirection qui va forcer l'évaluation de la macro INDEX_1 avant concaténation :

Code :

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

1
2
3
#define MA_SUPER_MACRO_( source, index, destination ) \
        ...
#define MA_SUPER_MACRO( source, index, destination ) MA_SUPER_MACRO_( source, index, destination )

Merci Matt_Houston, ça fonctionne !!!

Rapide et concis !

PS : surtout que tu n'a pas essayé de me dire que les macros c'est de la crotte...