[RESOLU] arrachage de cheveux sur les pointeurs

[Mephisto]

pour un gros faignan, tu te fais bien chier.

je veux bien croire que ce que tu aimerais faire est possible sous windows, mais si c'est le cas, t'as pas fini de bouffer de la doc.

qu'est-ce qui te gêne dans l'utilisation du `for (i=0;elt;i++)' ?

[GROS_FAIGNAN]

je veux bien croire que ce que tu aimerais faire est possible sous windows, mais si c'est le cas, t'as pas fini de bouffer de la doc.

qu'est-ce qui te gêne dans l'utilisation du `for (i=0;elt;i++)' ?

bas en fait rien ne me gene dans le for.

par contre imaginons que mon malloc=coef(void)*sizeof(char). je peut faire le printf de chaque ligne alloué a mon pointeur mais si y'en a 2000 sa risque de me prendre du temps de toutes les recompté. en plus sa me garantie pas que mon coef(void) ne change pas de valeur entre le moment ou je malloc et le moment ou je fait mon printf.

bon je veut bien que ce soit un peut tiré par les cheveux, surtout vue ce que j'ecrit comme programme, mais d'un autre coté, vu ce que malloc peut entrainé comme bug (en tout cas pour un debutant^^) je me suis dit que prendre des habitude de controle a son sujet serait pas une mauvaise chose.

par exemple, le probleme que j'avais eu c'etait que j'utilisait sizeof(xjoueur) au lieu de sizeof(*xjoueur) dans mon malloc, du coup mon sizeof etait egale a 4 octect, et comme je faisait mes intitialisation avec memset en meme tant que mon printf dans une boucle for, bas je sais pas trop ce qui ce passais (a premiere vu je dirais qu'il ecrivait et lisait des espace memoire non alloué), en tout cas j'avais bien les X printf correspondant, l'erreur ne m'etant retourné qu'en fin de fichier, au moment du free().

et pour la retrouvé j'ai pas mal galérer.

mais tout est resolu : super lien breiz

j'ai trouver ce que je cherchais etait juste a coté

et pour windows, l'utilitaire qui renvoie la taille d'un bloc memoire alloué est

size_t _msize(const void *ptr)// retourne la taille en octet d'un espace memoire alloué sur windows
size_t malloc_size(const void *ptr)// la meme chose sous mac OS X

partant de la j'ai juste a faire

x=(sizeof(*xjoueur)/_msize(xjoueur))// et je verifie que ma valleur de x correpond bien a mon coef d'allocation.

pour un gros faignan, tu te fais bien chier.

beau gosse desoeuvré (monté comme un p**ey) cherche a s'occupé.

et puis c'est surtout que si je veut programmé autre chose que des tp de jeu de nombre rapidement, j'ai interet a accelerer le mouvement.

@ BreizFenrir : merci pour ton lien et dsl de pas t'avoir repondu au sujet de la SDL, mais je pensait l'installé rapidement et puis j'ai pas eu le temps.

[Shtong]

Tu as fait là de fort jolies recherches et de fort pertinentes réflexions mais dans la quasi-totalité des cas l'adresse de départ suffit. Oui tu peux toujours utiliser des méthodes pour regarder la taille de la zone mémoire etc... mais ça se fait au détriment des performances et de la lisibilité de ton code, et encore une fois c'est complétement inutile en pratique.

Une bonne technique pour résoudre une bonne partie des problèmes que tu viens de citer est par exemple de créer une variable avant le malloc pour contenir la taille de la zone mémoire et du tableau :

int i = 0;
int tailleTbl = coef(void);
t_size tailleMem = tailleTbl * sizeof(char);

char* tableau = malloc(tailleMem);

for(i = 0; i < tailleTbl; ++i)
{
 ...
}

[Spaz001]

Tu pars dans aller lire l'info de malloc qui lui permet de se retrouver ...

ou malloc alloue ce que tu lui as demandé, ou il le fait pas.

dans ton exemple "malloc(coef*sizeof(xjoueurs))", si tu veux savoir la taille alloué, ben la taille EST "coef*sizeof(xjoueurs)", pas besoin de vérifier.

Comme le dit Shtong, sauvegarde la taille alloué, si tu arrives pas à la retrouver.

[GROS_FAIGNAN]

Tu as fait là de fort jolies recherches et de fort pertinentes réflexions mais dans la quasi-totalité des cas l'adresse de départ suffit. Oui tu peux toujours utiliser des méthodes pour regarder la taille de la zone mémoire etc... mais ça se fait au détriment des performances et de la lisibilité de ton code, et encore une fois c'est complétement inutile en pratique.

Une bonne technique pour résoudre une bonne partie des problèmes que tu viens de citer est par exemple de créer une variable avant le malloc pour contenir la taille de la zone mémoire et du tableau :

l'idée que je m'en faisait c'etait surtout pour la debug, et une fois qu'elle est faite ont vire ce genre d'instruction, ce qui peut egalement eviter au compilateur d'avoir a declarer autant de variable qu'il y a d'appel a malloc ou en entrée de fonction.

sa bouffe beaucoup de performance (CPU..???) ce genre d'outils ?

a ce propos j'ai vue un truc la dessus dans un bouquin mais c'est sous GCC avec un environnement Unix.

il passe en ligne de commande "Time ()" avec des parametre "nom du fichier" ; "nom du fichier"_O (optimisation statique du code je croi ?) et sa permet de voire les temps d'execution avec et sans optimisation. sauf que pas de bol je suis sous winwin.

c'etait juste une petite appartée histoire de, meme si pour l'instant je m'en passe allègrement.

sinon maitenant dans les tuto du site du zero ils passe au lib graphique SDL et win32. j'attaque par la ou ya eventuellement d'autre choses a voire avant, peut etre plus importantes ?

mephisto me parlait de l'algo, quoi d'autre ?

[EDIT] ha oui ! les listes chainées peut etre, sa devrait deja faire pas mal.

a ce propos, vus que j'y ai rapidement jeté un piti coup d'oeil, ya des programme ou des algo qui permette le calcul de la "complexité" ou il faut tout faire manuellement ???