conseils d'alloc - Page 1

J'ai un tableau de string a créer dynamiquement.
Je connais a l'avance la taille du string.
J'hésite donc entre les deux solutions:
- soit j'alloue une fois nb_str * taille_str
- soit j'ailloue un tableau de pointeurs, puis tous les strings

la premiere solution me facilite l'allocation et la libération
la deuxieme me facilite l'echange de str, l'ajout et le retrait : juste un echange de pointeurs...

quel est le mieux au niveau de la ram?
PS: je n'ai pas besoin d'etre optimisé en vitesse d'exec

La premiere, et tu peux te faire des macros pour simplifier les echanges etc.

Tu utilises un pointeur sur un tableau, comme ça tu n'as qu'une seule allocation/désallocation et tu accèdes à tes chaine par un indice.

[edit]:Tiens, j'ai du temps à perdre :

#define SIZE_STR 15 // La taille de ta chaine
#define NB_STR 10 // Le nombre de chaines
 
char (*chaines)[SIZE_STR];
 
chaines=malloc(SIZE_STR*NB_STR);
 
for(i=0;i<NB_STR;i++)
{
 DrawStr(0,10*i,chaines[i],1);
 ngetchx();
}

jackiechan> merci, je savais comment faire
C'est juste qu'en nombre de ligne de code, déplacer un str va en faire plus que par pointeurs. En même temps l'allocation est effectivement plus simple.
La question que je me pose principalement, c'est a propos de la RAM de la TI. Faire plein de petite alloc ou une grosse...? je ne sais pas trop comment marche l'alloc, je me demande si ca y'a pas des effet de "fragmentation" avec plein de petite...

Je ne crois pas qu'il y ait des effets de fragmentation.
Sinon, tu veux les utiliser pour faire quoi en fait, tes chaine ?
Parce que c'est clair qu'avec ma technique, ça va être galère pour en supprimer ou déplacer.
Le mieux ce serait d'utiliser une liste chaînée, je pense dans ton cas...

c'est pour mon hibtext : j'ai des favoris : je stocke le nom du text (taille fixe a 18).
Je veux donc pouvoir en ajouter, en retirer, et les ranger dans l'ordre que l'utilisateurs veux.

uns liste chainée, qu'est-ce que c'est ?
je connais peut-être la technique, mais j'ai peut-être jamais mis de nom dessus.

struct{
void element;
lst *precedent;
lst *suivant;
} lst;

me semble que c un truc comme ca

Oui, une liste chaînée serait pratique alors, je pense.

Il s'agit tout simplement de relier entre elles tes strings :
str1 -> str2 -> str3 -> str4 -> 0
Si tu veux un supprimer la string 3, il te suffit simplement de faire pointer la 2 sur la 4, ce qui fait qu'en parcourant ta liste chaînée, tu passeras directement de la 2 à la 4, donc c'est comme si la 3 aurait été supprimée.

Si tu veux ajouter une string, il te suffit de faire l'opération inverse : tu veux par exemple ajouter une string entre la 3 et la 4, tu n'as qu'à faire pointer la 3 vers cette nouvelle string et faire pointer la nouvelle vers la 4. Ainsi en parcourant la liste chainée, tu iras de la 3 à la nouvelle, puis à la 4.

Pour déplacer une string, ça revient au même que la supprimer puis l'ajouter quelque part.

Par exemple, voici une structure possible :

#define TAILLE_STR 15
 
typedef struct favori
{
 char string[TAILLE_STR];
 struct favori *suivant; // Ou bien 'short suivant;' si tu utilises un tableau, ce qui sera probablement ton cas
}FAVORI;

Tu peux te contenter d'un membre suivant seulement ou bien tu peux chainer ta liste doublement : tu rajoute un pointeur vers le membre précédent. Mais ça te fait faire deus fois plus de manipulations pour en supprimer ou en ajouter une.

pis fait une liste circulaire ... (1->2->3->0->1->2 ...)

Je connaissais pas.
Ca peut etre interessant.
L'allocation semble aussi longue qu'un tableau de pointeur
L'ajout et l'échange semble ultra simple. pour retirer aussi
ca peut meme m'aider a faire d'autre choses...
Y'a ptet l'acces au nieme element qui va etre un peu long
La taille mem est équivalente au tableaux de pointeurs

faut que j'y réfléchisse.
merci

par contre, ca demande pas mal de petites allocations, je pense qu'un alloca devrait suffir pour cela ..

le alloca me plait pas trop.
Je permet de mettre 256 favoris
Si un utilisateur un peu farfelu (si si ca existe) les utilisent tous... 256*(18+8)=6656
Et j'ai aussi un historique a gérer => x2=13 ko !

Je viens de l'implementer en partie, et ca s'integre tres bien. Je vais meme avoir qq simpification d'une routine d'affichage
je profite de l'effet circulaire

liste chainée adoptée

Les listes chaînées et les tableaux de pointeurs n'ont rien à faire sur TI-89/92+/V200 (sauf éventuellement pour un très petit nombre d'entrées)!!! Ça:
* fragmente la RAM. Tu alloues plein de blocs verrouillés! La RAM ne pourra être défragmentée correctement qu'après que tous les blocs en question aient été libérés. Et encore, seulement si on n'a pas alloué d'autres blocs verrouillés entretemps, qui se trouveraient en plein milieu de la RAM.
* risque d'atteindre le nombre maximal de handles. N'oublie pas que les fichiers prennent aussi des handles, donc si tu en alloues encore un bon paquet, le nombre maximal (2000) peut être atteint.
* complique l'enregistrement des données dans un fichier.

ah, ca frangmente le ram donc, en plus du pb du nb de handle.
donc on reprend les sources et on reprogramme tout pour la nieme fois...
c'est bien parce que j'aime ca

>complique l'enregistrement des données dans un fichier.
ca, ca ne regarde que moi et l'optimisation de mon programme... ?!

hibou: c pas pke KK a dit non que tu ne peux pas le faire

je sais bien
mais j'ai pas envie de consommer trop de ram... je veux optimiser en ram.

Mais j'ai une nouvelle idée. je vais utiliser quand même les listes chainées quand meme bien pratiques, tout en faisant une grosse alloc.
je travaillerais pas avec des pointeurs sur des alloc mais sur des no de case d'un (gros) tableau

a suivre....

Voilà, c'est ce que j'allais te conseiller pour éviter les inconvénients qu'a énumérés Kevin

Exactement, et c'est ce que je t'ai conseillé dans mon post #7 (le commentaire, après le champ suivant).
C'est vraiment très pratique et ça ne fait pas plein d'alloc différentes.