Bonjour à tous,
suite à des réflexions suscitées sur ce forum, j'ai réflechi
à une librairie inspirée de la STL qui offre en C des containers
génériques, efficaces et typés.
Le premier jet est disponible à l'URL:
http://www.enseeiht.fr/~boyer/BPL/
C'est un tout premier jet, mais je suis à la recherches d'avis,
de marques d'intérêt et de critiques avant de partir plus avant
dans les développements.
Merci d'avance de vos remarques,
Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Bonjour à tous,
suite à des réflexions suscitées sur ce forum, j'ai réflechi
à une librairie inspirée de la STL qui offre en C des containers
génériques, efficaces et typés.
Le premier jet est disponible à l'URL:
http://www.enseeiht.fr/~boyer/BPL/
C'est un tout premier jet, mais je suis à la recherches d'avis,
de marques d'intérêt et de critiques avant de partir plus avant
dans les développements.
Merci d'avance de vos remarques,
Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Bonjour à tous,
suite à des réflexions suscitées sur ce forum, j'ai réflechi
à une librairie inspirée de la STL qui offre en C des containers
génériques, efficaces et typés.
Le premier jet est disponible à l'URL:
http://www.enseeiht.fr/~boyer/BPL/
C'est un tout premier jet, mais je suis à la recherches d'avis,
de marques d'intérêt et de critiques avant de partir plus avant
dans les développements.
Merci d'avance de vos remarques,
Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Augestad (boa at metasystems dot no) ou Hallvard Furuseth (h.b.furuseth
at usit dot uio dot no), qui sont tous les deux responsables du projet
libclc (http://libclc.sourceforge.net), qui beneficierait grandement
d'une contribution telle que la tienne.
Maintenant, pour les remarques techniques, il faut d'abord que je jette
un coup d'oeil a ton code ;-)
Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Augestad (boa at metasystems dot no) ou Hallvard Furuseth (h.b.furuseth
at usit dot uio dot no), qui sont tous les deux responsables du projet
libclc (http://libclc.sourceforge.net), qui beneficierait grandement
d'une contribution telle que la tienne.
Maintenant, pour les remarques techniques, il faut d'abord que je jette
un coup d'oeil a ton code ;-)
Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Augestad (boa at metasystems dot no) ou Hallvard Furuseth (h.b.furuseth
at usit dot uio dot no), qui sont tous les deux responsables du projet
libclc (http://libclc.sourceforge.net), qui beneficierait grandement
d'une contribution telle que la tienne.
Maintenant, pour les remarques techniques, il faut d'abord que je jette
un coup d'oeil a ton code ;-)
Bertrand Mollinier Toublet wrote:Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Augestad (boa at metasystems dot no) ou Hallvard Furuseth (h.b.furuseth
at usit dot uio dot no), qui sont tous les deux responsables du projet
libclc (http://libclc.sourceforge.net), qui beneficierait grandement
d'une contribution telle que la tienne.
J'ai noté l'URL, j'ai jeté un coup d'oeil.
J'ai pour le moment du mal avec le modèle de développement,
et entre autre le copyright (orienté GPL) dont je ne sais
pas si mon employeur sera très content.
Problemes de copyright mis-a-part, qu'est ce qui te gene avec le modele
Maintenant, pour les remarques techniques, il faut d'abord que je jette
un coup d'oeil a ton code ;-)
J'avoue que je suis surtout demandeur de remarque "utilisateur",
ie en tant que développeur, serais-tu intéressé par utiliser
cette librairie (si elle dépassait le stade du prototype).
Apres lecture de ta doc, et jeter un petit coup d'oeil aux contraintes,
Bertrand Mollinier Toublet wrote:
Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Augestad (boa at metasystems dot no) ou Hallvard Furuseth (h.b.furuseth
at usit dot uio dot no), qui sont tous les deux responsables du projet
libclc (http://libclc.sourceforge.net), qui beneficierait grandement
d'une contribution telle que la tienne.
J'ai noté l'URL, j'ai jeté un coup d'oeil.
J'ai pour le moment du mal avec le modèle de développement,
et entre autre le copyright (orienté GPL) dont je ne sais
pas si mon employeur sera très content.
Problemes de copyright mis-a-part, qu'est ce qui te gene avec le modele
Maintenant, pour les remarques techniques, il faut d'abord que je jette
un coup d'oeil a ton code ;-)
J'avoue que je suis surtout demandeur de remarque "utilisateur",
ie en tant que développeur, serais-tu intéressé par utiliser
cette librairie (si elle dépassait le stade du prototype).
Apres lecture de ta doc, et jeter un petit coup d'oeil aux contraintes,
Bertrand Mollinier Toublet wrote:Perso, mon avis, je te l'ai deja donne, c'est que tu contactes Bjorn
Augestad (boa at metasystems dot no) ou Hallvard Furuseth (h.b.furuseth
at usit dot uio dot no), qui sont tous les deux responsables du projet
libclc (http://libclc.sourceforge.net), qui beneficierait grandement
d'une contribution telle que la tienne.
J'ai noté l'URL, j'ai jeté un coup d'oeil.
J'ai pour le moment du mal avec le modèle de développement,
et entre autre le copyright (orienté GPL) dont je ne sais
pas si mon employeur sera très content.
Problemes de copyright mis-a-part, qu'est ce qui te gene avec le modele
Maintenant, pour les remarques techniques, il faut d'abord que je jette
un coup d'oeil a ton code ;-)
J'avoue que je suis surtout demandeur de remarque "utilisateur",
ie en tant que développeur, serais-tu intéressé par utiliser
cette librairie (si elle dépassait le stade du prototype).
Apres lecture de ta doc, et jeter un petit coup d'oeil aux contraintes,
Sans ressasser tout les debats autour du developpement d'un conteneur
generique, aujourd'hui, je ne suis pas pret a sacrifier la facilite de
compilation et d'ecriture pour avoir un type checking pris en charge par
le langage (plutot que ma responsabilite), et une eventuelle
optimisation du code.
Sans ressasser tout les debats autour du developpement d'un conteneur
generique, aujourd'hui, je ne suis pas pret a sacrifier la facilite de
compilation et d'ecriture pour avoir un type checking pris en charge par
le langage (plutot que ma responsabilite), et une eventuelle
optimisation du code.
Sans ressasser tout les debats autour du developpement d'un conteneur
generique, aujourd'hui, je ne suis pas pret a sacrifier la facilite de
compilation et d'ecriture pour avoir un type checking pris en charge par
le langage (plutot que ma responsabilite), et une eventuelle
optimisation du code.
Marc Boyer wrote:
Au dernieres nouvelles, la licence de libclc n'a rien a voir avec GPL...
Mais alors rien puisque c'est une license BSD, qui ne t'oblige a pas
grand chose...
En quoi ca generai ton entreprise?
Marc Boyer wrote:
Au dernieres nouvelles, la licence de libclc n'a rien a voir avec GPL...
Mais alors rien puisque c'est une license BSD, qui ne t'oblige a pas
grand chose...
En quoi ca generai ton entreprise?
Marc Boyer wrote:
Au dernieres nouvelles, la licence de libclc n'a rien a voir avec GPL...
Mais alors rien puisque c'est une license BSD, qui ne t'oblige a pas
grand chose...
En quoi ca generai ton entreprise?
Bertrand Mollinier Toublet wrote:Marc Boyer wrote:Bertrand Mollinier Toublet wrote:
Problemes de copyright mis-a-part, qu'est ce qui te gene avec le modele
de developpement ? Si c'est le manque de contributeurs, il ne tient qu'a
toi de faire changer ca ;-)
Le fait de devoir faire valider toutes les orientations sur clc,
ça donne pas lieu à d'interminables discussions ?
Oui, comme disait Richard Heathfield sur c.l.c en reponse a une remarque
Apres lecture de ta doc, et jeter un petit coup d'oeil aux contraintes,
je dirais non.
Desole, mais autant la solution technique adoptee m'est relativement
indifferente, autant l'interface que tu proposes, les contraintes pour
la compilation (sed ? option de gcc ? inclure sans inclure tout en
incluant ?) me refroidissent un petit peu.
C'est peut-être une erreur de présentation de ma part.
La solution "standart", c'est d'avoir un fichier qui recense
les instanciations courantes.
#ifdef VECTOR_INT
#include "VectorInt.h"
#else
#ifdef VECTOR_STRING
#include "VectorInt.h"
#endif
#endif
C'est rédibitoire à ton avis ?
En comparaison d'autres solutions, un petit peu, oui. Pour etre honnete,
Sans ressasser tout les debats autour du developpement d'un conteneur
generique, aujourd'hui, je ne suis pas pret a sacrifier la facilite de
compilation et d'ecriture pour avoir un type checking pris en charge par
le langage (plutot que ma responsabilite), et une eventuelle
optimisation du code.
Ben, c'est bien le coeur du problème.
Y a-t-il une demande pour une telle solution ? Passer plusieurs
semaines à écrires quelques milliers de lignes de codes qui ne
seront jamais utilisée, cela ne me tente pas trop.
Note que mon opinion est a prendre avec une pincee de sel. Je suis tout
Bertrand Mollinier Toublet wrote:
Marc Boyer wrote:
Bertrand Mollinier Toublet wrote:
Problemes de copyright mis-a-part, qu'est ce qui te gene avec le modele
de developpement ? Si c'est le manque de contributeurs, il ne tient qu'a
toi de faire changer ca ;-)
Le fait de devoir faire valider toutes les orientations sur clc,
ça donne pas lieu à d'interminables discussions ?
Oui, comme disait Richard Heathfield sur c.l.c en reponse a une remarque
Apres lecture de ta doc, et jeter un petit coup d'oeil aux contraintes,
je dirais non.
Desole, mais autant la solution technique adoptee m'est relativement
indifferente, autant l'interface que tu proposes, les contraintes pour
la compilation (sed ? option de gcc ? inclure sans inclure tout en
incluant ?) me refroidissent un petit peu.
C'est peut-être une erreur de présentation de ma part.
La solution "standart", c'est d'avoir un fichier qui recense
les instanciations courantes.
#ifdef VECTOR_INT
#include "VectorInt.h"
#else
#ifdef VECTOR_STRING
#include "VectorInt.h"
#endif
#endif
C'est rédibitoire à ton avis ?
En comparaison d'autres solutions, un petit peu, oui. Pour etre honnete,
Sans ressasser tout les debats autour du developpement d'un conteneur
generique, aujourd'hui, je ne suis pas pret a sacrifier la facilite de
compilation et d'ecriture pour avoir un type checking pris en charge par
le langage (plutot que ma responsabilite), et une eventuelle
optimisation du code.
Ben, c'est bien le coeur du problème.
Y a-t-il une demande pour une telle solution ? Passer plusieurs
semaines à écrires quelques milliers de lignes de codes qui ne
seront jamais utilisée, cela ne me tente pas trop.
Note que mon opinion est a prendre avec une pincee de sel. Je suis tout
Bertrand Mollinier Toublet wrote:Marc Boyer wrote:Bertrand Mollinier Toublet wrote:
Problemes de copyright mis-a-part, qu'est ce qui te gene avec le modele
de developpement ? Si c'est le manque de contributeurs, il ne tient qu'a
toi de faire changer ca ;-)
Le fait de devoir faire valider toutes les orientations sur clc,
ça donne pas lieu à d'interminables discussions ?
Oui, comme disait Richard Heathfield sur c.l.c en reponse a une remarque
Apres lecture de ta doc, et jeter un petit coup d'oeil aux contraintes,
je dirais non.
Desole, mais autant la solution technique adoptee m'est relativement
indifferente, autant l'interface que tu proposes, les contraintes pour
la compilation (sed ? option de gcc ? inclure sans inclure tout en
incluant ?) me refroidissent un petit peu.
C'est peut-être une erreur de présentation de ma part.
La solution "standart", c'est d'avoir un fichier qui recense
les instanciations courantes.
#ifdef VECTOR_INT
#include "VectorInt.h"
#else
#ifdef VECTOR_STRING
#include "VectorInt.h"
#endif
#endif
C'est rédibitoire à ton avis ?
En comparaison d'autres solutions, un petit peu, oui. Pour etre honnete,
Sans ressasser tout les debats autour du developpement d'un conteneur
generique, aujourd'hui, je ne suis pas pret a sacrifier la facilite de
compilation et d'ecriture pour avoir un type checking pris en charge par
le langage (plutot que ma responsabilite), et une eventuelle
optimisation du code.
Ben, c'est bien le coeur du problème.
Y a-t-il une demande pour une telle solution ? Passer plusieurs
semaines à écrires quelques milliers de lignes de codes qui ne
seront jamais utilisée, cela ne me tente pas trop.
Note que mon opinion est a prendre avec une pincee de sel. Je suis tout
Le fait de devoir faire valider toutes les orientations sur clc,
ça donne pas lieu à d'interminables discussions ?
Oui, comme disait Richard Heathfield sur c.l.c en reponse a une remarque
similaire de ma part (quoi, qui a dit "proselytisme" ?): le terme
colletif pour "programeur" est "conflits" :-)
En comparaison d'autres solutions, un petit peu, oui. Pour etre honnete,
je ne suis pas un grand fan du preprocesseur.
Ben, c'est bien le coeur du problème.
Y a-t-il une demande pour une telle solution ? Passer plusieurs
semaines à écrires quelques milliers de lignes de codes qui ne
seront jamais utilisée, cela ne me tente pas trop.
Note que mon opinion est a prendre avec une pincee de sel. Je suis tout
au plus un amateur interesse, pas du tout un professionel du langage,
et mon experience en developpement en C de niveau industriel est d'un an
seulement...
Le fait de devoir faire valider toutes les orientations sur clc,
ça donne pas lieu à d'interminables discussions ?
Oui, comme disait Richard Heathfield sur c.l.c en reponse a une remarque
similaire de ma part (quoi, qui a dit "proselytisme" ?): le terme
colletif pour "programeur" est "conflits" :-)
En comparaison d'autres solutions, un petit peu, oui. Pour etre honnete,
je ne suis pas un grand fan du preprocesseur.
Ben, c'est bien le coeur du problème.
Y a-t-il une demande pour une telle solution ? Passer plusieurs
semaines à écrires quelques milliers de lignes de codes qui ne
seront jamais utilisée, cela ne me tente pas trop.
Note que mon opinion est a prendre avec une pincee de sel. Je suis tout
au plus un amateur interesse, pas du tout un professionel du langage,
et mon experience en developpement en C de niveau industriel est d'un an
seulement...
Le fait de devoir faire valider toutes les orientations sur clc,
ça donne pas lieu à d'interminables discussions ?
Oui, comme disait Richard Heathfield sur c.l.c en reponse a une remarque
similaire de ma part (quoi, qui a dit "proselytisme" ?): le terme
colletif pour "programeur" est "conflits" :-)
En comparaison d'autres solutions, un petit peu, oui. Pour etre honnete,
je ne suis pas un grand fan du preprocesseur.
Ben, c'est bien le coeur du problème.
Y a-t-il une demande pour une telle solution ? Passer plusieurs
semaines à écrires quelques milliers de lignes de codes qui ne
seront jamais utilisée, cela ne me tente pas trop.
Note que mon opinion est a prendre avec une pincee de sel. Je suis tout
au plus un amateur interesse, pas du tout un professionel du langage,
et mon experience en developpement en C de niveau industriel est d'un an
seulement...
On 30 Jun 2003 13:05:27 GMT, Marc Boyer
wrote:
Apres avoir jeté une rapide coup d'oeil, il apparait certaines choses
qui peuvent etre genantes :
"Notice that, from the BPL point of view, a constructor should never
fail. "
ou encore dans VectorString.h
--
#include <string.h>
[...]
#define COPY_TYPE(X,Y) (free(X),(X)=strdup(Y))
--
Si l'on passe que strdup n'est pas standard, elle peut en outre
echouer.
Bien sur, tu préconises dans la doc l'utilisation des exceptions
(d'ailleurs je suis sur que tu ne manqueras pas de remplacer bientot
ce strdup par une fonction de ta fabrication).
Par ailleurs, en
regardant un peu l'interface, je vois que tu proposes malgré tout une
gestion d'erreur, mais pas sous forme d'exceptions, sous forme de
valeurs de retour simples.
Donc je suppose que c'est par facilité que tu as choisi de ne pas
traiter les erreur d'echec de construction :
bool INST(initWithSize)(Vector* item, size_t size){
item->start= malloc( size * sizeof(Type));
if ( item->start ) {
size_t i;
item->size = item->reserved = size;
for(i = 0; i < size ; ++i ){
INIT_TYPE(item->start[i]);
}
typeInvariant(*item);
return true;
} else {
item->size = item->reserved = 0;
typeInvariant(*item);
return false;
}
}
Une gestion d'erreur eut été simple a mettre en place il me semble.
Pour gérer ca, je pense qu'il faudrait rajouter une macro permettant
de savoir si telle operation a échoué, par exemple pour des strings :
#define COPY_TYPE(X,Y) (free(X),(X)=strdup(Y))
#define COPY_HAS_FAILED(X) ((X)==NULL)
Bon, en y ayant refléchi 5 minutes c'est ce que je ferais (il y a
peut-être des choses à revoir/améliorer dans ma solution).
Cela dit, il serait peut etre interessant que ta librairie propose
comme tu le suggere dans la doc un gestion des exceptions complete, et
qui soit utilisable pour les types gérés l'utilisateur :
En effet, si par exemple la fonction de copie devait lever une
exception, tu pourrais definir un exception standard (genre
CopyFailureException), qui serait attrapée et gérée pour libérer
eventuellement les ressources puis re-levée pour l'utilisateur.
(Mais bon je vais pas t'apprendre la POO non plus, tu est très
certainement bien plus savant que moi dans ce domaine, après tout je
ne suis qu'un "Padawan").
Suite a plusieurs threads sur la généricité et les types sur fclc,
j'avais moi aussi décidé d'écrire une bibliotheque de structures de
données génériques (et plein d'autres choses utiles, une sorte de
compilation de plein de choses utiles et que l'on peut ecrire en C
portable) et cette vision la (utiliser des macros pour utiliser le
typage "fort" du C) me plait bien. Cela dit, j'ai structuré ma
bibliotheque de maniere différente de ta BPL, plutot comme Java, avec
des "interfaces", qui pourront etre implémentees de maniere différente
par des structures de plus bas niveau, mais le tout sans besoin
d'exceptions (j'ai choisi mon camp camarade ;-)). J'ai deja établi une
partie de l'interface des types proposés pour la premiere version,
j'ai aussi ma gestion d'erreurs et mes conventions de nommage (ca m'a
pris un petit bout de temps deja). Il se pourrait cependant que je
reprenne une partie des astuces de ta technique de compilation s'il
s'avere que c'est ce que je recherche (j'espere que tu ne m'en voudras
pas trop :)). Si j'arrive à la finir un jour (pour l'instant je doit
en être a 15% de la premiere version release que je souhaiterais), je
l'utiliserais sans doute pour mon prochain "gros projet" (une
modification de jeu, mais je suis meme pas encore sur de la faire). Je
le fais aussi pour essayer de voir un peu ce que je vaut en C. En tout
cas si je mene ca a bien je manquerais pas de le faire partager comme
tu l'a fait avec ta BPL.
Donc mon impression finale, c'est que c'est du bon taf a priori que
cette BPL, meme s'il y a encore pas mal d'améliorations a apporter je
pense. Sur ce, je retourne finir de lire la doc et fouiner le code...
On 30 Jun 2003 13:05:27 GMT, Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr>
wrote:
Apres avoir jeté une rapide coup d'oeil, il apparait certaines choses
qui peuvent etre genantes :
"Notice that, from the BPL point of view, a constructor should never
fail. "
ou encore dans VectorString.h
--
#include <string.h>
[...]
#define COPY_TYPE(X,Y) (free(X),(X)=strdup(Y))
--
Si l'on passe que strdup n'est pas standard, elle peut en outre
echouer.
Bien sur, tu préconises dans la doc l'utilisation des exceptions
(d'ailleurs je suis sur que tu ne manqueras pas de remplacer bientot
ce strdup par une fonction de ta fabrication).
Par ailleurs, en
regardant un peu l'interface, je vois que tu proposes malgré tout une
gestion d'erreur, mais pas sous forme d'exceptions, sous forme de
valeurs de retour simples.
Donc je suppose que c'est par facilité que tu as choisi de ne pas
traiter les erreur d'echec de construction :
bool INST(initWithSize)(Vector* item, size_t size){
item->start= malloc( size * sizeof(Type));
if ( item->start ) {
size_t i;
item->size = item->reserved = size;
for(i = 0; i < size ; ++i ){
INIT_TYPE(item->start[i]);
}
typeInvariant(*item);
return true;
} else {
item->size = item->reserved = 0;
typeInvariant(*item);
return false;
}
}
Une gestion d'erreur eut été simple a mettre en place il me semble.
Pour gérer ca, je pense qu'il faudrait rajouter une macro permettant
de savoir si telle operation a échoué, par exemple pour des strings :
#define COPY_TYPE(X,Y) (free(X),(X)=strdup(Y))
#define COPY_HAS_FAILED(X) ((X)==NULL)
Bon, en y ayant refléchi 5 minutes c'est ce que je ferais (il y a
peut-être des choses à revoir/améliorer dans ma solution).
Cela dit, il serait peut etre interessant que ta librairie propose
comme tu le suggere dans la doc un gestion des exceptions complete, et
qui soit utilisable pour les types gérés l'utilisateur :
En effet, si par exemple la fonction de copie devait lever une
exception, tu pourrais definir un exception standard (genre
CopyFailureException), qui serait attrapée et gérée pour libérer
eventuellement les ressources puis re-levée pour l'utilisateur.
(Mais bon je vais pas t'apprendre la POO non plus, tu est très
certainement bien plus savant que moi dans ce domaine, après tout je
ne suis qu'un "Padawan").
Suite a plusieurs threads sur la généricité et les types sur fclc,
j'avais moi aussi décidé d'écrire une bibliotheque de structures de
données génériques (et plein d'autres choses utiles, une sorte de
compilation de plein de choses utiles et que l'on peut ecrire en C
portable) et cette vision la (utiliser des macros pour utiliser le
typage "fort" du C) me plait bien. Cela dit, j'ai structuré ma
bibliotheque de maniere différente de ta BPL, plutot comme Java, avec
des "interfaces", qui pourront etre implémentees de maniere différente
par des structures de plus bas niveau, mais le tout sans besoin
d'exceptions (j'ai choisi mon camp camarade ;-)). J'ai deja établi une
partie de l'interface des types proposés pour la premiere version,
j'ai aussi ma gestion d'erreurs et mes conventions de nommage (ca m'a
pris un petit bout de temps deja). Il se pourrait cependant que je
reprenne une partie des astuces de ta technique de compilation s'il
s'avere que c'est ce que je recherche (j'espere que tu ne m'en voudras
pas trop :)). Si j'arrive à la finir un jour (pour l'instant je doit
en être a 15% de la premiere version release que je souhaiterais), je
l'utiliserais sans doute pour mon prochain "gros projet" (une
modification de jeu, mais je suis meme pas encore sur de la faire). Je
le fais aussi pour essayer de voir un peu ce que je vaut en C. En tout
cas si je mene ca a bien je manquerais pas de le faire partager comme
tu l'a fait avec ta BPL.
Donc mon impression finale, c'est que c'est du bon taf a priori que
cette BPL, meme s'il y a encore pas mal d'améliorations a apporter je
pense. Sur ce, je retourne finir de lire la doc et fouiner le code...
On 30 Jun 2003 13:05:27 GMT, Marc Boyer
wrote:
Apres avoir jeté une rapide coup d'oeil, il apparait certaines choses
qui peuvent etre genantes :
"Notice that, from the BPL point of view, a constructor should never
fail. "
ou encore dans VectorString.h
--
#include <string.h>
[...]
#define COPY_TYPE(X,Y) (free(X),(X)=strdup(Y))
--
Si l'on passe que strdup n'est pas standard, elle peut en outre
echouer.
Bien sur, tu préconises dans la doc l'utilisation des exceptions
(d'ailleurs je suis sur que tu ne manqueras pas de remplacer bientot
ce strdup par une fonction de ta fabrication).
Par ailleurs, en
regardant un peu l'interface, je vois que tu proposes malgré tout une
gestion d'erreur, mais pas sous forme d'exceptions, sous forme de
valeurs de retour simples.
Donc je suppose que c'est par facilité que tu as choisi de ne pas
traiter les erreur d'echec de construction :
bool INST(initWithSize)(Vector* item, size_t size){
item->start= malloc( size * sizeof(Type));
if ( item->start ) {
size_t i;
item->size = item->reserved = size;
for(i = 0; i < size ; ++i ){
INIT_TYPE(item->start[i]);
}
typeInvariant(*item);
return true;
} else {
item->size = item->reserved = 0;
typeInvariant(*item);
return false;
}
}
Une gestion d'erreur eut été simple a mettre en place il me semble.
Pour gérer ca, je pense qu'il faudrait rajouter une macro permettant
de savoir si telle operation a échoué, par exemple pour des strings :
#define COPY_TYPE(X,Y) (free(X),(X)=strdup(Y))
#define COPY_HAS_FAILED(X) ((X)==NULL)
Bon, en y ayant refléchi 5 minutes c'est ce que je ferais (il y a
peut-être des choses à revoir/améliorer dans ma solution).
Cela dit, il serait peut etre interessant que ta librairie propose
comme tu le suggere dans la doc un gestion des exceptions complete, et
qui soit utilisable pour les types gérés l'utilisateur :
En effet, si par exemple la fonction de copie devait lever une
exception, tu pourrais definir un exception standard (genre
CopyFailureException), qui serait attrapée et gérée pour libérer
eventuellement les ressources puis re-levée pour l'utilisateur.
(Mais bon je vais pas t'apprendre la POO non plus, tu est très
certainement bien plus savant que moi dans ce domaine, après tout je
ne suis qu'un "Padawan").
Suite a plusieurs threads sur la généricité et les types sur fclc,
j'avais moi aussi décidé d'écrire une bibliotheque de structures de
données génériques (et plein d'autres choses utiles, une sorte de
compilation de plein de choses utiles et que l'on peut ecrire en C
portable) et cette vision la (utiliser des macros pour utiliser le
typage "fort" du C) me plait bien. Cela dit, j'ai structuré ma
bibliotheque de maniere différente de ta BPL, plutot comme Java, avec
des "interfaces", qui pourront etre implémentees de maniere différente
par des structures de plus bas niveau, mais le tout sans besoin
d'exceptions (j'ai choisi mon camp camarade ;-)). J'ai deja établi une
partie de l'interface des types proposés pour la premiere version,
j'ai aussi ma gestion d'erreurs et mes conventions de nommage (ca m'a
pris un petit bout de temps deja). Il se pourrait cependant que je
reprenne une partie des astuces de ta technique de compilation s'il
s'avere que c'est ce que je recherche (j'espere que tu ne m'en voudras
pas trop :)). Si j'arrive à la finir un jour (pour l'instant je doit
en être a 15% de la premiere version release que je souhaiterais), je
l'utiliserais sans doute pour mon prochain "gros projet" (une
modification de jeu, mais je suis meme pas encore sur de la faire). Je
le fais aussi pour essayer de voir un peu ce que je vaut en C. En tout
cas si je mene ca a bien je manquerais pas de le faire partager comme
tu l'a fait avec ta BPL.
Donc mon impression finale, c'est que c'est du bon taf a priori que
cette BPL, meme s'il y a encore pas mal d'améliorations a apporter je
pense. Sur ce, je retourne finir de lire la doc et fouiner le code...
In 'fr.comp.lang.c', Marc Boyer wrote:Je m'adresse plus à des gens qui font du C procédural
"classique", qui manipulent déjà des listes à coup de
macros qui castent tout en void*.
void* est indispensabple pour faire de la programmation générique. Même
l'idiome:
typedef struct obj obj_s;
<...>
obj_s *p_obj;
definit en fait un
void *p_obj;
sans le dire. Ca fait partie du langage.
La, il va falloir que tu clarifies, parce que j'ai pas suivi.
In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Je m'adresse plus à des gens qui font du C procédural
"classique", qui manipulent déjà des listes à coup de
macros qui castent tout en void*.
void* est indispensabple pour faire de la programmation générique. Même
l'idiome:
typedef struct obj obj_s;
<...>
obj_s *p_obj;
definit en fait un
void *p_obj;
sans le dire. Ca fait partie du langage.
La, il va falloir que tu clarifies, parce que j'ai pas suivi.
In 'fr.comp.lang.c', Marc Boyer wrote:Je m'adresse plus à des gens qui font du C procédural
"classique", qui manipulent déjà des listes à coup de
macros qui castent tout en void*.
void* est indispensabple pour faire de la programmation générique. Même
l'idiome:
typedef struct obj obj_s;
<...>
obj_s *p_obj;
definit en fait un
void *p_obj;
sans le dire. Ca fait partie du langage.
La, il va falloir que tu clarifies, parce que j'ai pas suivi.
