Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » Programmation C » Méthode de gestion des mallocs (32 réponse(s))
./POST DE DEPART (post n°0)   Marquer comme non lu.
LionelA Ecrit le: Samedi 5 mars 2005 à 15:07 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Voilà donc pour ceux qui ont plein de malloc dans leurs programmes et qui ont eu la flemme de les tester et après de faire une gestion des erreurs pour liberer toute la mémoire, un .c et un .h qui permettent de s'en sortir :)

le fichier mem.h :

// Header File
// Created 02/01/2005; 20:11:47
#ifndef MEM_H
#define MEM_H

// Memory Management
#define DEV_PHASE 0 // 0: not in development phase, 1: get message if there is not enough *_MAX_*
#define INTERRUPT_MAX_HANDLERS 5
#define MEMORY_MAX_HANDLES 32
#define MEMORY_MSG "Mon message pour dire qu'il y a  pas assez de ram"

#include <tigcclib.h>

__attribute__((noreturn)) void Exit (void);
void *Malloc (unsigned long Size);
void *Calloc (unsigned short NoOfItems, unsigned short SizeOfItems);
void Free (void *Ptr);

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler); 
void ReSetIntVector(long IntVec);

#endif




et le fichier mem.c (attention : code illisible)

// C Source File
// Created 02/01/2005; 23:14:39

#include "mem.h"

#if DEV_PHASE == 1
unsigned char overptr = 0;
unsigned char overint = 0;
#endif

INT_HANDLER hdlrs[INTERRUPT_MAX_HANDLERS*2];
void *ptrs[MEMORY_MAX_HANDLES];
unsigned short nbptr = 0;
unsigned short nbhdlr = 0;

__attribute__((noreturn)) void Exit (void) {
  void ** ptr = ptrs + nbptr;
  for(; (ptr--) != ptrs; free(*ptr));
  GrayOff (); // Does nothing if not On
  INT_HANDLER* hdlr = hdlrs + 2*nbhdlr;
  for(; hdlr != hdlrs; hdlr-=2 ,SetIntVec ((long)(*hdlr), *(hdlr+1)));
  clrscr ();
#if DEV_PHASE == 1
  if(overptr) {
    DlgMessage("DEVELOPMENT","Not enough MEMORY_MAX_HANDLES",BT_OK,BT_NONE);
    overptr = 0;
  }
  else if(overint) {
    DlgMessage("DEVELOPMENT","Not enough INTERRUPT_MAX_HANDLERS",BT_OK,BT_NONE);
    overint = 0;
  }
  else
#endif
  DlgMessage("MEMORY",MEMORY_MSG,BT_OK,BT_NONE);
  nbptr=0;
  nbhdlr = 0;
  exit (0);  
}

void *Malloc (unsigned long Size) {
#if DEV_PHASE == 1
  if(nbptr == MEMORY_MAX_HANDLES) overptr = 1, Exit ();
#endif
  void ** ptr = ptrs + (nbptr++);
  if ((*ptr = malloc(Size)))
    return *ptr;
  nbptr--;
  Exit ();
}

void *Calloc (unsigned short NoOfItems, unsigned short SizeOfItems) {
#if DEV_PHASE == 1
  if(nbptr == MEMORY_MAX_HANDLES) overptr = 1, Exit ();
#endif
  void ** ptr = ptrs + (nbptr++);
  if ((*ptr = calloc(NoOfItems, SizeOfItems)))
    return *ptr;
  nbptr--;
  Exit ();
}

void Free (void *Ptr) {
  void ** ptr = ptrs + nbptr - 1;
  unsigned char i = 0;  
  for(; *ptr != Ptr; ptr--, i++);
  free(Ptr);
  memmove (ptr, ptr+1, i * sizeof(void *));
  nbptr--;
}

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler) {
#if DEV_PHASE == 1
  if(nbhdlr == INTERRUPT_MAX_HANDLERS) overint = 1, Exit ();
#endif
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr++);
  *(hdlr++) = (INT_HANDLER)IntVec;
  *hdlr = GetIntVec (IntVec);
  SetIntVec (IntVec, Handler);
  return (*hdlr);
}

void ReSetIntVector(long IntVec) {
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr - 1);
  unsigned char i = 0;  
  for(; (long)(*hdlr) != IntVec; hdlr-=2, i++);
  SetIntVec (IntVec, *(hdlr+1));
  memmove (hdlr, hdlr+2, i * sizeof(INT_HANDLER)*2);
  nbhdlr--;
}


