Bonjour à tous,

Je vous présente une toute petite bibliothèque que j'ai écrit hier et qui ne sers à rien, comme la plupart des choses que je produit. J'ai nommé C_EXN (nom provisoire), qui permet d'ajouter la gestion d'exception au langage C, et cela, de manière assez propre, même si c'est forcément limité.

Elle est écrite en pur C89 et donc doit compiler avec gcc quels que soit les paramètres de langage (malheureusement j'utilise quelques annotations pour le compilo donc ça ne fonctionnera pas avec un autre compilateur, mais ça ne doit pas demander grand chose pour être porté vers un autre compilo).

J'ai mis une archive qui contient la bibliothèque, et un petit programme d'exemple avec une description de comment utiliser les exceptions sur le net :
http://repository.sectionpc.info/C/c_exn.tgz

C'est très préliminaire et pas beaucoup testé, mais si vous pouviez jeter un coup d'oeil et me dire ce que vous en pensez (particulièrement si vous y trouvez des bogues) j'apprécierais.

merci.

P.S. je suis dans une phase "je n'aime pas le C++ mais je trouve le C un peu limité ...", mais ça devrait me passer dans pas trop longtemps, ne vous inquiétez pas.

bien bien bien, tres interessant ça pour ceux qui sont dans une phase "j'adore le C et le C++ m'ennuie meme si la POO c'est mieu" depuis 3 ans.

une question me chatouille tout de meme.
Je ne peux pas tester maintenant sinon j'aurais pu verifier tout seul. Est-il possible pour une fonction de faire appel a throw(....) sans etre dans un try-catch Si elle est appelé dans un bloc contenu lui meme (a un niveau au dessus) dans un try-catch ?

genre :

int f() {
_// tout le bouzin de la fonction f
_throw(int , 5);
_return 0;
}

int f2() {
_// les petites affaires de f2()
_int resultat = f();
_return resultat;
}

int main(){

try{
_f2();
} with{
_catch(int, a) {
__printf("%d", a);
_}
}
return 0;
}

=============================
en gros pouvoir faire utiliser throw() sans etre directement dans un bloc try-catch .

J'ai pas regardé le code qui aurait certainement répondu a ma question. Tu fais ca avec setjmp, lngjmp ?

Réponse : oui et oui.
On peut faire un throw de n'importe où. Même dans un morceau de code qui
n'est pas protégé par un bloc try. Auquel cas la bibliothèque récupère
l'exception et arrète le programme.
Et oui, c'est bien à base de setjmp/longjmp. D'ailleurs je pense que de
véritable gestionnaire d'exceptions le sont aussi non ?

ok, merci dnoob700.

Je vais integrer ça à mon projet courant.
Tu dis que c'est du code orienté vers gcc. Je bosse en ce moment sur un prog pour psp, donc c'est un compilo gcc pour une archi differente, ça change quelque chose ?

Je reviendrais apres l'avoir utilisé pour te dire si j'ai croisé des bugs.

apres m'etre renseigné un peu sur setjmp, j'ai un doute.

Qu'arrive t-il aux zones mémoire allouée dans un bloc protégé qui renverait une exception si les seuls pointeurs sur cette zone se trouvent dans ce bloc ?
j'imagine que l'on peut faire une croix dessus...

Mais si c'est le cas, comment des langages, comme le C++, qui ne possedent pas de ramasse miettes font-ils pour s'affranchir de ce problème ?

non, si c'est gcc, ça doit fonctionner sans problème.

Mais ce que j'ai uploader est une première version. Je vais faire quelques petites modifications dans les prochains jours.
D'une par je veux rajouter des "handler" pour gérer des exceptions (ça c'est déjà fait) qui sont appelé automatiquement, et d'autre part je ne désespère pas de réussir à gérer un bloc finally qui soit optionnel (et si je peut rendre le bloc with optionnel aussi je serais content).

Et ça répond à ta question. Si j'arrive à implémenter des blocs finally, ça permet de détruire comme il faut les pointeur en question.

En C++ les pointeurs sont perdu aussi si tu ne fait pas attention. Il n'y a pas cette construction finally (qu'on trouve dans le java par exemple) mais par contre les variable alloué statiquement sont proprement désallouée automatiquement. Si tu veux détruire une variable alloué avec new, tu peut écrire une classe comme ça :
template<class T> class destructor{
public:
destructor(T* t) { p = t; }
~destructor() {delete p;}
private:
T* p;
};

Et à chaque fois que tu fais un new, tu peut initialiser un destructor avec ce pointeur, comme ça si il y a une exception qui se produit, le pointeur est désalloué. Bien sûr il faut un mécanisme pour détruire le destructor mais pas son pointeur, etc.

Il y a d'ailleurs des auto_ptr en C++ (et boost implémente des truc plus perfectionné) qui ont aussi ce genre de rôle, mais je ne connais pas trop.

Donc ça peut être fait en C++, et je vais essayer de faire en sorte que ça puisse être fait aussi avec ma bibliothèque.

P.S. sur un tout petit benchmark (trop superficiel pour être valable), j'ai l'impression que mes exceptions sont beaucoup (genre 20 fois) plus rapide que celles du C++. Mais bien sûr, il n'y a pas toute la couche objet à gérer.

hop, c'est bon, j'ai trouvé comment implémenter correctement un bloc finally optionnel. Et en prime les blocs catch vont l'être aussi, et il n'y aura plus besoin du bloc with !

Je me suis inspiré de ce qui existait déjà sur le net. Par exemple ça : http://www.nicemice.net/cexcept/ (qui liste d'autre bibliothèques à la fin). Mais, il n'y a pas à dire, je trouve ma bibliothèque plus simple à utiliser et elle offre(ira) plus de possibilité.

merci pour cette réponse plutot complete

je suis fan des exception à la java (en fait je ne connais pas la syntaxe du C++)
le try-with me rappelle plus l'Ocaml avec ses matches-with et du coup ça me perturbe un chouilla.

Bon et bien j'attend avec impatience la prochaine version.

Super boulot

effectivement, c'est ocaml qui m'a inspiré le with.

http://repository.sectionpc.info/C/cexn.tar.gz

Voila une version corrigée, plus simple, avec une syntaxe plus souple, plus de fonctionnalités, etc.

Il y a une petite documentation dans l'archive avec des fichiers exemples et tout ce qu'il faut.

J'ai rajoutté le bloc finally comme promis, qui permet de désallouer des pointeurs avant de sortir d'une fonction (même si l'exception vient d'ailleurs), et tout les blocs sont optionnel maintenant.

J'aimerais bien rendre optionnel aussi les mots clef rethrow et catchall à la fin du block with (qui est lui aussi optionnel), mais dans ce cas là, dois perdre la compatibilité C89. Je ne sais pas ce qui est mieux.