Création de fonction farfelue

Bonjour à tous,

Désolé pour l'intitulé du sujet, je ne savais quoi écrire...


En gros je travaille sur un code déjà écrit que je dois modifier pour changer son application. Tout se passait très bien dans le meilleur des mondes jusqu'à ce que je tombe sur le bout de code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#define MAKE_FILTER(name, fun) \ static std::vector<float> make_ ## name (float sigma) { \   sigma = std::max(sigma, 0.01F); \   int len = (int)ceil(sigma * WIDTH) + 1; \   std::vector<float> mask(len); \   for (int i = 0; i < len; i++) { \   mask[i] = fun; \   } \   return mask; \ }   MAKE_FILTER(fgauss, exp(-0.5*square(i/sigma)));

---

(tiens c'est bizarre, sur visual c++ les deux premières lignes ne sortent pas en vert)

Je comprends l'idée générale, qui est, à partir d'une fonction mathématique définie, de créer un certain filtre. Ce qui me laisse perplexe, c'est la syntaxe, je n'ai jamais vu quelque chose comme ça 8O.

Dans l'application (algo de traitement d'image), il n'y a de toute façon besoin que d'un seul filtre, défini à partir d'une distribution gaussienne. Donc ma question est : pouvez-vous m'expliquer à quelles notions de langage c++ ce bout de code fait référence parce que pour moi c'est de l'inconnu ? Et est-ce que, comme dirait ma grand-mère, vous avez l'impression que ça revient pas un peu à tortiller du cul pour chier droit ?


Merci d'avance.

Bonsoir,

il s'agit simplement d'une macro.

Bonjour,

C'est quoi ce mélange C et C++ 8O

En C++, je pense qu'on préférerait plutôt faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

