bon, j’ai enlever des bout, pour faire des reponses en block
[quote]
[quote]du temps, de la memoire, et de la maitrise : t’es sur que y a pas un autres truc qui va te faire un alloc dans le dos, et puis tu sais ou sont les trucs, vu que comme t’es tres fort : t’as fait une map de la memoire ! [/quote]malloc/free sont justement la pour te permettre de gerer une map de la memoire de facon simple. Si tu prefere gerer tout ca a la main a coups de mmap ou sbrk, je pense que tu t’embetes pour rien, ou alors tu as besoin d’un truc ultra optimise (et peu portable).
Dans certains languages de haut niveau il n’y a pas de malloc/free, mais quand tu declares ou que tu affectes une variable, c’est le compilo qui se charge de faire les malloc pour toi, et le garbage collector qui libere la memoire quand elle ne sert plus.
[/quote]En terme de truc “ultra optimise”, je reponds oui : je parle de programmation console, la ou la memoire est super limite, un pays ou on en viens a reduire la taille de la pile (celle dont tu parle ) a 8ko, pour gagner 8ko de plus, un pays ou oui, se dire que 8 octets (ca depends des systems, donc c’est pas une valeurs fixe) partent dans les limbes alors que ca pourrait etre utilise pour faire autre choses ( j’ai parfois vue jusqu’a 1Mo de memoire utilise par le system d’allocation (sans compter le code ! parce qu’il faut bien le mettre quelquepart, le code…), 1Mo!! on peut en foutre des trucs, dans un Mega !!!
Quand aux garbage collector, c’est la grande angoisse du programmeur de console ce truc la : tu doit t’assurer que ta boucle principale (rendu compris) va etre complete en moins d’1/60eme de seconde!, mais si tu :
c’est un peu con de se demander si on peut allouer de la memoire, alors qu’on SAIT que personne d’autre n’est la : c’est un peu comme frapper a la porte des chiotes qu’en on habite tout seul
Le quelqu’un d’autre ca peux aussi etre toi. Si quand tu as besoin d’enregistrer un truc tu choisis de le mettre aleatoirement dans une zone de la memoire sans te preoccuper de savoir si quelquechose d’important etait la avant, tu vas vers de gros problemes.
bah, le truc, c’est qu’on evite de prendre une adresse aux hazard (tiens et maintenant je vais ecrire … la: tadaa 0x01230012 !!!
ca se prepare :
par example, imaginons que tu as des missilles dans ton jeux, et que tu SAIS que tu ne peux pas en avoir plus de 256 a l’ecran, tu peux pas, c’est pas possible, c’est comme ca !
tu peux soit faire :
missile *
launchmissile(void)
{
if( numMissile < 256 )
{
missile *newmissile = (missile *)malloc(sizeof(missile));
initmissile(newmissile);
numMissile++;
return newmissile;
}
return NULL
}
[/quote]ou tu te tappe donc un malloc et un free a chaque fois qu’un missile est lancer/detruit
soit faire un :
missile *
launchmissile(void)
{
if( numMissile < 256 )
{
missile *newmissile = &missileStack[numMissile];
initmissile(newmissile);
numMissile++;
return newmissile;
}
return NULL
}
[/quote]qui va etre beaucoup beaucoup beaucoup plus rapide a executer.
et qui te permet, en plus, d’etre sur que TOUT tes missilles sont au meme endroit en memoire, et donc evite la fragmentation (parce que ca aussi c’est mal la fragmentation, et nous sur consoles : on aime pas gacher )
(bon il est evident que la gestion de la stack de missile demanderait, dans la vrais vie, un peu plus de gestions, mais je laisse ca a votre imagination )
et en ce qui concerne la portabilite, comme tu peux le voir dans l’example : c’est aussi portable, si ce n’est plus qu’un malloc (certains OS ne supportant pas malloc par defaut (oui, ca existe : des machines sur lequel le malloc n’existe juste pas !) ), et ca evite de chasser le leak !
Ce message a été édité par c0unt0 le 15/04/2003