Ce code gère l'allocation par des fonctions Malloc ou Calloc (vous devez remplacer vos malloc et calloc avec)
la liberation par la fonction Free (idem)
lors d'une erreur d'allocation le programme quitte et restaure toute la ram allouée avec ces fonctions et restaure les handlers d'interruption détournés (Il faut utiliser les fonctions fournies aussi)
Par contre vous aurez quand même des pertes mémoire si vous utilisez des fonctions comme fopen qui font leur propre allocation (donc il faut utiliser les fonction de la vat pour les fichiers ou bien rajouter une gestion des fichiers ouverts à ce module)

Voilà voilà :)

Je précise (avant de me faire engueuler) que cette méthode n'est à utiliser qu'en cas de flemme intense, sinon il faut pas faire comme ca (paraît-il :p)

-Edité le Samedi 5 mars 2005 à 15:11 par LionelA-
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°1   Marquer comme non lu.
Jfg Ecrit le: Samedi 5 mars 2005 à 15:41 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


Quand on connais dès le début le montant de la mémoire à allouer, il vaut mieux faire une grosse allocation (et donc un seul free) et distribué la mémoire a des pointeurs différents que plusieurs petite allocations. C'est tout aussi rapide que d'utiliser le .c et .h à LionelA.
Si par contre on fait des allocations un peu partout dans le programme, le code de LionelA est utile.
Kill Mario
    
./Post n°2   Marquer comme non lu.
Kevin Kofler Ecrit le: Samedi 5 mars 2005 à 16:09 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Puisqu'on en est aux systèmes de gestion de mémoire, voilà une méthode beaucoup plus propre:

1. Identifier les fonctions allocatrices. Ce sont toutes les fonctions de ce style:
void *foo(...)
{
  void *ret;
  ...
  ret = malloc(...);
  ...
  return ret;
}

c'est-à-dire les fonctions qui se comportent essentiellement comme malloc. Toutes les autres fonctions sont des fonctions non-allocatrices. En particulier, une fonction non-allocatrice est responsable de libérer tout ce qu'elle a alloué avant de retourner. Si une fonction allocatrice alloue plus que ret seulement, elle est responsable de libérer tout ce qu'elle a alloué à part ret (et à part possiblement des sous-structures de ret qui peuvent être libérées en connaissant ret - je fais une description simplifiée ici).

2. Utiliser les exceptions. On remplace partout malloc par malloc_throw. Notre fonction allocatrice ressemble donc maintenant à:
void *foo(...)
{
  void *ret;
  ...
  ret = malloc_throw(...);
  ...
  return ret;
}

et se comporte donc comme malloc_throw. Comme il n'y a plus de différences entre une fonction allocatrice et malloc_throw pour ce qui suit, je noterai alloc_throw pour toute fonction allocatrice ou malloc_throw. La fonction exacte a peu d'importance par la suite.

3. En cas d'exception provoquée par une fonction d'allocation, tout ce qui a précédemment été alloué dans la même fonction doit être libéré. Les blocs TRY...FINALLY...ENDFINAL sont idéaux pour ça. Une fonction non-allocatrice ressemblera donc à:
void bar(void)
{
  void *p1=alloc_throw(...);
  TRY
    void *p2=alloc_throw(...);
    TRY
      void *p3=alloc_throw(...);
      TRY
        ...
      FINALLY
        free(p3);
      ENDFINAL
    FINALLY
      free(p2);
    ENDFINAL
  FINALLY
    free(p1);
  ENDFINAL
}

Attention à utiliser la bonne fonction free pour la fonction d'allocation utilisée, par exemple: malloc_throw -> free, HeapAllocThrow -> HeapFree, GrayOnThrow -> GrayOff. Attention aussi à utiliser toujours la variante "throw" des fonctions d'allocation de TIGCCLIB.

4. Activer l'option ENABLE_ERROR_RETURN ("Allow returning errors to AMS" dans les Program Options), pour que l'erreur "Memory" soit passée à AMS.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°3   Marquer comme non lu.
LionelA Ecrit le: Samedi 5 mars 2005 à 17:32 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Ok mais comment faire dans le cas où tu as des fonctions du genre :

char * ptr1;
char * ptr2;

void init(void) {
...
ptr1 = (char*)malloc(...);
ptr2 = (char*)malloc(...);
...
}

void end(void) {
free(ptr1);
free(ptr2);
}

