Discussion :

[MrPchoun]

Bonjour,

Alors pendant le confinement on s'ennuie..
Pour un projet perso j'ai besoin de macros pour simplifier certaines fonctions.
Et comme ce n'est pas toujours très simple à composer, surtout quand elles s'appellent entre elles, j'ai eu l'idée de faire un mini traducteur C++ vers Macro. L'idée c'est de saisir le code C++ qu'on veut que la macro traduise, et le traducteur nous écrit la macro.
Pour l'instant je n'ai trouvé que des traducteurs Macro -> C++, enfin en bidouillant sur les flags du compilateur quoi.
Pour ceux que ça intéresse voici le lien de mon dernier petit bébé : http://coding.alwaysdata.net/MacroDeducer/
Ce n'est qu'une version alpha, qui ne prend pas encore compte les variadics, ni sans doute plein de tournures de code auxquelles je n'ai pas encore pensé. C'est quelque chose qui peut évoluer en fonction de vos remarques, si le besoin était réel. D'ailleurs, existe-t-il d'autres outils de ce genre online ? Je pense en tous cas pousser la fantaisie jusqu'à la traduction de certaines macros variadiques courantes, un peu pour la perf', et surtout pour le plaisir !

À l'écoute de vos remarques

[Bousk]

J'ai du mal à voir un quelconque intérêt.
Les macros sont dépliées pendant la phase du préprocesseur pour générer du code qui sera compilé.
Si je voulais générer du code, macro ou non, j'ajouterais un script Python pour le faire en Pre-Build event.

[MrPchoun]

Si je voulais générer du code, macro ou non, j'ajouterais un script Python pour le faire en Pre-Build event.

Intéressant.. Je vais aller fouiner de ce côté là, tiens.

J'ai du mal à voir un quelconque intérêt. Les macros sont dépliées pendant la phase du préprocesseur pour générer du code qui sera compilé

Hum.. Eh bien ce petit traducteur est totalement inutile pour des macros simples, puisqu'on peut facilement se représenter, à la fois la macro, et son code déplié (exemple MULTIPLICATION(a,b) a * b. Mais pour des traductions plus importantes, où je veux que la macro me déplie une classe entière avec ses membres et ses méthodes et fonction des arguments passés (oui je sais, c'est mal), l'exercice est un peu plus difficile à appréhender. L'idée c'est que j'input dans mon traducteur le résultat que je veux obtenir, et mon code C++ est automatiquement "replié".

Je rappelle l'objectif : une aide à la composition des macros. Que le code sera redéplié ensuite, je le sais bien

[foetus]

une aide à la composition des macros

Quelle est l'utilité ? Quelle est la difficulté ? À part échapper la fin de ligne

Que le code sera redéplié ensuite, je le sais bien

Quelle est l'utilité ? Pour moi, l'utilité d'1 macro c'est d'avoir "1 nom explicite sur 1 ligne" à la place d'1 bloc de code + ou - long (en plus évidemment du principe de la programmation procédurale)

Non le plus intéressant c'est d'avoir 1 parser qui permet d'extraire/ d'ajouter-de supprimer/ de mettre à jour toutes les macros (avec sûrement des commentaires pour marquer les blocs de code à transformer en macros)
parce qu'il est vrai que modifier des macros lorsqu’elles sont échappées et 1 rien "tassées", c'est 1 peu chiatique et il faut y aller piano.

[Bktero]

Et moi qui fait tout mon possible pour éviter les macros et les #define

Dans quels cas vous faites des macros plutôt que du code directement (dans les cas où le code est possible bien sûr) les gens ?

[foetus]

Dans quels cas vous faites des macros plutôt que du code directement (dans les cas où le code est possible bien sûr) les gens ?

regarde mon commentaire sur 1 autre fil de discussion qui explique "1 nom explicite sur 1 ligne" (et le code 2 messages au dessus) (<- et au passage de réduire fortement de longues fonctions même si la longueur se retrouve dans les macros).

Et 1 gros avantage des macros c'est qu'on peut isoler des morceaux de boucle et de tests (seulement le si ou le sinon) contrairement aux constexpr du C++11.
Le C est également très permissif en permettant 1 macro d’appeler 1 autre macro.

Évidement , à tout 1 chacun de prendre du recul et de juger si c'est bien ou pas/ dangereux ou pas/ faire attention aux effets non désirés.

[jo_link_noir]

je fais des macros pour tout ce qui est rébarbatif et qu'il n'y a pas de contournement simple:

- Définir X opérateurs avec une implémentation un peu complexe. C'est souvent la même chose au nom de l'opérateur près. Ou de la spécialisation de template lorsque que les identifiants utilisés changent. Le faire en recopiant le code ou avec des intermédiaires n'est pas toujours satisfaisant.
- Lorsqu'il y a besoin d'avoir les lignes / nom du fichier, mais que mettre explicitement __LINE__ ou __FILE__ n'a aucun intérêt. Donc plutôt des fonctions de log, assertion, trace. Le besoin sera réduit avec std::source_location (C++20), mais cela ne couvre pas le besoin d'avoir l'expression pour l'afficher (assert, macro de test unitaire).
- Tout ce qui est génération avec beaucoup de bruit ou de répétition. Par exemple, l'expression decltype(auto) foo(T x, U y) noexcept(noexcept(x + y)) { return x + y; } ou avoir un code avec des concepts C++20 ou une émulation avec le même code (voir le code de range-v3).
- Des choses qui se rapprochent de l’introspection.

Donc les macros me servent à écrire quelque chose de simple plutôt que me trimbaler 36 mille lignes de bruit inutile.

Perso, je ne vois pas l’intérêt d'un tel projet. Je commence toujours par écrire le code en C++ puis le transforme en macro à grand coup de rechercher/remplacer (c'est très rapide) et sinon c'est du code vraiment complexe avec des concaténations de macro et simili-boucles de partout, je ne vois pas comment un outil pourrais déduire la macro dont j'ai besoin.