Bibliothèque C pour la gestion des tableaux

**alphalog** · 16/04/2007, 13h12

Bonjour,

A force d'écrire des codes scientifiques en C, je me retrouve avec un problème de gestion des érreurs et de la mémoire. Plus exactement, le fait de tester l'allocation et de faire l'initialisation à la main de mes tableaux chaque fois est devenu un souci, surtout lorsqu'on utilise plusieurs tableaux chaques fois. Le passage par le C++ et par la structure vecteur n'est pas (à ma connaissance) recommendé dans ce genre de code, vu qu'elle peut dégrader un peu les performances.
Est ce qu'il y a quelqu'un qui a une proposition?

Merci d'avance

**Emmanuel Delahaye** · 16/04/2007, 13h27

Envoyé par alphalog

A force d'écrire des codes scientifiques en C, je me retrouve avec un problème de gestion des érreurs et de la mémoire. Plus exactement, le fait de tester l'allocation et de faire l'initialisation à la main de mes tableaux chaque fois est devenu un souci, surtout lorsqu'on utilise plusieurs tableaux chaques fois.<...> Est ce qu'il y a quelqu'un qui a une proposition?

http://emmanuel-delahaye.developpez.com/clib.htm
Module FARR (Flexible ARRay)

**souviron34** · 16/04/2007, 13h59

Envoyé par alphalog

Bonjour,

A force d'écrire des codes scientifiques en C, je me retrouve avec un problème de gestion des érreurs et de la mémoire. Plus exactement, le fait de tester l'allocation et de faire l'initialisation à la main de mes tableaux chaque fois est devenu un souci, surtout lorsqu'on utilise plusieurs tableaux chaques fois. Le passage par le C++ et par la structure vecteur n'est pas (à ma connaissance) recommendé dans ce genre de code, vu qu'elle peut dégrader un peu les performances.
Est ce qu'il y a quelqu'un qui a une proposition?

Merci d'avance

