Librairie dynamique - Page 6

Ouep, mais comme je sais pas le faire on-pc, je vais faire un éditeur de map... simplissime, mais ça ira

extraits de mon code arrangés pour faire un exemple générique (je suppose que les données à dumper sont dans un tableau global qui s'appelle data) :

int main (int argc, char **argv) {
  int calctype = -1;
  char nomfic_onti[9] = "fichier";
  char nomfic_onpc[13];
  FILE *fichier_arrivee;
  unsigned char *out_buffer;
  unsigned int taille_resultat;

  if (argc >= 2) {
    if (!strcmp ("-89", argv[1])) calctype = 0;
    else if (!strcmp ("-92", argv[1])) calctype = 1;
  }
  if (calctype < 0) {
    printf ("Generate files for which calculator ? 0 : TI-89 -- 1 : TI-92+\n> ");
    while (!scanf ("%d", &calctype) || (calctype && calctype != 1))
      printf ("Please type 0 for TI-89 or 1 for TI-92+ ; Ctrl-C to cancel.\n> ");
  }

  out_buffer = DataBuffer2OTHBuffer (calctype, "dossier", nomfic_onti, "TRUC", sizeof(data), data, &taille_resultat);

  if (!taille_resultat) {
    fprintf (stderr, "Error processing data\n");
    return 1;
  }

  sprintf (nomfic_onpc, "%s%s", nomfic_onti, calctype ? ".9xy" : ".89y");
  fichier_arrivee = fopen (nomfic_onpc, "wb");
  if (!fichier_arrivee) {
      fprintf (stderr, "Error opening file %s\n", nomfic_onpc);
      free (out_buffer);
      return 1;
  }
  if (fwrite (out_buffer, taille_resultat, 1, fichier_arrivee) != 1) {
      fclose (fichier_arrivee);
      free (out_buffer);
      fprintf (stderr, "Error writing data\n")
      return 1;
  }
  free (out_buffer);
  fclose (fichier_arrivee);
  return 0;
}

les deux fopen à la suite c'est pour être sûr qu'il est bien ouvert ? ^^

Nan, ça ouvre en dual channel : c'est pour accélérer les transferts

C'est gentil comme tout, j'apprécie et je t'en remercie.

Mais j'aime pas repomper. Pour le moment, je m'en sort avec une lib dynamique : les données se situent aux exports, je les lis facilement. Mais j'ai fait ça pour faire vite, c'est pas définitif. Je vais voir si j'arrive à me démerder avec les tt*.

bob > la touche tab qui va sur envoyer, c'est particulièrement peu pratique quand tu essayes de remettre en forme du code copié-collé

Folco > bah c'est pas pour que tu repompes, mais pour que tu lises et comprennes (vraiment rien de sophistiqué dans ce code, l'essentiel de la place qu'il prend c'est pour teste les conditions d'erreur . C'est pour illustrer ce que je disais au ./149.)

En fait, je me dis deux choses, après avoir lu ton code :
- avec mes connaissances en C, toutes basiques qu'elles soient, je devrais en effet arriver à faire un moulinette
- avec mes connaissances en C, basiques, je pourrai certainement pas faire un éditeur on-pc

Et comme j'ai pas envie de me fader des maps à la main, avec les sprites à placer et les 5 ou 6 flags par tile, je vais faire ça on-calc

Merci quand même.

Question au niveau de la compilation :
Si j'utilise deux variables locales du même type dans une fonction, A et B
Si j'utilise A, puis B sans plus toucher à A, est-ce que le compilateur saura qu'en mémoire, il peut merger les deux, donc faire un stack frame plus petit que s'il allouait de l'espace pour chaque variable ?

Normalement oui

./159 > Ça dépend du niveau d’optimisation (par défaut non), mais normalement tu n’as pas besoin de te préoccuper de ces détails pour écrire ton code.

Je sais que je n'en ai pas besoin pour écrire. Mais je voulais savoir.

La curiosité est un vilain défaut (ou pas.)

Banane, pas dans ce domaine.

La sagesse populaire a toujours raison (ou pas.)

Bon, je commence à vouloir rentrer dans des trucs cons.
Idéalement, je voudrais faire un tableau de pointeurs de fonction, genre :
func = tableau[n];

Et ensuite, appeler tableau(n)(); à mon bon vouloir.

Mais on m'a glissé dans l'oreillette que ce n'était pas aussi simpliste que ça, un pointeur de fonction n'étant pas un simple void* etc...

Alors, comment m'y prendre ?

Si ta fonction est de type void* ma_fonction(void*), le plus simple est de définir un type :
typedef void*(*fonction_t)(void*);

pour exécuter la fonction, tu utiliseras

void toto(void* arg) {
 fonction_t f;
 void *result;
 f = tableau[0];
 result = (*f)(arg);

}

Parfait, merci !

Tiens, cadeau !

pourquoi une variable "f" intermédiaire ?

je me suis rendu compte que si les fonctions que tu veux appeler ont des args différents, faudra plein de casts partout

typedef int (*boo_t) (int a, char b);
typedef void (*yar_o) (void *a, int b);

( les noms)

int zeboo(int a, char b) { ......blabla }
void zeyar(void *a, int b) { ...... blublu }

void * tableau[2] = {
(void*)zeboo,
(void*)zeyar,
};

a l'utilisation
..... {
boo_t boo;
int blabla;
boo=(boo_t)tableau[0];
blabla = boo(3, (char)42);
}

..... {
yar_o yar;
yar = (yar_o)tableau[1];
yar(NULL,42);
}

ou sans variable intermédiaire comme cross-suggéré par Zephyr:

((yar_o)tableau[1])(NULL,42);

ça fait le code que tu veux ('fin, presque sûr)

Surtout pourquoi (*f)(arg) et pas f(arg)
(La variable c'est pour la clarté je pense)

le * est inutile, le compilo sait que tu peux pas faire 36 trucs avec un pointeur de fonction ^^
(edit: la honte X_X)

Zephyr (./169) :
pourquoi une variable "f" intermédiaire ?

bonne question (je pensais pas écrire la ligne f=tableau[0] au début )

tu pensais peut-être plus à tableau[0] ?

d'ailleurs pour confirmation, il n'existe pas de façon portable de réaliser un appel de fonction avec un nombre quelconque de paramètres de types quelconques non connus en temps de compilation ? (sachant que prévoir les 1092 prototypes possibles pour des fonctions de 1 à 6 arguments char/short/long n'est pas super élégant comme solution )

ben a pars la méthode de printf (ie utilise un parametre pour savoir) je vois pas trop, du moins en C

ben la méthode printf?

#include <stdarg.h>

sauf qu'il faut connaitre les types attendus, le C ne donne pas d'infos sur ce qu'il passe.

edit: cross

oui j'ai pas précisé, mais le but est d'appeler une fonction qui ne prévoit pas une convention d'appel particulière (pas de va_args par exemple), juste une fonction quelconque.

ça n'existe pas en C, ni aucun language 100% compilé que je connaisse (bon j'en connais pas 150000 non plus)

Si le code est interpreté, ou que c'est du passage de message etc... la il y a des languages qui le permettent

Si par "pas de convention d'appel particulière" tu entends genre cdecl, de base c'est mort. (T'es obligé de connaître la convention d'appel, le reste tu peux t'en démerder )
Après ça se fait très bien en assembleur [inline] mais c'est pas portable... Et ça tombe très bien car les conventions d'appel ne sont pas portables :]