std::vector<float> maFonction( float t, std::function<float(int)> fct) { //.... mask[i] = fct(i); //.... }   std::vector<float> maPremiereFonction( float t) { return maFonction( t, [](int i){ return std::vector<float>(); } ); }

---

^Cela ne nécessite-t-il pas C++11?

Si puisque ça utilise des lambdas.
Btw, les macros ne sont pas interdites en C++, et les rejeter en bloc est stupide amha. :P

Citation:

---

Envoyé par Bousk

Si puisque ça utilise des lambdas.
Btw, les macros ne sont pas interdites en C++, et les rejeter en bloc est stupide amha. :P

---

En C++, on a beaucoup d'outils pour éviter les macro comme les templates ou de vrais constantes, par exemples. Et ce n'est pas non plus pour rien qu'on préfère éviter les macro.

Déjà les macro sur plusieurs lignes ne sont pas très lisibles (généralement la coloration syntaxique saute), de plus, il faut faire très attention aux priorités avec les macro vu qu'une macro n'est qu'un copié-collé de code, etc...

Après, je veux bien un exemple où utiliser une macro serait vraiment appropriée ( à part les #if #else #endif), mais utiliser les macro alors qu'on peut l'éviter est tout aussi stupide.

Des exemples j'en ai plein, parce que je trouve les macros très pratiques.

Au hasard, le dernier en date qui date d'hier: je travaille sur du scripting python dans l'appli et je veux pouvoir l'enrichir.

Code:

---

1 2 3 4 5

#define DECLARE_PY_MODULE(module_name) \ public: \ static PyMethodDef Methods[]; \ static PyModuleDef Module; \ static PyObject* PyInit() { return PyModule_Create(&module_name::Module); }

---

Pour pouvoir utiliser DECLARE_PY_MODULE(StaticModule) dans une class qui contient des méthodes static exporter au python.
Et

Code:

---

1 2	#define ADD_STATIC_MODULE(module_name) PyImport_AppendInittab(#module_name, &PyExtends::module_name::PyInit)

---

pour pouvoir ajouter l'initialisation de ce module à l'initialisation de Python via ADD_STATIC_MODULE(StaticModule);.

Egalement pour créer des fonctions "helper" pour transformer des types C en type Python

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

template<class DstType, class SrcType> static PyObject* SimpleValue(SrcType val); #define CONVERTER(DstType, SrcType, PyParam) \ template<> \ static PyObject* SimpleValue<DstType, SrcType>(SrcType val) { return Py_BuildValue(PyParam, val); }   //!< to Python integer CONVERTER(int, char, "b") CONVERTER(int, short, "h") CONVERTER(int, int, "i") CONVERTER(int, long, "l") etc

---

Parce que devoir retenir que pour retourner un int je dois faire Py_BuildValue("i", monInt); ou PyLong_FromLong(myInt); c'est quand même plus chiant que PythonManager::SimpleValue<int>(myInt);.

Autre exemple, quand je déclare une class comme étant un singleton, je dois déclarer cette class friend de mon interface Singleton, ce qui est fait via

Code:

---

1 2 3

class MySingleton : public Sdk::Singleton<MySingleton> { DECLARE_SINGLETON(MySingleton); };

---

Tu as des exemples beaucoup plus stupides et simples aussi.
Si j'ai besoin de déclarer une variable avec un prefixe particulier, pourquoi serait-il interdit de faire de cette manière ?

Code:

---

1 2 3 4 5

#define DECLARE_VAR2(var_type, var_name, prefix) var_type prefix##var_name #define DECLARE_VAR(var_type, var_name) DECLARE_VAR2(var_type, var_name, "mon_prefixe_de_ouf_")   DECLARE_VAR(int, bob); DECLARE_VAR(int, bobby) = 2;

---

Ou bien l'exemple de l'op qui veut déclarer une fonction. ;)

Citation:

---

Envoyé par Bousk

Des exemples j'en ai plein, parce que je trouve les macros très pratiques.

Au hasard, le dernier en date qui date d'hier: je travaille sur du scripting python dans l'appli et je veux pouvoir l'enrichir.

Code:

---

1 2 3 4 5

#define DECLARE_PY_MODULE(module_name) \ public: \ static PyMethodDef Methods[]; \ static PyModuleDef Module; \ static PyObject* PyInit() { return PyModule_Create(&module_name::Module); }

---

Pour pouvoir utiliser DECLARE_PY_MODULE(StaticModule) dans une class qui contient des méthodes static exporter au python.

---

Code:

---

1 2 3 4 5 6 7 8 9

template<typename T> class PyUtile { PyMethodDef Methods[]; PyModuleDef Module; PyObject* PyInit() { return PyModule_Create(&T::Module); } }   static PyUtile<ModuleName> py;

---

?

Citation:

---

Envoyé par Bousk

Et

Code:

---

1 2	#define ADD_STATIC_MODULE(module_name) PyImport_AppendInittab(#module_name, &PyExtends::module_name::PyInit)

---

pour pouvoir ajouter l'initialisation de ce module à l'initialisation de Python via ADD_STATIC_MODULE(StaticModule);.

---

Le problème, c'est que tu ne pourras pas charger d'autres modules que ceux que tu auras prévu à la compilation.

Code:

---

1 2 3 4

void ADD_STATIC_MODULE(const std::string & name ) { PyExtends::getModuleByName(name).load(); }

---

ou

Code:

---

1 2 3 4

void pyExtends::Module::load( void ) { PyImport_AppendInittab( getName(), &PyInit); }

---

Serait, je pense, plus pratique.

Citation:

---

Envoyé par Bousk

Egalement pour créer des fonctions "helper" pour transformer des types C en type Python

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

template<class DstType, class SrcType> static PyObject* SimpleValue(SrcType val); #define CONVERTER(DstType, SrcType, PyParam) \ template<> \ static PyObject* SimpleValue<DstType, SrcType>(SrcType val) { return Py_BuildValue(PyParam, val); }   //!< to Python integer CONVERTER(int, char, "b") CONVERTER(int, short, "h") CONVERTER(int, int, "i") CONVERTER(int, long, "l") etc

---

---

Le code de ta classe est quand même un peu moins lisible.
De plus tu pouvait très bien te contenter d'une seule template au lieu d'utiliser ta macro + une template.

Citation:

---

Envoyé par Bousk

Autre exemple, quand je déclare une class comme étant un singleton, je dois déclarer cette class friend de mon interface Singleton, ce qui est fait via

Code:

---

1 2 3

class MySingleton : public Sdk::Singleton<MySingleton> { DECLARE_SINGLETON(MySingleton); };

---

---

Singletonite ? :aie:
Je ne connais pas ton code dans sa globalité, mais je pense qu'il y a une erreur de conception. Je doute très fortement que les friends soient bien appropriés. Sinon pourquoi directement mettre friend class MySingleton serait plus compliqué ? :koi:

Citation:

---

Envoyé par Bousk

Tu as des exemples beaucoup plus stupides et simples aussi.
Si j'ai besoin de déclarer une variable avec un prefixe particulier, pourquoi serait-il interdit de faire de cette manière ?

Code:

---

1 2 3 4 5

#define DECLARE_VAR2(var_type, var_name, prefix) var_type prefix##var_name #define DECLARE_VAR(var_type, var_name) DECLARE_VAR2(var_type, var_name, "mon_prefixe_de_ouf_")   DECLARE_VAR(int, bob); DECLARE_VAR(int, bobby) = 2;

---

---

Quelle utilité :koi:
On a aussi des namespaces qui peuvent permettre "d'ajouter des préfixes".

Citation:

---

Envoyé par Bousk

Ou bien l'exemple de l'op qui veut déclarer une fonction. ;)