(j'ai à peu près que de ça dans Mode7Engine, tu comprend pourquoi j'ai pas voulu tout recoder :))
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°4   Marquer comme non lu.
Jfg Ecrit le: Samedi 5 mars 2005 à 17:39 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


Tu free toute la mémoire en même tps ?
Kill Mario
    
./Post n°5   Marquer comme non lu.
LionelA Ecrit le: Samedi 5 mars 2005 à 17:43 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


je ne suis pas sur de capter la question :p

Si c'est une suggestion, ben je peux pas tout allouer dans un init et tout freer à la fin car les calculs intermediaires pour placer les waypoints sur la map prennent à fond de mémoire mais temporairement, puisque je libere tout une fois calculé.
Si c'est vraiment une question, la premiere réponse y répond aussi :)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°6   Marquer comme non lu.
Sasume Ecrit le: Samedi 5 mars 2005 à 18:44 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Kevin> Ça donne quoi en ASM ton code ?
    
./Post n°7   Marquer comme non lu.
Kevin Kofler Ecrit le: Samedi 5 mars 2005 à 23:00 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


LionelA :
Ok mais comment faire dans le cas où tu as des fonctions du genre :

char * ptr1;
char * ptr2;

void init(void) {
...
ptr1 = (char*)malloc(...);
ptr2 = (char*)malloc(...);
...
}

void end(void) {
free(ptr1);
free(ptr2);
}

init est ta fonction d'allocation, end est ta fonction de libération. La seule chose à laquelle faire attention est la sémantique "tout ou rien" d'une fonction d'allocation: soit tout est alloué correctement, soit une exception est jetée et rien n'est alloué. Cela donne:
void init(void) {
  ...
  ptr1 = (char*)malloc_throw(...);
  TRY
    ptr2 = (char*)malloc_throw(...);
    ...
  FINALLY
    free(ptr1);
  ENDFINAL
}

void end(void) {
  free(ptr1);
  free(ptr2);
}

void caller(void) {
  init();
  TRY
    ...
  FINALLY
    end();
  ENDFINAL
}

Et il est également à envisager de regrouper tes 2 allocations en une seule allocation, ce qui donnerait une allocation atomique et te permettrait donc de te passer du TRY...FINALLY...ENDFINAL dans init.

Cela dit, une chose qui n'est pas prévue dans cette architecture générale est l'utilisation de realloc. Pour ça, il faut réfléchir au cas par cas au comportement correct en termes de handlers d'exceptions.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°8   Marquer comme non lu.
Kevin Kofler Ecrit le: Samedi 5 mars 2005 à 23:13 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Sasume :
Kevin> Ça donne quoi en ASM ton code ?

void bar(void)
{
  void *p1=malloc_throw(100);
  TRY
    void *p2=malloc_throw(200);
    TRY
      void *p3=malloc_throw(300);
      TRY
        ngetchx();
      FINALLY
        free(p3);
      ENDFINAL
    FINALLY
      free(p2);
    ENDFINAL
  FINALLY
    free(p1);
  ENDFINAL
}

donne:
bar:
  link.w %fp,#-180
  movm.l #0x1f20,-(%sp)
  lea malloc_throw,%a2
  move.w #100,%a0
  jbsr (%a2)
  move.l %a0,%d7
  pea -180(%fp)
  move.l 1360(%a5),%a0
  jbsr (%a0)
  move.w %d0,%d5
  addq.l #4,%sp
  jbne .L2
  move.w #200,%a0
  jbsr (%a2)
  move.l %a0,%d6
  pea -60(%fp)
  move.l 1360(%a5),%a0
  jbsr (%a0)
  move.w %d0,%d4
  addq.l #4,%sp
  jbne .L4
  move.w #300,%a0
  jbsr (%a2)
  move.l %a0,%a2
  pea -120(%fp)
  move.l 1360(%a5),%a0
  jbsr (%a0)
  move.w %d0,%d3
  addq.l #4,%sp
  jbne .L6
#APP
  .xdef __ref_all___set_file_in_use_bit
#NO_APP
  move.l 324(%a5),%a0
  jbsr (%a0)
  move.l 1364(%a5),%a0
  jbsr (%a0)
.L6:
  move.l %a2,-(%sp)
  move.l 652(%a5),%a0
  jbsr (%a0)
  addq.l #4,%sp
  tst.w %d3
  jbeq .L8
  move.w %d3,-(%sp)
  jbra .L15
