Bibliothèque C pour la gestion des tableaux

Version imprimable

16/04/2007, 13h12
alphalog

Bibliothèque C pour la gestion des tableaux

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
16/04/2007, 13h27
Emmanuel Delahaye

Citation:

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)
16/04/2007, 13h59
souviron34

Citation:

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..
16/04/2007, 14h02
stephl

Citation:

Envoyé par souviron34

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

... que je partage.
16/04/2007, 14h09
siplusplus

Les vecteurs de la STL sont très efficaces.
L'allocation dynamique est prise en charge dans les primitives du vecteur même.
16/04/2007, 15h57
reptils

Citation:

Envoyé par stephl

... que je partage.

également....

Bibliothèque C Array

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:

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) :cry:

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.

17/04/2007, 09h23
alphalog

Suite: gestion de mémoire

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.
17/04/2007, 09h31
Emmanuel Delahaye

Citation:

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...
17/04/2007, 09h46
Garulfo

Citation:

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.
17/04/2007, 09h48
alphalog

OK lets go

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

Citation:
Envoyé par alphalog
Code:

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

17/04/2007, 12h40
souviron34
Citation:

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 :

Citation:

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:

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

:D
19/04/2007, 19h11
siplusplus

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