:x
Les macros c'est bien, mais ça devient excessif là, non?
Pen^2 (./31) :Oui ! Ca reste très simple à débugger
C'est de l'art
(Ça doit être facile à débuguer)
Folco (./32) :Je sais, mais le python n'est pas assez performant !
J'imagine que ça dépend du niveau qu'on a dans le langage. Mais peut-être que si j'avais besoin d'autant de macros dans un langage donné, j'irais voir vers un langage de plus haut niveau pour lequel ces choses sont basiques.
Zeph (./34) :PpHd, lâche ce volant tout de suite
Mouais, faudrait me rouler dessus pour qu'un code pareil passe ailleurs que dans un projet strictement perso ^^
Zeph (./34) :Oué, les INIT, CLEAR et compagnie sont quand même moches ! M'enfin certains codes que je vois en production sont largement plus sales!
Mouais, faudrait me rouler dessus pour qu'un code pareil passe ailleurs que dans un projet strictement perso ^^
Warpten (./35) :Elles définissent aussi toutes les fonctions permettant d'utiliser ces structures.
En fait, je ne vois pas en quoi ces macros te font gagner du temps par rapport à des typedefs directs :/
Kevin Kofler (./36) :Cite-moi une seule personne qui maitrise le C++ ?
Et pourquoi pas du C++ tout simplement? Même le projet GNU permet le C++ pour ses projets de nos jours.
Kevin Kofler (./41) :
il est une très mauvaise idée de retourner une référence à une variable locale dans une fonction).
Merci Captain Obvious !Et franchement, PpHd, le C++ est plus maîtrisable que le bordel de macros C que tu proposes.
Le C++ maitrisable !Pen^2 (./42) :Oué. Lorsque tu reprends un projet en C++, le mainteneur précédent n'a jamais utilisé la même sous-partie du langage C++ que celle que tu maitrises. Ah le paria !
C'est bien de maîtriser ce que tu utilises, mais si tu ne travailles pas seul... Ou que tu reprends des projets...
... Folco (./48) :Tût tût tût. Tu oublies que le 68000 supporte le multiprocesseurs
Voilà. Alors qu'avec un bon vieux 68000, ça ne serait jamais arrivé !
)
#include "m-tuple.h"
#include "m-list.h"
#include "m-array.h"
// Définition d'une paire (string, mpz_t) et ses fonctions utilitaires
TUPLE_DEF(pair, (key, string_t, STRING_OPLIST), (value, mpz_t, CLASSIC_OPLIST(mpz)))
#define PAIR_OPLIST TUPLE_OPLIST(STRING_OPLIST, CLASSIC_OPLIST(mpz))
// Définition d'une liste de paire et ses fonctions utilitaires
LIST_DEF(pair, pair_t, PAIR_OPLIST)
// Définition d'un tableau de liste de paire et ses fonctions utilitaires
ARRAY_DEF(list_pair, list_pair_t, LIST_OPLIST(PAIR_OPLIST))
int f(const array_list_pair_t org)
{
array_list_pair_t x;
array_list_pair_init_set(x, org);
int n = array_list_pair_size(x);
array_list_pair_clear(x);
return n;
}
int f2(const array_list_pair_t org)
{
array_list_pair_it_t it;
int n = 0;
for(array_list_pair_begin(it, org); !array_list_pair_end_p(it); array_list_pair_next(it))
{
n += list_pair_size(*array_list_pair_cref(it));
}
return n;
}
/* Map a macro to all given arguments and reduce all theses computation with another reduce macro */
/* Example: REDUCE(f, g, a, b, c) ==> g( f(a), g( f(b), f(c)) */
#define REDUCE_L0_INDIRECT() REDUCE_L0
#define REDUCE_L1(f, g, cur, a, ...) DELAY3(REDUCE_L0_INDIRECT) () (f, g, g(cur, f(a)), __VA_ARGS__)
#define REDUCE_L0(f, g, cur, ...) IF_NARGS_EQ1(__VA_ARGS__)( g(cur, f(__VA_ARGS__)) , REDUCE_L1(f, g, cur, __VA_ARGS__))
#define REDUCE1(f, g, a, ...) EVAL(REDUCE_L0(f, g, f(a), __VA_ARGS__))
#define REDUCE(f, g, ...) IF_NARGS_EQ1(__VA_ARGS__)( f(__VA_ARGS__), REDUCE1(f, g, __VA_ARGS__))
REDUCE(BOOL, AND, 0, 1, 2, 3, 4)
REDUCE(BOOL, AND, 1, 2, 3, 4)
cc -E ==>
0
1
REDUCE(ID, ADD, 0, 1, 2, 3, 4)
cc -E ==>
EVAL(INC_INC_INC_INC_EVAL(ADD_L0 (INC_INC_INC_EVAL(3), 0)))
Ça peut être réglé en ajustant les délais d'évaluations (REDUCE(ID, DELAY256(ADD), 0, 1, 2, 3, 4)), mais dans ce cas, le préprocesseur C devient lent.