.L8:
  move.l 1364(%a5),%a0
  jbsr (%a0)
.L4:
  move.l %d6,-(%sp)
  move.l 652(%a5),%a0
  jbsr (%a0)
  addq.l #4,%sp
  tst.w %d4
  jbeq .L10
  move.w %d4,-(%sp)
.L15:
  move.l 1356(%a5),%a0
  jbsr (%a0)
.L10:
  move.l 1364(%a5),%a0
  jbsr (%a0)
.L2:
  move.l %d7,-(%sp)
  move.l 652(%a5),%a0
  jbsr (%a0)
  addq.l #4,%sp
  tst.w %d5
  jbeq .L14
  move.w %d5,-(%sp)
  jbra .L15
.L14:
  movm.l -204(%fp),#0x4f8
  unlk %fp
  rts
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°9   Marquer comme non lu.
LionelA Ecrit le: Jeudi 14 juillet 2005 à 04:02 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Voilà une mise à jour de mon système anti leak (ca en interessera certains (je pense a FpgForce :))) :
mem.h
// Header File
// Created 02/01/2005; 20:11:47
#ifndef MEM_H
#define MEM_H

#include <tigcclib.h>

// Memory Management
#define DEV_PHASE 1 // 0: not in development phase (release), 1: get message if there is not enough *_MAX_*
#define NB_EXIT_HANDLES 7 // You may want to exit the application and let the memory manager to free NB_EXIT_HANDLES handles for you
#define INTERRUPT_MAX_HANDLERS 5
#define MEMORY_MAX_HANDLES 27
#define MEMORY_MSG "There is not enough free RAM.\nYou don't need to reset your calculator, everything has been intercepted"
#ifndef SAVE_SCREEN
  extern unsigned char * scr;
  // assumes that home screen has previously been stored into a buffer pointed by global variable unsigned char * scr;
  #define ENDING_MESSAGE "My app by me"
#endif

void mem_init(void);
__attribute__((noreturn)) void Exit (unsigned char msg);
void *Malloc (unsigned long Size);
void *MallocNoExit (unsigned long Size);
void Free (void *Ptr);
HANDLE Keep (void *Ptr);

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler); 
void ReSetIntVector(long IntVec);

#endif


mem.c
// C Source File
// Created 02/01/2005; 23:14:39

#include "mem.h"

#if DEV_PHASE == 1
unsigned char overhdl;
unsigned char overint;
#endif
#ifndef SAVE_SCREEN
unsigned char * scr;
#endif

INT_HANDLER hdlrs[INTERRUPT_MAX_HANDLERS*2];
HANDLE hdls[MEMORY_MAX_HANDLES];
unsigned short nbhdl;
unsigned short nbhdlr;

void mem_init(void) {
  nbhdl = 0;
  nbhdlr = 0;
  #if DEV_PHASE == 1
    overhdl = 0;
    overint = 0;
  #endif
}

__attribute__((noreturn)) void Exit (unsigned char msg) {
  HANDLE * hdl = hdls + nbhdl;
  for(; (hdl--) != hdls; HeapFree(*hdl));
  GrayOff ();
  INT_HANDLER* hdlr = hdlrs + 2*nbhdlr;
  for(; hdlr != hdlrs; hdlr-=2 ,SetIntVec ((long)(*hdlr), *(hdlr+1)));
  ClrScr ();
#if DEV_PHASE == 1
  char str[59];
  if(overhdl) DlgMessage("DEVELOPMENT","Not enough MEMORY_MAX_HANDLES",BT_OK,BT_NONE);
  else if(overint) DlgMessage("DEVELOPMENT","Not enough INTERRUPT_MAX_HANDLERS",BT_OK,BT_NONE);
  else if(!msg && nbhdl > NB_EXIT_HANDLES) {
    sprintf(str, "Memory Leak Detected : %u abnormally not freed Handles", nbhdl-NB_EXIT_HANDLES);
    DlgMessage("DEVELOPMENT",str,BT_OK,BT_NONE);
  }
#endif
  if(msg) DlgMessage("MEMORY",MEMORY_MSG,BT_OK,BT_NONE);
  nbhdl=0;
  nbhdlr = 0;
#ifndef SAVE_SCREEN
  LCD_restore(scr);
  ST_helpMsg(ENDING_MESSAGE);
#endif
  exit (0);  
}

