pb de pointeurs

Bonjour,

Voila la je commence a fatiguer,

Code:

---

1 2 3 4 5

typedef struct _Ligne Ligne struct _Ligne { char s[60]; };

---

dans la fonction main

Code:

---

1 2 3 4

Ligne * buffer = NULL; void mafonction(&buffer); free(buffer);

---

dans ma fonction

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void mafonction(Ligne ** buffer) { static int tailleBuffer=0;   //tailleBuffer evolue dans la fct mais j'ai simplifié le code mais tailleBuffer est non nulle et supérieur à 3   *buffer = realloc(*buffer,sizeof(Ligne)*tailleBuffer);   buffer[2]->s[0]='a';//erreur de segmentation   }

---

La je m'embrouille, j'aimerais savoir comment on peut allouer et initialiser buffer dans mafonction et libérer dans la fonction main.

Je dirais

Code:

---

(*buffer)[2].s[0]='a';

---

tailleBuffer = 0;

realloc(*buffer,sizeof(Ligne)*tailleBuffer);

sizeof(Ligne)*tailleBuffer = 0;
Donc tu n'alloue pas grand chose la.

selon ddd, l'allocation est bien effectué mais buffer[2] pointe sur n'importe quoi ! c pas un pb de type

*buffer =>4
buffer => 60

nan tailleBuffer n'est pas nulle j'ai pas mis le code pour affecter une valeur a tailleBuffer pour des soucis de lisibilité

Citation:

---

Envoyé par Gruik

Je dirais

Code:

---

(*buffer)[2].s[0]='a';

---

---

je vois pas la différence entre

(*buffer[2]).s[0] = 'a';
et
buffer[2]->s[0]='a';

(*variable).champ == variable->champ Enfin je crois

Le problème vient certainement de l'appel à la fonction realloc().
Tu lui passes un pointeur non initialisé.

*buffer == NULL donc y'a pas de problème

l'erreur vient de l'affectation

Citation:

---

Envoyé par gnto

*buffer == NULL donc y'a pas de problème

l'erreur vient de l'affectation

---

Oui en effet, dans ce cas là c'est équivalent à un malloc. Au temps pour moi...

qd je créé une variable temp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void mafonction(Ligne ** buffer) { Ligne * temp; static int tailleBuffer = 0;   ...   temp = malloc(temp,sizeof(Ligne)*tailleBuffer);   temp[2]->s[0] = 'a'; // la ca fonctionne   }

---

le probleme c'est que je n'ai pas de retour

Pourquoi tu ne fais pas quelque chose de plus simple du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Ligne *mafonction(void) { static Ligne *buffer = NULL; static int tailleBuffer=3;   if ( (buffer = realloc(buffer,sizeof(Ligne)*tailleBuffer)) != NULL) { buffer[2].s[0]='a'; } return buffer; }   int main(void) { [...] Ligne * buffer = NULL; buffer = mafonction(); free(buffer); [...] return 0; }

---

j'attendais la question,

j'aimerais avoir une signature de ce type

int mafonction(Ligne ** buffer,size_t count)

Tout ca pour dire que la solution t'avais ete donné par Gruik

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

#include <stdio.h> #include <stdlib.h>   typedef struct _Ligne Ligne; struct _Ligne { char s[60]; };   void mafonction(Ligne ** buffer) { static int tailleBuffer=5;   //tailleBuffer evolue dans la fct mais j'ai simplifié le code mais tailleBuffer est non nulle et supérieur à 3   *buffer = realloc(*buffer, sizeof(Ligne)*tailleBuffer);   (*buffer)[2].s[0]='a'; }   int main(void) { Ligne * buffer = NULL; mafonction(&buffer); free(buffer); return 0; }

---

peut on me donner la difference entre

(*variable).champ et variable->champ

parce que j'ai toujours cru que c'étais la même chose !!

J'allais oublier de vous remercié tous.

Citation:

---

Envoyé par gnto

peut on me donner la difference entre

(*variable).champ et variable->champ

parce que j'ai toujours cru que c'étais la même chose !!

J'allais oublier de vous remercié tous.

---

C'est effectivement la meme chose, c'est juste une ecriture simplifié.

Mais ici avec ton probleme
(*buffer)[2]...
(*buffer[2])...
*buffer[2]...

Ce n'est pas la meme chose. Quand tu as un doute avec la priorité des opérateurs met des parenthèses.

Citation:

---

Envoyé par gnto

Voila la je commence a fatiguer,

---

Moi aussi. Ne pas recopier le code, mais faire un copié/collé. C'est plein de bugs inutiles...

A part ça, si tailleBuffer vaut 0, sizeof(Ligne)*tailleBuffer vaudra 0, donc realloc() va retourner NULL (jamais testé...)

Comportement indéfini.

De plus, si tu veux écrire en buffer[2], il faut que tailleBuffer soit > 2... (jamais testé...).

De toutes façons, cette conception est atroce (Force 9).

http://emmanuel-delahaye.developpez.com/goret.htm

Pour faire un tableau souple, il faut utiliser une structure qui regroupe

• l'adresse de base du tableau
• sa taille

Ici, ce serait

Code:

---

1 2 3 4 5 6

struct tabdyn { Ligne *p_lines; size_t nb_lines; };

---

Citation:

---

Envoyé par Emmanuel Delahaye

Moi aussi. Ne pas recopier le code, mais faire un copié/collé. C'est plein de bugs inutiles...

---

Ah oui ? j'ai recopié par souci de simplification et pour aller à l'essentielle.

Citation:

---

Envoyé par gnto

Ah oui ? j'ai recopié par souci de simplification et pour aller à l'essentielle.

---

Oui mais la par exemple en recopiant tu as glisser des erreurs dans ton code (oubli de ;, appel de fonction avec void devant).

Donc c'est plus simple de faire un copier/coller.

Citation:

---

Envoyé par crocodilex

Pourquoi tu ne fais pas quelque chose de plus simple du genre :

Code:

---

1 2 3 4

Ligne *mafonction(void) { static Ligne *buffer = NULL; static int tailleBuffer=3;

---

---

Goretisation de force 9 !
http://emmanuel-delahaye.developpez.com/goret.htm

Citation:

---

Envoyé par gnto

peut on me donner la difference entre

(*variable).champ et variable->champ

parce que j'ai toujours cru que c'étais la même chose !!

---

Certes, mais le problème, c'est que tu as dans ton code une atrocité appelée 'douple pointeur', qu'il est préférable de fuir pour ne pas avoir ces écritures gores...

Je recommande fortement l'usage de la structure qui nous ramènes à des choses connues et lisibles du style : p->element...

Citation:

---

Envoyé par Emmanuel Delahaye

Goretisation de force 9 !
http://emmanuel-delahaye.developpez.com/goret.htm

---

Tiens la tu m'interesse.
J'ai arrete il y a quelques temps mais je n'ai pas trouve de reponse convaincante et tu vas surement pouvoir m'eclairer.

Pourquoi les static saymal ?

Citation:

---

Envoyé par Emmanuel Delahaye

A part ça, si tailleBuffer vaut 0, sizeof(Ligne)*tailleBuffer vaudra 0, donc realloc() va retourner NULL (jamais testé...)

Comportement indéfini.

---

Citation:

---

Envoyé par gnto

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void mafonction(Ligne ** buffer) { static int tailleBuffer=0;   //tailleBuffer evolue dans la fct mais j'ai simplifié le code mais tailleBuffer est non nulle et supérieur à 3   *buffer = realloc(*buffer,sizeof(Ligne)*tailleBuffer);   buffer[2]->s[0]='a';//erreur de segmentation   }

---

---

Il me semble que j'avais laissé un commentaire

les static sont a utiliser en dernier recours car ils sont défini en mémoire pendant la durée de tout le programme, a l'inverse des variables locales

Citation:

---

Envoyé par Jack_serious

Tiens la tu m'interesse.
J'ai arrete il y a quelques temps mais je n'ai pas trouve de reponse convaincante et tu vas surement pouvoir m'eclairer.

Pourquoi les static saymal ?

---

Parce que ça rend le code non réentrant, aux appels non imbricables car le donnée statique n'est pas instanciable (ou alors à que prix...). Les données persitantes doivent appartenir à l'utilisateur, pas à l'implémenteur.

Code:

---

1 2 3 4 5 6 7 8

{ T a; T b;   f (&a); f (&b); }

---

C'est tout le problème de strtok(), par exemple.

Citation:

---

Envoyé par gnto

les static sont a utiliser en dernier recours car ils sont défini en mémoire pendant la durée de tout le programme, a l'inverse des variables locales

---

Il n'y a aucune justification pour utiliser des statiques. Apprend plutôt à programmer par contexte persistants.

Citation:

---

Envoyé par Emmanuel Delahaye

Goretisation de force 9 !
http://emmanuel-delahaye.developpez.com/goret.htm

---

Que le developpeur qui n'a jamais utilisé de variable static se fasse connaître...
Aïe, aïe, aïe...qu'est-ce qu'il ne faut pas entendre....

comment géres-tu les flags dans une librairie si tu n'as pas de variables statiques ?

Citation:

---

Envoyé par crocodilex

Que le developpeur qui n'a jamais utilisé de variable static se fasse connaître...
Aïe, aïe, aïe...qu'est-ce qu'il ne faut pas entendre....

---

J'évite au maximum. Montre les cas où ce n'est pas possible ?
Dans ma CLIB,

http://emmanuel-delahaye.developpez.com/clib.htm

je ne connais que SYSALLOC (normal, il n'y a pas de contexte dans les fonctions malloc() etc. et par définition, je n'ai pas le choix de l'interface) mais la ressource est garantie d'être unique, alors je l'accepte (de toutes façon, je n'ai pas le choix).

Quand aux applications, je ne vois pas non plus à quoi ça pourrait servir à part pour les interruptions matérielles qui devraient partager des données...

Enfin, pour les gros tableaux qui ne tiennent pas en automatique, la solution est évidemment malloc()...

Citation:

---

Envoyé par gnto

comment géres-tu les flags dans une librairie si tu n'as pas de variables statiques ?

---

Je suppose que tu parles de bibliothèques ? C'est le dernier endroit où il doit y avoir des statiques.

Quel flag ? Pourquoi faire ? Donne un exemple précis, parce à part le cas très particulier que j'ai énoncé au dessus, je n'en vois pas.

Au fait, on est bien d'accord que je ne parle que des statiques à lecture écriture, bien sûr. Les statiques const sont les bienvenues...

Citation:

---

Envoyé par Emmanuel Delahaye

J'évite au maximum. Montre les cas où ce n'est pas possible ?
[...]

---

Moi aussi, quand je peux, j'évite au maximun d'utiliser les variables globales et les statics.
Je développe du logiciel de base (BSP, drivers et de temps en temps des applis), et je peux t'assurer que dans certains cas je ne peux pas me passer de variables globales.
Donc mettre un niveau de goret 9 sur les statics, je trouve que tu y vas un peu fort...Moi j'aurai mis un niveau 2

Citation:

---

Envoyé par crocodilex

Moi aussi, quand je peux, j'évite au maximun d'utiliser les variables globales et les statics.
Je développe du logiciel de base (BSP, drivers et de temps en temps des applis), et je peux t'assurer que dans certains cas je ne peux pas me passer de variables globales.
Donc mettre un niveau de goret 9 sur les statics, je trouve que tu y vas un peu fort...Moi j'aurai mis un niveau 2

---

OK, Je vais préciser 'au niveau applicatif'. Je suis d'accord que dans un driver, on ne peut pas faire autrement. Mais par définition, la ressource est limitée et les nombre d'instances donc contrôlé.

nan je parle de librairie.

Je créé une librairie qui lit dans un fichier, 3 structures on va dire A,B et C.

Je dois lire d'abord la B pour connaitre l'offset ou se situe la A et la C.

Pour simplifier l'utilisation de la librairie au programme utilisateur on n'a que très peu de point d'entrée, j'ai une fonction dans ma lib qui lit la premier fois la structure A ki place un flag(indiquer que la structure B a été lu) et je stock l'offset. La meme fonction lit ensuite la B.

La philosophie de la lib résulte en la simpliciter du programme utilisateur à l'interfacer (surtout qd le programme n'est pas réaliser en C )

Bref je sais pas si j'ai été clair.

Citation:

---

Envoyé par gnto

nan je parle de librairie.

---

Alors je ne connais pas.

Citation:

---

Je créé une librairie qui lit dans un fichier, 3 structures on va dire A,B et C.

Je dois lire d'abord la B pour connaitre l'offset ou se situe la A et la C.

Pour simplifier l'utilisation de la librairie au programme utilisateur on n'a que très peu de point d'entrée,

---

Un contexte, c'est UN point d'entrée :

Code:

---

1 2 3 4 5

/* dans le .h */ struct contexte;   int f (struct contexte *self, parametres...);

---

Rien de compliqué. L'utilisateur ne connait même pas les détails de la structure dont il n'a que faire. Les fonctions font le travail.

http://emmanuel-delahaye.developpez.com/tad.htm

Citation:

---

Envoyé par Emmanuel Delahaye

[...]

---

J'aime beaucoup cette echelle de goret, bien que je ne soit pas d'accord avec tout les points.
Il manque peut etre un paragraphe concernant les méthodes de developpement. Un peu comme ceci : http://www.la-rache.com/

Mais bon, là on est hors sujet.

ok c'est deja moins catégorique.

On est d'accord que c'est goret, faut éviter de les utiliser.
Moi j'ai pas le choix ,je suis coincé par un souci de simplicité d'interfacage, sinon crois moi je les utilisent pas

Citation:

---

Envoyé par gnto

ok c'est deja moins catégorique.

On est d'accord que c'est goret, faut éviter de les utiliser.
Moi j'ai pas le choix ,je suis coincé par un souci de simplicité d'interfacage, sinon crois moi je les utilisent pas

---

L'interface est fixée ? Qu'est-ce qui t'empêche de faire du refactoring[1]?

Et quoi ça complique l'interface ? Tu remplaces un paramètre par un autre.

Tu trouves ça compliqué à utiliser les fonctions de FILE (fopen() fgetc() etc? OK, ce qui est tordu, c'est que le contexte n'est pas toujours en 1er paramètre, mais à part ça ?)

-----------------
[1] Mot chic très tendance dans le monde de l'XP... de réécrire ton code, quoi..

c'est compliqué dans mon cas.

Je lis dans un fichier des données puis je décale a un autre endroit du fichier quand je n'ai plus de donnée à lire dans celui ci je lis un fichier suivant puis je lis dans un autre fichier et ainsi de suite.

Je veux bien que l'utilisateur gere le premier fichier d'ailleur c'est ce que je fais, il donne le nom du premiers fichier mais l'enchainement d'ouverture des autres fichiers est invisible. Ainsi l'utilisateur ne sais pas à quelle endroit la donnée a été lu, d'ailleur c'est preferable qu'il ne le gere pas.

Pour ne pas que l'utilisateur, gere un grand nombre de FILE * je les stock.

Code:

---

1 2 3 4

void archive_open(char * name); void archive_load(char * channelName); int archive_get_list_value(Ligne **buffer,size_t count); void archive_close();

---

Quoi de plus simple !!

Ps : je précise que la lib n'accepte qu'un seul prog utilisateur ( faute de temps )

Citation:

---

Envoyé par Emmanuel Delahaye

Certes, mais le problème, c'est que tu as dans ton code une atrocité appelée 'douple pointeur', qu'il est préférable de fuir pour ne pas avoir ces écritures gores...

---

Heu je prefere dans le cas d'une librairie que le programme utilisateur alloue un buffer et le désalloue. Ainsi le double pointeur est de mise.

Qu'il soit Ligne ** ou struct tabdyn * le resultat est le meme

on aura au final, un pointeur sur une structure dans lequel il y aura un poiteur sur une ligne, donc 2 pointeurs...