// une classe simple
class B {
public:
B(int j) : k(j) {}
inline void run () {
throw Excp("exception imprévue dans le run");
}
virtual ~B () { throw Excp("Bad B"); }
private:
int k;
};
Je comprend que l'exception déclenchée dans b.run() provoque la sortie
du bloc et donc la destruction de l'objet b. Une nouvelle exception est
alors levée. Je pensais que mes try/catch résolverais le problème, mais
ce n'est pas le cas. J'ai un message
Executable tests has exited due to signal 6 (SIGABRT).
Et rien d'autre. C'est un vrai plantage. Si je supprime l'un des deux
throw, j'ai le résultat attendu.
J'utilise gcc 3.3 sur MacOS 10.3.5.
Est-ce que quelqu'un a des explications ? Je sais comment m'en dépétrer,
ce qui m'intéresse c'est le pourquoi du comment.
| drkm wrote: | > Jean-Marc Bourguet writes: | [...] | > J'imagine qu'il y a quelque chose comme un stockage de | > l'instantiation dans une des TUs traduites. Il devrait être facile | > d'utiliser à la place une sorte de repository pour ne plus du tout | > avoir besoin des sources des TUs utilisatrices. | | "Facile" est un concepte relatif ;-) Mais, oui c'est possible. | En fait, le produit C++ d'EDG peut etre configure pour | generer les instantiations dans des fichiers objets separes.
Je crois que le modèle « repository » (pre-norme) était (est toujours ?) utilisé par Sun CC -- c'est avec ce compilateur que j'ai été « initié » à la « compilation séparée » des templates. il y a bientôt une décennie.
G++ a une option « -frepo » -- je n'ai jamais compris comment cela marchait.
| drkm <usenet.fclcxx@fgeorges.org> wrote:
| > Jean-Marc Bourguet <jm@bourguet.org> writes:
| [...]
| > J'imagine qu'il y a quelque chose comme un stockage de
| > l'instantiation dans une des TUs traduites. Il devrait être facile
| > d'utiliser à la place une sorte de repository pour ne plus du tout
| > avoir besoin des sources des TUs utilisatrices.
|
| "Facile" est un concepte relatif ;-) Mais, oui c'est possible.
| En fait, le produit C++ d'EDG peut etre configure pour
| generer les instantiations dans des fichiers objets separes.
Je crois que le modèle « repository » (pre-norme) était (est
toujours ?) utilisé par Sun CC -- c'est avec ce compilateur que j'ai
été « initié » à la « compilation séparée » des templates. il y a
bientôt une décennie.
G++ a une option « -frepo » -- je n'ai jamais compris comment cela
marchait.
| drkm wrote: | > Jean-Marc Bourguet writes: | [...] | > J'imagine qu'il y a quelque chose comme un stockage de | > l'instantiation dans une des TUs traduites. Il devrait être facile | > d'utiliser à la place une sorte de repository pour ne plus du tout | > avoir besoin des sources des TUs utilisatrices. | | "Facile" est un concepte relatif ;-) Mais, oui c'est possible. | En fait, le produit C++ d'EDG peut etre configure pour | generer les instantiations dans des fichiers objets separes.
Je crois que le modèle « repository » (pre-norme) était (est toujours ?) utilisé par Sun CC -- c'est avec ce compilateur que j'ai été « initié » à la « compilation séparée » des templates. il y a bientôt une décennie.
G++ a une option « -frepo » -- je n'ai jamais compris comment cela marchait.
-- Gaby
drkm
Gabriel Dos Reis writes:
G++ a une option « -frepo » -- je n'ai jamais compris comment cela marchait.
Je me sens moins seul ;-)
--drkm
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
G++ a une option « -frepo » -- je n'ai jamais compris comment cela
marchait.
G++ a une option « -frepo » -- je n'ai jamais compris comment cela marchait.
Je me sens moins seul ;-)
--drkm
Jean-Marc Bourguet
Gabriel Dos Reis writes:
(Daveed Vandevoorde) writes:
| drkm wrote: | > Jean-Marc Bourguet writes: | [...] | > J'imagine qu'il y a quelque chose comme un stockage de | > l'instantiation dans une des TUs traduites. Il devrait être facile | > d'utiliser à la place une sorte de repository pour ne plus du tout | > avoir besoin des sources des TUs utilisatrices. | | "Facile" est un concepte relatif ;-) Mais, oui c'est possible. | En fait, le produit C++ d'EDG peut etre configure pour | generer les instantiations dans des fichiers objets separes.
Je crois que le modèle « repository » (pre-norme) était (est toujours ?) utilisé par Sun CC
SunCC a toujours son modele. Il permet aussi depuis une ou deux versions le modele "greedy" en plus des autres modeles ne permettant pas une conformite totale qu'il permet depuis toujours (toutes les instanciations en static, etc).
Mais je crois qu'il y a une difference avec ce a quoi fait allusion David: le repository chez Sun sert a savoir quels templates instancier. Le mode d'EDG genere simplement plusieurs fichiers objets plutot qu'un seul, la decision de savoir quel template instancier se fait exactement de la meme maniere. L'avantage est pour les bibliotheques d'eviter de devoir tirer des choses inutiles simplement parce que le pre-linker a decider d'assigner une instanciation a une unite de compilation dont on a pas besoin.
G++ a une option « -frepo » -- je n'ai jamais compris comment cela marchait.
Moi non plus.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
| drkm <usenet.fclcxx@fgeorges.org> wrote:
| > Jean-Marc Bourguet <jm@bourguet.org> writes:
| [...]
| > J'imagine qu'il y a quelque chose comme un stockage de
| > l'instantiation dans une des TUs traduites. Il devrait être facile
| > d'utiliser à la place une sorte de repository pour ne plus du tout
| > avoir besoin des sources des TUs utilisatrices.
|
| "Facile" est un concepte relatif ;-) Mais, oui c'est possible.
| En fait, le produit C++ d'EDG peut etre configure pour
| generer les instantiations dans des fichiers objets separes.
Je crois que le modèle « repository » (pre-norme) était (est
toujours ?) utilisé par Sun CC
SunCC a toujours son modele. Il permet aussi depuis une ou deux
versions le modele "greedy" en plus des autres modeles ne permettant
pas une conformite totale qu'il permet depuis toujours (toutes les
instanciations en static, etc).
Mais je crois qu'il y a une difference avec ce a quoi fait allusion
David: le repository chez Sun sert a savoir quels templates
instancier. Le mode d'EDG genere simplement plusieurs fichiers objets
plutot qu'un seul, la decision de savoir quel template instancier se
fait exactement de la meme maniere. L'avantage est pour les
bibliotheques d'eviter de devoir tirer des choses inutiles simplement
parce que le pre-linker a decider d'assigner une instanciation a une
unite de compilation dont on a pas besoin.
G++ a une option « -frepo » -- je n'ai jamais compris comment cela
marchait.
Moi non plus.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
| drkm wrote: | > Jean-Marc Bourguet writes: | [...] | > J'imagine qu'il y a quelque chose comme un stockage de | > l'instantiation dans une des TUs traduites. Il devrait être facile | > d'utiliser à la place une sorte de repository pour ne plus du tout | > avoir besoin des sources des TUs utilisatrices. | | "Facile" est un concepte relatif ;-) Mais, oui c'est possible. | En fait, le produit C++ d'EDG peut etre configure pour | generer les instantiations dans des fichiers objets separes.
Je crois que le modèle « repository » (pre-norme) était (est toujours ?) utilisé par Sun CC
SunCC a toujours son modele. Il permet aussi depuis une ou deux versions le modele "greedy" en plus des autres modeles ne permettant pas une conformite totale qu'il permet depuis toujours (toutes les instanciations en static, etc).
Mais je crois qu'il y a une difference avec ce a quoi fait allusion David: le repository chez Sun sert a savoir quels templates instancier. Le mode d'EDG genere simplement plusieurs fichiers objets plutot qu'un seul, la decision de savoir quel template instancier se fait exactement de la meme maniere. L'avantage est pour les bibliotheques d'eviter de devoir tirer des choses inutiles simplement parce que le pre-linker a decider d'assigner une instanciation a une unite de compilation dont on a pas besoin.
G++ a une option « -frepo » -- je n'ai jamais compris comment cela marchait.
Moi non plus.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
google
Jean-Marc Bourguet wrote: [...]
Mais je crois qu'il y a une difference avec ce a quoi fait allusion David: le repository chez Sun sert a savoir quels templates instancier. Le mode d'EDG genere simplement plusieurs fichiers objets plutot qu'un seul, la decision de savoir quel template instancier se fait exactement de la meme maniere. L'avantage est pour les bibliotheques d'eviter de devoir tirer des choses inutiles simplement parce que le pre-linker a decider d'assigner une instanciation a une unite de compilation dont on a pas besoin.
100% exacte.
David
Jean-Marc Bourguet <jm@bourguet.org> wrote:
[...]
Mais je crois qu'il y a une difference avec ce a quoi fait allusion
David: le repository chez Sun sert a savoir quels templates
instancier. Le mode d'EDG genere simplement plusieurs fichiers objets
plutot qu'un seul, la decision de savoir quel template instancier se
fait exactement de la meme maniere. L'avantage est pour les
bibliotheques d'eviter de devoir tirer des choses inutiles simplement
parce que le pre-linker a decider d'assigner une instanciation a une
unite de compilation dont on a pas besoin.
Mais je crois qu'il y a une difference avec ce a quoi fait allusion David: le repository chez Sun sert a savoir quels templates instancier. Le mode d'EDG genere simplement plusieurs fichiers objets plutot qu'un seul, la decision de savoir quel template instancier se fait exactement de la meme maniere. L'avantage est pour les bibliotheques d'eviter de devoir tirer des choses inutiles simplement parce que le pre-linker a decider d'assigner une instanciation a une unite de compilation dont on a pas besoin.