static inline void *MallocInternal (unsigned long Size, unsigned char exit_if_fail) {
#if DEV_PHASE == 1
  if(nbhdl == MEMORY_MAX_HANDLES) overhdl = 1, Exit (0);
#endif
  HANDLE * hdl = hdls + (nbhdl++);
  if ((*hdl = HeapAlloc(Size)))
    return HLock(*hdl);
  nbhdl--;
  if (exit_if_fail) Exit (1);
  return NULL;
}

void *Malloc (unsigned long Size) {
  return MallocInternal(Size, 1);
}

void *MallocNoExit (unsigned long Size) {
  return MallocInternal(Size, 0);
}

static inline HANDLE FreeInternal (void *Ptr, unsigned char keep) {
  HANDLE * hdl = hdls + nbhdl - 1;
  HANDLE h = H_NULL;
  unsigned char i = 0;
  for(; HeapDeref(*hdl) != Ptr; hdl--, i++);
  if(!keep) HeapFree(*hdl);
  else h = *hdl;
  memmove (hdl, hdl+1, i * sizeof(HANDLE));
  nbhdl--;
  return h;
}

void Free (void *Ptr) {
  FreeInternal(Ptr, 0);
}

HANDLE Keep (void *Ptr) {
  return FreeInternal(Ptr, 1);
}

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler) {
#if DEV_PHASE == 1
  if(nbhdlr == INTERRUPT_MAX_HANDLERS) overint = 1, Exit (0);
#endif
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr++);
  *(hdlr++) = (INT_HANDLER)IntVec;
  *hdlr = GetIntVec (IntVec);
  SetIntVec (IntVec, Handler);
  return (*hdlr);
}

void ReSetIntVector(long IntVec) {
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr - 1);
  unsigned char i = 0;  
  for(; (long)(*hdlr) != IntVec; hdlr-=2, i++);
  SetIntVec (IntVec, *(hdlr+1));
  memmove (hdlr, hdlr+2, i * sizeof(INT_HANDLER)*2);
  nbhdlr--;
}


et un petit exemple d'utilisation :
main.c
// C Source File
// Created 28/06/2005; 15:06:16

#include <tigcclib.h>
#include "mem.h"

// pour tester la redirection d'auto int
INT_HANDLER OldInt;

DEFINE_INT_HANDLER(MyInt) {
  ExecuteHandler (OldInt);
}

// Main Function
void _main(void)
{
  // sauve l'ecran home sur la pile et fait pointer scr dessus pour quand on quitte le prog
#ifndef SAVE_SCREEN
  LCD_BUFFER scrdata;
  LCD_save (scrdata);
  scr = scrdata;
#endif

  mem_init(); // pour reinitialiser les variables globales de la lib

  char * ptr = Malloc(10000); // test d'allocation 
  ptr[0] = 0; // (pas avoir le warning unused variable si on a commenté les lignes du bas)
  OldInt = SetIntVector (AUTO_INT_1, MyInt); // test redirection
  if(!GrayOn ()) Exit(1); // si le Grayon foire il faut appeler Exit (car l'allocation n'est pas faite avec mes fonctions)
  // le parametre de Exit doit etre 1 pour dire que ca s'est terminé par une erreur
  
  // tests liberation etc ...
  
  // si tu vire ces deux lignes ca marche encore sans leaker car le Exit s'occupe de tout virer
  // ,eteindre les niveau de gris et meme de restaurer les redirections d'auto int,
  // bref la calc revient dans son etat d'origine exactement apres un Exit
/*
  Free(ptr);
  ReSetIntVector(AUTO_INT_1);
*/
  Exit(0); // parametre 0 pour dire que ca s'est bien terminé
}