---

Si on ne veut pas utiliser le C++11, on peut très bien utiliser des templates qui seront bien plus pratique.

Salut,

Citation:

---

Envoyé par Neckara

Après, je veux bien un exemple où utiliser une macro serait vraiment appropriée ( à part les #if #else #endif), mais utiliser les macro alors qu'on peut l'éviter est tout aussi stupide.

---

En fait, je crois que tout dépend encore une fois du contexte d'une part et du nom que l'on donne à la macro d'autre part.

Il est parfois utile de pouvoir concaténer certains symboles qui ne sont pas forcément de vraies chaines de caractères mais qui doivent être considérés comme des symboles à part entière par le compilateur.

Tout comme il est parfois simplement utile de pouvoir simplifier une exception en permettant de rajouter des informations de manière automatique.

L'exemple le plus simple dans lequel une macro peut s'avérer intéressante (et sans équivalent en C++) serait une "simple" fonction log, qui, pour assurer son comportement nécessite d'avoir le nom du fichier et la ligne à laquelle le log est effectué:

Code:

---

1 2 3 4

void log(std::string const & message, std::string const &filename, int line){ /*out représente "n'importe quel" flux de sortie formaté ;) */ out<<filename<<" at line :"<<line <<" "<<message<<std::endl; }

---

Tu pourrais, bien sur, t'ammuser à invoquer directement cette fonction dans ton code, sous la forme de

Code:

---

1 2 3

void foo(){ log("le message hyper important", __FILE__,__LINE__); }

---

car cela fonctionnerait sans problème.

Mais il faut avouer que tu peux vraiment te faciliter la vie avec la macro "qui va bien":

Code:

---

#define LOG( a) log(a, __FILE__, __LINE__)

---

qui peut etre utilisée sous la forme de

Code:

---

1 2 3

void bar(){ LOG("un autre message hyper important"); }

---

sans avoir à t'inquiéter de transmettre, effectivement, __FILE__ et __LINE__ à la fonction.


On peut bien sur ne considérer cela que comme un "sucre syntaxique", mais il faut avouer que cela apporte malgré tout un certain confort tant à l'écriture qu'à la lecture (car on ne perd pas d'information essentielle sans avoir à s'inquiéter de certaines informations que le compilateur est parfaitement en mesure de fournir par lui -même ;) )
Un autre cas est celui où il faut pouvoir redéfinir "quelque chose" (par exemple new et delete) si l'on a défini un symbole particulier:

