pb de pointeurs

**Jack_serious** · 29/05/2006, 00h10

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 ?

**gnto** · 29/05/2006, 00h11

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.

Envoyé par gnto

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**gnto** · 29/05/2006, 00h14

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

**Emmanuel Delahaye** · 29/05/2006, 00h18

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

**Emmanuel Delahaye** · 29/05/2006, 00h19

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.

**crocodilex** · 29/05/2006, 00h23

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....

**gnto** · 29/05/2006, 00h28

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

**Emmanuel Delahaye** · 29/05/2006, 00h34

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()...

**Emmanuel Delahaye** · 29/05/2006, 00h36

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...

**crocodilex** · 29/05/2006, 00h41

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

**Emmanuel Delahaye** · 29/05/2006, 00h48

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é.

**gnto** · 29/05/2006, 00h48

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.

**Emmanuel Delahaye** · 29/05/2006, 00h55

Envoyé par gnto

nan je parle de librairie.

Alors je ne connais pas.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**crocodilex** · 29/05/2006, 00h58

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.

**gnto** · 29/05/2006, 01h04

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

**Emmanuel Delahaye** · 29/05/2006, 01h15

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..

**gnto** · 29/05/2006, 08h57

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 )

**gnto** · 29/05/2006, 09h03

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...

pb de pointeurs

C

Discussions similaires

Partager

Partager