CBSoft Le 06/05/2005 à 09:04Edité par CBSoft le 06/05/2005 à 11:33 Bonjour,
J'ai un petit problème pour utiliser une macro. Je vais l'expliquer avec un petit exemple : je déclare une structure quelconque, un tableau l'utilisant et un pointeur vers ce tableau :
typedef struct
{
const char *nom;
char age;
} PERSONNE;
PERSONNE gens[ 2 ]={
{"toto",10},
{"tata",20}
};
PERSONNE *p_gens=(PERSONNE*)&gens;
Pour accéder à une propriété du tableau en utilisant le pointeur, je peux par exemple écrire (*(p_gens+1)).nom (qui renvoie "tata"). Je voudrais maintenant utiliser une macro (nommons la "g") permettant d'écrire g(1).nom à la place du truc précédent. Comment faire ? Parce que ceci ne marche pas :
#define g(i) (*(p_gens+i));
Quand j'utilise cette macro, il y a une parse error. Quelqu'un a-t-il une idée ?
Enlève le ; à la fin de ta macro.
Mais ça me semble bizarre que le code que tu as écrit compile sans erreur, car l'expression &gens n'est pas du type PERSONNE *, donc l'affectation p_gens = &gens; devrait poser problème.
Sinon, pourquoi tu n'écris pas simplement gens[i].nom ?
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Pour cet exemple, TIGCC ne fait pas la différence quand il y a ou non un ;. Sinon pour le &gens, il y a effectivement un warning qui disparaît si je mets (PERSONNE*) devant. Mais le pb n'est pas là !
En fait le tableau "gens" (qui occupe beaucoup de place) n'est pas situé dans ma source mais dans un fichier séparé, si bien que je n'y ai accès que par l'intermédiaire d'un pointeur. Et j'aimerais pouvoir utiliser une macro afin de simplifier l'accès à ce tableau.
CBSoft -- qui crée le premier (?) jeu d'aventure "point & click" avec graphismes et scénario persos --
Le tableau est dans un fichier externe au programme ou bien dans un fichier source différent de celui où tu l'utilises ?
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Peut-être
#define DEREFSMALL(__p,__i) (*(typeof(&*(__p)))((unsigned char*)(__p)+(long)(short)((short)(__i)*sizeof(*(__p)))))
pour __p[__i], évidemment.
Lionel Debroux Le 06/05/2005 à 13:12Edité par Lionel Debroux le 06/05/2005 à 15:24 Tu peux garder DEREFSMALL, parce qu'elle est générique, et plus efficace que p[ i ] - c'est pour ça qu'elle a été faite.
> PS : mettre un &* n'est pas inutile ?
Non, c'est nécessaire dans le cas des tableaux dont la taille est donnée. J'ai eu le problème sur un sprite unsigned short[16].
[EDIT: enlevé le tag italique]
a rien, le (long) est inutile... (par contre le (short) est utile, puisque sizeof() renvoie un unsigned short, donc la multiplication renvoie un unsigned short)
« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)
Je sais qu'il y a un truc à propos de (long) vs. (unsigned long). Mes address hacks pour les ROM_CALLs donnent du meilleur code quand il y a (long) que (unsigned long).
si c'est le cas c'est un bug de tigcc...
« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)
Des façons de trouver les fonctions ou variables existant sous tous AMS, mais seulement définies dans la jump table sous une partie des versions d'AMS. Plus d'une dizaine de tels address hacks (il existe aussi des value hacks), dont un certain nombre de fonctions utiles de vat.h (que filelib réinvente différemment, d'ailleurs), pas tous faits par moi (voir push_internal_simplify dont le hack existe depuis longtemps).
La différence de taille totale entre AMS 1.xx et AMS 2.xx est suffisamment faible pour qu'on soit en droit d'être à peu près sûr que toutes les fonctions du CAS existent aussi sous AMS 2.03-. Ces address hacks sont inutiles parce qu'AMS 2.04+ les fournissent tous, avec les ROM_CALLs en F-Line (les fonctions du CAS étant par programmation et par nature lentes, il ne sert à rien de gagner 0% en passant en ROM_CALLs plus optimisés pour les appels).
J'ai survolé rapidement le topic.... je comprends pas ce qu'il veut faire de si particulier qui empèche de faire betement gens[i] ?
aze Le 30/05/2005 à 22:39 en quoi DEREFSMALL(p,i) est plus efficace que p[i] ?
p[i] n'est pas equivalent à *(p+i*sizeof(*p)), et donc à DEREFSMALL ?
Si, mais il semble que TIGCC ne génère pas un code aussi optimal que lorsqu'on lui mâche le boulot.
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
J'ai diminué la taille de la version de tthdex qui ne sortira probablement jamais d'une centaine d'octets en utilisant DEREFSMALL sous sa forme ASM inline avec opérandes C.
jfg> et si i est un signed short ?
Le tableau est dans une source compilée à part (et l'exécutable devient donc externe). Cela me permet de stocker le tableau séparément car ce dernier prend de la place. De plus je peux ainsi compiler le tableau sans devoir recompiler tout le projet qui utilise 'gens'.