Bof... ça force une pensée et une lisibilité correcte..(et en particulier des libérations correctes en cas d'échec, ce qui est très important pour la robustesse)...

Et franchement avec le copier/coller, c'est pas très pénible.

Pour ce qui est de l'initialisation, à part si c'est pour initialiser à zéro (ce qui est faisable rapidement avec calloc ) pour le reste ça me semble pas franchement plus simple d'utiliser une bibliothèque..

Mais ceci n'est que mon humble avis..

**stephl** · 16/04/2007, 14h02

Envoyé par souviron34

...
Mais ceci n'est que mon humble avis..

... que je partage.

**siplusplus** · 16/04/2007, 14h09

Les vecteurs de la STL sont très efficaces.
L'allocation dynamique est prise en charge dans les primitives du vecteur même.

**reptils** · 16/04/2007, 15h57

Envoyé par stephl

... que je partage.

également....

**alphalog** · 17/04/2007, 09h18

Merci à tout ceux qui ont enrichi ce petit débat,
-Le copie coller est facile mais pas efficace en terme de visibilité et de maintenabilité du code, pour allouer 1 tableau de 2 dimension avec tout les tests qui faut je compte environ de 12 lignes de code, voici un exemple d'une fonction qui fait que cela:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
int amallocd2(double **d2,unsigned int size1,unsigned int size2){
	unsigned int i,j;
	if( (d2 =(double **)malloc(sizeof(double*)*size1)) == NULL){
	fprintf(stderr,"%s, in file: %s Func: %s Line: %d\n",
			_MSG_ALLOC,__FILE__, __FUNCTION__,__LINE__);
	}
	for(i =0; i<size1; i++){
		if( (d2[i]=(double*)malloc(sizeof(double)*size2)) == NULL){
		fprintf(stderr,"%s, in file: %s Func: %s Line: %d\n",
					_MSG_ALLOC,__FILE__, __FUNCTION__,__LINE__);
					for(j=i-1; j>0; j--){
					free( d2[j]);	
					}
					free(d2);
					return EXIT_FAILURE;
		}
	}
	return EXIT_SUCCESS;
}

imaginons alors un code avec une allocation de 10 tableaux de 2 dimension (si c'est pas 3d)

D'ou j'ai eu une idée de créer une bibliothèque pour ce but, mais avant de commencer j'ai besoin de savoir si c'est vraiment qlqchose qui vaut le cout ou pas!!

Merci d'avance pour vos commentaires.

**alphalog** · 17/04/2007, 09h23

Un autre souci qui va avec cela, c'est la gestion de la mémoire,
dans pas mal de code on trouve des allocations dans tous les sens mais la désallocation n'est pas bien faite, si on dispose d'un outils facile de debug qui nous indique la situation de la pile d'allocation ça serai très bien. C'est une des fonctionnalité que j'ai pensé qu'il faut avoir dans une bibliothèque comme ceci.

**Emmanuel Delahaye** · 17/04/2007, 09h31

Envoyé par alphalog

Un autre souci qui va avec cela, c'est la gestion de la mémoire,
dans pas mal de code on trouve des allocations dans tous les sens mais la désallocation n'est pas bien faite, si on dispose d'un outils facile de debug qui nous indique la situation de la pile d'allocation ça serai très bien. C'est une des fonctionnalité que j'ai pensé qu'il faut avoir dans une bibliothèque comme ceci.

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

Je ne sais pas si tu as bien lu tout le fil, mais j'ai déjà répondu à tes questions existentielles...

J'ai reglé ce problème il y a déjà quelques temps...

**Garulfo** · 17/04/2007, 09h46

Envoyé par souviron34

[...]
Et franchement avec le copier/coller, c'est pas très pénible.
[...]

Mais fortement problématique par la propagation d'une erreur.
Retaper force la relecture.

**alphalog** · 17/04/2007, 09h48

......
Je vais prendre le temps de regarder cela, il y a des choses qui me parraissent très intéréssantes.
Merci

**Ulmo** · 17/04/2007, 12h32

Envoyé par alphalog

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
int amallocd2(double **d2,unsigned int size1,unsigned int size2){
	unsigned int i,j;
	if( (d2 =(double **)malloc(sizeof(double*)*size1)) == NULL){
	fprintf(stderr,"%s, in file: %s Func: %s Line: %d\n",
			_MSG_ALLOC,__FILE__, __FUNCTION__,__LINE__);
	}
	for(i =0; i<size1; i++){
		if( (d2[i]=(double*)malloc(sizeof(double)*size2)) == NULL){
		fprintf(stderr,"%s, in file: %s Func: %s Line: %d\n",
					_MSG_ALLOC,__FILE__, __FUNCTION__,__LINE__);
					for(j=i-1; j>0; j--){
					free( d2[j]);	
					}
					free(d2);
					return EXIT_FAILURE;
		}
	}
	return EXIT_SUCCESS;
}

Pas de cast du retour de malloc en C
Pour la lisibilité, éviter d'utiliser le résultat d'une affectation (le "if ((a=b) == c)" )
Plutôt utiliser "sizeof(*d2)" et "sizeof(**d2)" que "sizeof(double *)" et "sizeof(double)", des fois que tu changes le type de d2.
Tu oublies de sortir de la fonction si la première affectation a échoué
Tu ne libères pas d2[0] si une allocation échoue dans la boucle

**souviron34** · 17/04/2007, 12h40

Envoyé par Garulfo

Mais fortement problématique par la propagation d'une erreur.
Retaper force la relecture.

Absolument d'accord, mais vu l'argument du PO.....

Quant à lui, le PO :

Envoyé par alphalog

imaginons alors un code avec une allocation de 10 tableaux de 2 dimension (si c'est pas 3d)

bah j'ai vraiment rarement vu le cas de tableaux à 2 dimensions, et pourtant j'ai fait beaucoup de traitements d'images....

Mais de toutes façons, je ne vois pas en quoi ça améliore la portabilité... Et pour la lisibilité, bof...

je ne vois pas en quoi :

Code :

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

1
2
3
4
 
  *NewPts = (Pt *) calloc ( (N_Pts+2), sizeof(Pt) );
  if ( (*NewPts) == (Pt *)NULL )
      return (-1) ;

est illisible et compliqué...

Et au moins tu sais ce que tu fais..

Et pour tes arguments pour la libération, il est un certain nombre de cas où c'est alloué quelque part et libéré ailleurs...

M'enfin c'est ton choix...

**siplusplus** · 19/04/2007, 19h11

Le tableau 2d a l'air homogène, il ne serait pas plus simple de le ramener
sur une dimension?

Bibliothèque C pour la gestion des tableaux

C

Discussions similaires

Partager

Partager