Les nouveautés sont :

  • l'utilisation des HANDLEs pour la memoire allouée, on peut donc maintenant s'en servir pour enregistrer des fichiers (ne pas oublier de faire un Keep sur le pointeur afin de recuperer le HANDLE du fichier a sauvegarder et surtout afin de le retirer de la liste des buffers qui seront libérés par le Exit en fin de programme)
  • la fonction Keep (mentionnée ci-dessus)
  • la fonction MallocNoExit qui ne lance pas un Exit si elle echoue mais renvoie un pointeur NULL
  • la possibilité de quitter avec un message perso dans la status bar si SAVE_SCREEN n'est pas defini (voir l'exemple)
  • un systeme de detection de leak de handle interne (si on oublie de freer des pointeur qu'on devrait (meme si le systeme rattrape tout a la fin)


Edit : j'ai oublié de dire que j'ai viré Calloc car en fait c'est un peu bidon comme fonction (par contre faudra peut etre que je mette un Realloc)

Je crois que c'est tout, si vous avez des questions/critiques/insultes/messages en #ffffff n'hesitez pas :D
Pour ce qui est de l'utilisation du code, comme d'hab vous en faite ce que vous voulez, vous pouvez meme l'imprimer sur du PQ et vous connaissez la suite... :p
Bref et si vous l'utilisez et que vous voulez mentionner mon nom (Lionel Anton) pas de pb et si voulez pas le mentionner pas de pb non plus :) voila

-Edité le Jeudi 14 juillet 2005 à 04:08 par LionelA-
-Edité le Vendredi 15 juillet 2005 à 15:15 par LionelA-
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°10   Marquer comme non lu.
LionelA Ecrit le: Jeudi 14 juillet 2005 à 04:43 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Je pense que je sortirais un article qui regroupera toutes mes techniques de prog (synchro, link, memoire) -> "The Forbidden TI Techniques" :D au fait, merci pour le nom JfG
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°11   Marquer comme non lu.
Folco Ecrit le: Jeudi 14 juillet 2005 à 09:49 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Pas mal, mais implémenter tout ça dans chaque programme, ça revient pas à recréer un kernel pour chaque programme??? pas mal pour la place mémoire :/
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°12   Marquer comme non lu.
Lionel Debroux Ecrit le: Jeudi 14 juillet 2005 à 11:58 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

Ce système n'est nécessaire que pour les programmes qui sont codés n'importe comment, c'est marqué depuis le début de ce topic...
Lionel Debroux - membre de TICT.
    
./Post n°13   Marquer comme non lu.
LionelA Ecrit le: Jeudi 14 juillet 2005 à 15:13 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Ben ouais evidement, je le conseille pas mais c'est très utile pour les programme qui comportent des tonnes d'allocations (en tout cas c'est mieux que de devoir se farcir de TRY partout je trouve)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°14   Marquer comme non lu.
limmt Ecrit le: Jeudi 14 juillet 2005 à 16:45 Déconnecté(e)    Voir le profil de limmt Envoyer un email à limmt Visiter le site WEB de limmt Envoyer un message privé à limmt  


et les mallloc_throw ca vous dit pas? :D
http://www.falco-fr.com/ - http://www.jump67.com/ - http://www.msf-league.com/
    
./Post n°15   Marquer comme non lu.
LionelA Ecrit le: Jeudi 14 juillet 2005 à 17:12 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


ben ca veut dire que tu fais confiance a AMS pour rattraper la merde ou bien que tu entoure tes malloc_throw par des TRY etc... (cf. les posts de Kevin) et ca ca sux si t'as des tonnes de malloc.
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°16   Marquer comme non lu.
Folco Ecrit le: Jeudi 14 juillet 2005 à 17:19 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


...
Un programme bien fait doit être capable de libérer ses allocations et de quitter sans crasher la calc en cas d'échec sur une alocation, pour moi c'est l'essentiel, après quelque soit la méthode, si ça marche, tant mieux.
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°17   Marquer comme non lu.
Link Ecrit le: Vendredi 15 juillet 2005 à 10:02 Déconnecté(e)    Voir le profil de Link Envoyer un email à Link Visiter le site WEB de Link Envoyer un message privé à Link  

En fait, ce truc doit être pas mal pour débugguer...

Par contre, je ne vois pas trop ce que c'est que NB_EXIT_HANDLES ... #confus#
    
./Post n°18   Marquer comme non lu.
Folco Ecrit le: Vendredi 15 juillet 2005 à 13:34 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Sans trop regarder, ça doit être la taille d'un buffer de handles non?
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°19   Marquer comme non lu.
LionelA Ecrit le: Vendredi 15 juillet 2005 à 14:50 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


non non :)
En fait c'est pour detecter le nombre de handles non libérés a l'interieur du programme durant la phase de developpement.
En fait quand le main quitte on peut vouloir que ca soit normal que le Exit libere un certain nombre de handles qui sont utilisés tout au long du prog (ca evite de mettre du code pour liberer ces handles) et donc il ne faut pas qu'ils soient detectés parmi les handles anormalement non libérés.
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
  :: Index » Forum Ti68K » Programmation C » Méthode de gestion des mallocs (32 réponse(s))
Pages : 1/2     « [1] 2 » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 71.82ms avec 18 requetes