J'essaie d'utiliser une bibliothèque écrite en C (libjpeg).
La gestion d'erreurs dans cette bibliothèque fonctionne comme suit :
on fournit une fonction "my_error_exit()", qui doit se démerder pour
arrêter le code. (La fonction par défaut appelle exit().)
Dans cette fonction, je vois deux choix possibles :
1- longjmp() (avec un setjmp() dans le code appelant)
2- throw une_exception;
Au moins sur mon compilateur (VC++ 2008), la première solution est
officiellement non gérée :
"Do not use setjmp and longjmp in C++ programs; these functions do not
support C++ object semantics."
<http://msdn.microsoft.com/en-us/library/yz2ez4as(VS.80).aspx>
Lancer une exception serait bien agréable, mais j'ai cru lire qu'il ne
fallait pas laisser se propager une exception à travers du code C.
Pour l'instant, j'ai pondu une interface en C qui contient un paquet
de fonctions de ce style :
> J'avais mis ces fonctions dans un .c, histoire de les faire > compiler par le compilateur C, et donc m'assurer que > setjmp/longjmp ne pouvait en aucun cas interférer avec > quelque objet C++ que ce soit.
Ce n'est pas suffisant. Le problème n'est pas lexical, mais dynamique. Pour illustrer:
[...]
Mais si on s'arrange pour que le longjmp ne croise pas de cadre de pile non C, alors il ne devrait pas y avoir de problème. Ta première solution est bonne. À la limite, on pourrait faire:
Exactement. On peut faire le setjmp dans une fonction C++, mais il ne faut pas ce cette fonction ait des variables sur la pipe (ou ou moins des variables avec destructeur), y compris des temporaires, ni qu'elle appelle des fonctions C++.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 8, 1:48 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Fabien LE LEZ <grams...@gramster.com> writes:
> J'avais mis ces fonctions dans un .c, histoire de les faire
> compiler par le compilateur C, et donc m'assurer que
> setjmp/longjmp ne pouvait en aucun cas interférer avec
> quelque objet C++ que ce soit.
Ce n'est pas suffisant. Le problème n'est pas lexical, mais
dynamique. Pour illustrer:
[...]
Mais si on s'arrange pour que le longjmp ne croise pas de
cadre de pile non C, alors il ne devrait pas y avoir de
problème. Ta première solution est bonne. À la limite, on
pourrait faire:
Exactement. On peut faire le setjmp dans une fonction C++, mais
il ne faut pas ce cette fonction ait des variables sur la pipe
(ou ou moins des variables avec destructeur), y compris des
temporaires, ni qu'elle appelle des fonctions C++.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
> J'avais mis ces fonctions dans un .c, histoire de les faire > compiler par le compilateur C, et donc m'assurer que > setjmp/longjmp ne pouvait en aucun cas interférer avec > quelque objet C++ que ce soit.
Ce n'est pas suffisant. Le problème n'est pas lexical, mais dynamique. Pour illustrer:
[...]
Mais si on s'arrange pour que le longjmp ne croise pas de cadre de pile non C, alors il ne devrait pas y avoir de problème. Ta première solution est bonne. À la limite, on pourrait faire:
Exactement. On peut faire le setjmp dans une fonction C++, mais il ne faut pas ce cette fonction ait des variables sur la pipe (ou ou moins des variables avec destructeur), y compris des temporaires, ni qu'elle appelle des fonctions C++.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