Code:

---

1 2 3

#ifdef __DEBUG__ #define new ns::new(__FILE__, __LINE__) /* avec les définitions de new et new[] qui vont bien ;) */ #endif

---

Ce n'est même plus du "sucre syntaxique" ici, car c'est vraiment la solution la plus facile qu'il te soit donnée pour faire en sorte de redéfinir new (dans le cas présent) partout, l'alternative étant de parsemer littéralement ton code d'un #ifdef __DEBUG__ #else #endif à chaque utilisation de new :aie:

Enfin, il y a tous ces cas où la macro permet d'éviter de nombreuses duplications de code dans lesquelles seules quelques informations sont susceptible de changer, mais qui serait très nombreuses du seul fait du nombre d'éléments qui nécessiteraient ces duplications de code.

Prenons, par exemple, un ensemble de propriétés, certaines pouvant être constantes (seulement un get_propertyName() ), d'autres pouvant être modifiées ( présentant un coupe d'accesseur et de mutateurs : get_propertyName() et set_propertyName())

Si toutes ces propriétés doivent être représentées par un code sensiblement similaire, ce sera sans doute sous la forme de

Code:

---

1 2 3 4 5 6

public: UnType /* const &*/ get_lapropriete() const{return propriete_;} void set_lapropriete(UnType /* const &*/ newval){ prorpiete_ = newval;} private: UnType propriete_;

---

Avec, comme seul point de variation le nom devant remplacer "propriete" et le type et le type qui lui est associé.

Il sera, simplement, beaucoup plus facile d'écrire une classe présentant de nombreuses propriétés sous la forme de

Code:

---

1 2 3 4 5 6 7 8 9 10

class MaClass{ DECLARE_GET_SET_PROPERTY(tailleVerticale, int); DECLARE_GET_SET_PROPERTY(tailleHorizontale, int); DECLARE_GET_SET_PROPERTY(tailleVerticaleMinimale, int); DECLARE_GET_SET_PROPERTY(tailleVerticaleHorizontale, int); DECLARE_GET_SET_PROPERTY(tailleHorizontaleMinimale, int); DECLARE_GET_SET_PROPERTY(tailleHorizontaleMaximale, int); DECLARE_GET_PROPERTY(uneProprieteReadOnly, std::string);   };

---

(avec les macros qui vont bien pour y arriver ;)) que de devoir se "palucher" l'écriture de tout ce que la macro doit remplacer à chaque fois.

Le code même de ta classe n'est certainement pas moins lisible que ce qu'il aurait du être (on voit très rapidement quelles sont les propriétés déclarées ;)) mais tu as écrit en une ligne l'équivalent d'un code qui t'en aurait pris quatre sans l'aide de la macro, avec tout le risque d'erreur que peut représenter le simple fait d'avoir à se répéter (une majuscule, une lettre ou un underscore oublié quelque part est si vite arrivé ;)).

Alors, oui, je suis d'accord, une macro n'est jamais qu'un "sucre syntaxique" que l'on se définit.

Mais si la macro permet de se faciliter la vie en gardant un code succin sans perdre d'information importante tout en gardant des termes explicites, je crois, sincèrement, que cela vaut la peine d'y recourir.

Je tiens cependant à préciser que, comme toute chose, le recours aux macros n'est qu'une solution parmi tant d'autres dont l'usage devrait rester limité aux cas ils représentent la "moins mauvaise" des solutions envisager (à défaut d'être clairment la meilleure ;)).

A priori, je serais aussi du genre à en limiter l'usage au maximum, mais, dans certains cas particuliers, il s'avère qu'il peuvent représenter une solution viable ;).

Bonjour et merci de vos réponses.

En effet je n'avais jamais utilisé de macros auparavant et je ne compte pas m'y mettre... Mais l'avantage ici il faut le dire c'est que cela permet de créer directement une nouvelle fonction avec un nom spécifique. Ici make_fgauss(sigma) est directement utilisé dans la suite du code.

Avec les fonctions template, on peut définir une fonction pour plusieurs types de variable différents, mais peut-on faire comme ici, c'est à dire mettre en entrée un nom et une fonction et récupérer en sortie une autre fonction ?

Il me semble que c'est ce que Neckara me propose avec son code, mais j'ai du mal à comprendre ce que fait et retourne maPremiereFonction ?

En fait, c'est tout simple:

La macro va déclarer une fonction statique make_fgauss (selon ton expemple) qui va prendre un argument sigma (de type float ) en argument et qui remplira un tableau de float composé soit de sigma* WIDTH éléments +1, soit de 0.01 * WIDTH éléments +1 (en fonction de la valeur de sigma) dont les valeurs seront, pour chaque élément, le résultat de la fonction exp prenant en argument -0.5 *(index de l'élément/ sigma) au carré.

C'est à dire que, avec un sigma de 0.1 (par exemple), et une taille "finale" de 10, les valeurs seront égales au résultat de

1. exp(-0.5 * 0 (==0)); pour le premier élément (0/0.1 = 0, 0*0 = 0)
2. exp(-0.5 * 100 (==-50)) pour le deuxième (1/0.1 = 10, 10*10=100 )
3. exp(-0.5 * 400 (==-200)) pour le troisième (2/0.1 = 20, 20*20= 400 )
4. exp(-0.5 * 900 (==-450)) pour le quatrième (3/0.1 = 30, 30*30= 900 )
5. exp(-0.5 * 1600 (==-800)) pour le cinquième (4/0.1 = 40, 40*40= 1600 )
6. exp(-0.5 * 2500 (==-1250)) pour le sixième(5/0.1 = 50, 50*50= 2500 )
7. exp(-0.5 * 3600 (==-1800)) pour le septième (6/0.1 = 60, 60*60= 3600 )
8. exp(-0.5 * 4800 (==-2400)) pour le huitième (7/0.1 = 70, 70*70= 4800 )
9. exp(-0.5 * 6400 (==-3200)) pour le neuvième(8/0.1 = 80, 80*80= 6400 )
10. exp(-0.5 * 8100 (==-4050)) pour le dixième (9/0.1 = 90, 90*90= 8100 )

Puis, cette fonction (fsigma) renverra le tableau en question, qui, de toutes évidences, devrait correspondre à un mask de gauss.

En fait, il faut comprendre que les macro ne font que remplacer du texte par autre chose, qui sera analysé "as it" par le compilateur ;)

Une fois que tu as repéré le symbole défini (ici MAKE_FILTER(name, fun) ) il "suffit" de remplacer, chaque symbole (équivalent à name et à fun) dans le code par lequel le symbole sera remplacé.

Dans le cas présent, ca donne

Code:

---

1 2 3 4 5 6 7 8 9

static std::vector<float> make_fsigma (float sigma) { //remplacement de name par fsigma sigma = std::max(sigma, 0.01F); int len = (int)ceil(sigma * WIDTH) + 1; std::vector<float> mask(len); for (int i = 0; i < len; i++) { mask[i] = exp(-0.5*square(i/sigma)); // remplacement de "fun" par exp(-0.5*square(i/sigma)) } return mask; }

---

J'avais bien compris le but final du bout de code, qui est simplement de me retourner un masque (je travaille sur un algo de traitement d'image).

Ce qui me laissait plus perplexe c'était la syntaxe (et donc comment le compilateur l'interprète) et l'intérêt de recourir à une macro dans cette application.


Mais ça va mieux maintenant, je vais pouvoir modifier ça tranquillement.


Merci pour vos éclaircissements !