Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
Le 07-03-2007, Jean-Marc Bourguet a écrit :Marc Boyer writes:
Si le véritable exemple t'intéresse, je peux te le poster.
Ca n'est pas très long (7 classes, 400 lignes, 10ko de code).
Tu peux le faire ou me l'envoyer en perso. Je ne garanti pas de reponse
rapide.
Levons une ambiguïté: en ce qui me concerne, l'explication sur
la gestion des temporaires me convient, en j'ai une solution à
base de *(new X(1)), qui crée des objets persistants.
Après, Laurent était étonné par la nature du message d'erreur et
je lui proposais le code s'il le voulait. Cela vaut aussi pour
toi.
Mais ne fait pas ça pour moi, mais uniquement pour satisfaire ta
curiosité.
Le 07-03-2007, Jean-Marc Bourguet <jm@bourguet.org> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Si le véritable exemple t'intéresse, je peux te le poster.
Ca n'est pas très long (7 classes, 400 lignes, 10ko de code).
Tu peux le faire ou me l'envoyer en perso. Je ne garanti pas de reponse
rapide.
Levons une ambiguïté: en ce qui me concerne, l'explication sur
la gestion des temporaires me convient, en j'ai une solution à
base de *(new X(1)), qui crée des objets persistants.
Après, Laurent était étonné par la nature du message d'erreur et
je lui proposais le code s'il le voulait. Cela vaut aussi pour
toi.
Mais ne fait pas ça pour moi, mais uniquement pour satisfaire ta
curiosité.
Le 07-03-2007, Jean-Marc Bourguet a écrit :Marc Boyer writes:
Si le véritable exemple t'intéresse, je peux te le poster.
Ca n'est pas très long (7 classes, 400 lignes, 10ko de code).
Tu peux le faire ou me l'envoyer en perso. Je ne garanti pas de reponse
rapide.
Levons une ambiguïté: en ce qui me concerne, l'explication sur
la gestion des temporaires me convient, en j'ai une solution à
base de *(new X(1)), qui crée des objets persistants.
Après, Laurent était étonné par la nature du message d'erreur et
je lui proposais le code s'il le voulait. Cela vaut aussi pour
toi.
Mais ne fait pas ça pour moi, mais uniquement pour satisfaire ta
curiosité.
Marc Boyer wrote on 07/03/2007 13:42:
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
tu peux garder une sémantique référence (et non pointeurs) mais ajouter
en effet un clone et des destructeurs propres.
struct Fonction {
virtual ~Fonction(){}
virtual Fonction& clone() const = 0;
virtual double operator()(double x) const = 0;
};
class Affine : public Fonction {
double a;
public:
Affine(double _a) : a(_a){}
Fonction& clone() const {
return *new Affine(a);
return *new Affine(*this);
}
double operator()(double x) const {
return a*x;
}
};
class Min : public Fonction {
Fonction& f;
Fonction& g;
public:
Min(const Fonction& _f, const Fonction& _g) :
f(_f.clone()), g(_g.clone()){
}
~Min(){
delete &f;
delete &g;
}
Fonction& clone() const {
return *new Min(f, g);
}
Marc Boyer wrote on 07/03/2007 13:42:
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
tu peux garder une sémantique référence (et non pointeurs) mais ajouter
en effet un clone et des destructeurs propres.
struct Fonction {
virtual ~Fonction(){}
virtual Fonction& clone() const = 0;
virtual double operator()(double x) const = 0;
};
class Affine : public Fonction {
double a;
public:
Affine(double _a) : a(_a){}
Fonction& clone() const {
return *new Affine(a);
return *new Affine(*this);
}
double operator()(double x) const {
return a*x;
}
};
class Min : public Fonction {
Fonction& f;
Fonction& g;
public:
Min(const Fonction& _f, const Fonction& _g) :
f(_f.clone()), g(_g.clone()){
}
~Min(){
delete &f;
delete &g;
}
Fonction& clone() const {
return *new Min(f, g);
}
Marc Boyer wrote on 07/03/2007 13:42:
Alors je pourrais sortir l'artillerie des pointeurs, ou de methode
..clone(), mais j'ai la flemme. C'est du code jetable.
tu peux garder une sémantique référence (et non pointeurs) mais ajouter
en effet un clone et des destructeurs propres.
struct Fonction {
virtual ~Fonction(){}
virtual Fonction& clone() const = 0;
virtual double operator()(double x) const = 0;
};
class Affine : public Fonction {
double a;
public:
Affine(double _a) : a(_a){}
Fonction& clone() const {
return *new Affine(a);
return *new Affine(*this);
}
double operator()(double x) const {
return a*x;
}
};
class Min : public Fonction {
Fonction& f;
Fonction& g;
public:
Min(const Fonction& _f, const Fonction& _g) :
f(_f.clone()), g(_g.clone()){
}
~Min(){
delete &f;
delete &g;
}
Fonction& clone() const {
return *new Min(f, g);
}
le polymorphisme existe toujours mais en effet 'Fonction' est virtuel pure.
Le polymorphisme existe toujours ? Tu peux développer ?
des données membre pointeurs sont pourtant la bonne solution, [...]
Oui, si ce code avait vocation à durer, je ferais ça.
le polymorphisme existe toujours mais en effet 'Fonction' est virtuel pure.
Le polymorphisme existe toujours ? Tu peux développer ?
des données membre pointeurs sont pourtant la bonne solution, [...]
Oui, si ce code avait vocation à durer, je ferais ça.
le polymorphisme existe toujours mais en effet 'Fonction' est virtuel pure.
Le polymorphisme existe toujours ? Tu peux développer ?
des données membre pointeurs sont pourtant la bonne solution, [...]
Oui, si ce code avait vocation à durer, je ferais ça.
f et g sont des instances d'une classe ayant [...]
f et g sont des instances d'une classe ayant [...]
f et g sont des instances d'une classe ayant [...]
Marc Boyer wrote on 07/03/2007 15:32:le polymorphisme existe toujours mais en effet 'Fonction' est virtuel pure.
Le polymorphisme existe toujours ? Tu peux développer ?
le "polymorphisme" telle une notion générique non.
le comportement polymorphe de tes instances, oui.
f et g sont des instances d'une classe ayant des méthodes virtuelles, en
particulier l'opérateur (), l'appel à f(double) et g(double) se fait
donc par une résolution virtuelle (polymorphe) de cette méthode (un
virtual_invoke et non static_invoke puisque tu trouves Java cohérent -
ce qui te sauverait pour ce code en Java tient plus de son ref. counting
que d'un problème de cohérence d'ailleurs).
il se trouve que lorsque Min () utilise f()et g(), f et g sont réduit à
des Fonction, leur résolution polymorphe tourne alors court à la seule
évaluation de Fonction::()
des données membre pointeurs sont pourtant la bonne solution, [...]
Oui, si ce code avait vocation à durer, je ferais ça.
s'il a vocation à ne pas durer mais aussi à ne pas fonctionner même une
seule fois, tu peux en effet t'en passer.
Marc Boyer wrote on 07/03/2007 15:32:
le polymorphisme existe toujours mais en effet 'Fonction' est virtuel pure.
Le polymorphisme existe toujours ? Tu peux développer ?
le "polymorphisme" telle une notion générique non.
le comportement polymorphe de tes instances, oui.
f et g sont des instances d'une classe ayant des méthodes virtuelles, en
particulier l'opérateur (), l'appel à f(double) et g(double) se fait
donc par une résolution virtuelle (polymorphe) de cette méthode (un
virtual_invoke et non static_invoke puisque tu trouves Java cohérent -
ce qui te sauverait pour ce code en Java tient plus de son ref. counting
que d'un problème de cohérence d'ailleurs).
il se trouve que lorsque Min () utilise f()et g(), f et g sont réduit à
des Fonction, leur résolution polymorphe tourne alors court à la seule
évaluation de Fonction::()
des données membre pointeurs sont pourtant la bonne solution, [...]
Oui, si ce code avait vocation à durer, je ferais ça.
s'il a vocation à ne pas durer mais aussi à ne pas fonctionner même une
seule fois, tu peux en effet t'en passer.
Marc Boyer wrote on 07/03/2007 15:32:le polymorphisme existe toujours mais en effet 'Fonction' est virtuel pure.
Le polymorphisme existe toujours ? Tu peux développer ?
le "polymorphisme" telle une notion générique non.
le comportement polymorphe de tes instances, oui.
f et g sont des instances d'une classe ayant des méthodes virtuelles, en
particulier l'opérateur (), l'appel à f(double) et g(double) se fait
donc par une résolution virtuelle (polymorphe) de cette méthode (un
virtual_invoke et non static_invoke puisque tu trouves Java cohérent -
ce qui te sauverait pour ce code en Java tient plus de son ref. counting
que d'un problème de cohérence d'ailleurs).
il se trouve que lorsque Min () utilise f()et g(), f et g sont réduit à
des Fonction, leur résolution polymorphe tourne alors court à la seule
évaluation de Fonction::()
des données membre pointeurs sont pourtant la bonne solution, [...]
Oui, si ce code avait vocation à durer, je ferais ça.
s'il a vocation à ne pas durer mais aussi à ne pas fonctionner même une
seule fois, tu peux en effet t'en passer.
Marc Boyer writes:Le 07-03-2007, Jean-Marc Bourguet a écrit :Marc Boyer writes:
Si le véritable exemple t'intéresse, je peux te le poster.
Ca n'est pas très long (7 classes, 400 lignes, 10ko de code).
Tu peux le faire ou me l'envoyer en perso. Je ne garanti pas de reponse
rapide.
Levons une ambiguïté: en ce qui me concerne, l'explication sur
la gestion des temporaires me convient, en j'ai une solution à
base de *(new X(1)), qui crée des objets persistants.
Après, Laurent était étonné par la nature du message d'erreur et
je lui proposais le code s'il le voulait. Cela vaut aussi pour
toi.
Mais ne fait pas ça pour moi, mais uniquement pour satisfaire ta
curiosité.
J'aimerais bien comprendre pourquoi ton exemple reduit ne donne pas le
message que tu as avec le code complet... Et ce avec au moins 2
compilateurs d'origine differentes meme en non optimise, donc il y a peut
de chance que ce soit un artefact d'un compilateur qui applique une
optimisation tenant compte du fait que tout est visible.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Le 07-03-2007, Jean-Marc Bourguet <jm@bourguet.org> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Si le véritable exemple t'intéresse, je peux te le poster.
Ca n'est pas très long (7 classes, 400 lignes, 10ko de code).
Tu peux le faire ou me l'envoyer en perso. Je ne garanti pas de reponse
rapide.
Levons une ambiguïté: en ce qui me concerne, l'explication sur
la gestion des temporaires me convient, en j'ai une solution à
base de *(new X(1)), qui crée des objets persistants.
Après, Laurent était étonné par la nature du message d'erreur et
je lui proposais le code s'il le voulait. Cela vaut aussi pour
toi.
Mais ne fait pas ça pour moi, mais uniquement pour satisfaire ta
curiosité.
J'aimerais bien comprendre pourquoi ton exemple reduit ne donne pas le
message que tu as avec le code complet... Et ce avec au moins 2
compilateurs d'origine differentes meme en non optimise, donc il y a peut
de chance que ce soit un artefact d'un compilateur qui applique une
optimisation tenant compte du fait que tout est visible.
Marc Boyer writes:Le 07-03-2007, Jean-Marc Bourguet a écrit :Marc Boyer writes:
Si le véritable exemple t'intéresse, je peux te le poster.
Ca n'est pas très long (7 classes, 400 lignes, 10ko de code).
Tu peux le faire ou me l'envoyer en perso. Je ne garanti pas de reponse
rapide.
Levons une ambiguïté: en ce qui me concerne, l'explication sur
la gestion des temporaires me convient, en j'ai une solution à
base de *(new X(1)), qui crée des objets persistants.
Après, Laurent était étonné par la nature du message d'erreur et
je lui proposais le code s'il le voulait. Cela vaut aussi pour
toi.
Mais ne fait pas ça pour moi, mais uniquement pour satisfaire ta
curiosité.
J'aimerais bien comprendre pourquoi ton exemple reduit ne donne pas le
message que tu as avec le code complet... Et ce avec au moins 2
compilateurs d'origine differentes meme en non optimise, donc il y a peut
de chance que ce soit un artefact d'un compilateur qui applique une
optimisation tenant compte du fait que tout est visible.
Marc Boyer wrote:class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Probleme ici. Il ne faut pas utiliser des references mais des copies.
Avec des copies
const Fonction f;
je perds le polymorphisme (et sur ce coup, il se plaint que Fonction
a une méthode virtuelle pure).
ok, j'avais rate ce details.
Oui. En je pensais que tu me ferais un couplet sur le choix
inadéquat de C++ de privilégier la sémantique de valeur.
Je réalise que quand on veut le polymorphisme, on est
obligé de ce taper pleins de pointeurs,
et qu'en fait,
Java est cohérent sur ce point.
Non, pas vraiment. Je sais comment produire facilement des 'pure virtual
call' tout seul comme un grand ;-) Et en plus je suis a la bourre pour
mon papier OOPSLA (date de cloture le 19 mars, sic!) donc d'ici la...
Il te reste 12 jours. Ca dépend s'il faut encore obtenir les
résultats ou juste mettre en forme le papier...
Marc Boyer wrote:
class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Probleme ici. Il ne faut pas utiliser des references mais des copies.
Avec des copies
const Fonction f;
je perds le polymorphisme (et sur ce coup, il se plaint que Fonction
a une méthode virtuelle pure).
ok, j'avais rate ce details.
Oui. En je pensais que tu me ferais un couplet sur le choix
inadéquat de C++ de privilégier la sémantique de valeur.
Je réalise que quand on veut le polymorphisme, on est
obligé de ce taper pleins de pointeurs,
et qu'en fait,
Java est cohérent sur ce point.
Non, pas vraiment. Je sais comment produire facilement des 'pure virtual
call' tout seul comme un grand ;-) Et en plus je suis a la bourre pour
mon papier OOPSLA (date de cloture le 19 mars, sic!) donc d'ici la...
Il te reste 12 jours. Ca dépend s'il faut encore obtenir les
résultats ou juste mettre en forme le papier...
Marc Boyer wrote:class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Probleme ici. Il ne faut pas utiliser des references mais des copies.
Avec des copies
const Fonction f;
je perds le polymorphisme (et sur ce coup, il se plaint que Fonction
a une méthode virtuelle pure).
ok, j'avais rate ce details.
Oui. En je pensais que tu me ferais un couplet sur le choix
inadéquat de C++ de privilégier la sémantique de valeur.
Je réalise que quand on veut le polymorphisme, on est
obligé de ce taper pleins de pointeurs,
et qu'en fait,
Java est cohérent sur ce point.
Non, pas vraiment. Je sais comment produire facilement des 'pure virtual
call' tout seul comme un grand ;-) Et en plus je suis a la bourre pour
mon papier OOPSLA (date de cloture le 19 mars, sic!) donc d'ici la...
Il te reste 12 jours. Ca dépend s'il faut encore obtenir les
résultats ou juste mettre en forme le papier...
Marc Boyer wrote:Marc Boyer wrote:class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Probleme ici. Il ne faut pas utiliser des references mais des copies.
Avec des copies
const Fonction f;
je perds le polymorphisme (et sur ce coup, il se plaint que Fonction
a une méthode virtuelle pure).
ok, j'avais rate ce details.
Oui. En je pensais que tu me ferais un couplet sur le choix
inadéquat de C++ de privilégier la sémantique de valeur.
Plus la peine, tu le fait tout seul ;-) Ceci dit, je n'ai pas dis que
c'etait inadequat, j'ai dit que c'etait (beaucoup) plus complique. Mais
c'est obligatoire quand on fait le choix de 1) rester compatible avec le
C, 2) etre tres efficace et 3) conserver un modele proche de celui de la
machine.
Je réalise que quand on veut le polymorphisme, on est
obligé de ce taper pleins de pointeurs,
condition incontournable pour avoir le polymorphisme d'inclusion.
Non, pas vraiment. Je sais comment produire facilement des 'pure virtual
call' tout seul comme un grand ;-) Et en plus je suis a la bourre pour
mon papier OOPSLA (date de cloture le 19 mars, sic!) donc d'ici la...
Il te reste 12 jours. Ca dépend s'il faut encore obtenir les
résultats ou juste mettre en forme le papier...
J'ai les resultats mais il me reste a les mettre en ordre et j'ai ecrit
seulement 25% du papier pour l'instant (en 4 jours). Le probleme, c'est
qu'il y a beaucoup de chose a dire et que 10000 mots c'est pas beaucoup
alors au debut je reflechissais murement a ce que j'allais dire (je
comptais meme les mots).
Maintenant j'ecris les lignes au kilometre et
j'effacerais / reformulerais a la fin en fonction du surplus (ce qui
suppose que je finisse en avance sic!).
Marc Boyer wrote:
Marc Boyer wrote:
class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Probleme ici. Il ne faut pas utiliser des references mais des copies.
Avec des copies
const Fonction f;
je perds le polymorphisme (et sur ce coup, il se plaint que Fonction
a une méthode virtuelle pure).
ok, j'avais rate ce details.
Oui. En je pensais que tu me ferais un couplet sur le choix
inadéquat de C++ de privilégier la sémantique de valeur.
Plus la peine, tu le fait tout seul ;-) Ceci dit, je n'ai pas dis que
c'etait inadequat, j'ai dit que c'etait (beaucoup) plus complique. Mais
c'est obligatoire quand on fait le choix de 1) rester compatible avec le
C, 2) etre tres efficace et 3) conserver un modele proche de celui de la
machine.
Je réalise que quand on veut le polymorphisme, on est
obligé de ce taper pleins de pointeurs,
condition incontournable pour avoir le polymorphisme d'inclusion.
Non, pas vraiment. Je sais comment produire facilement des 'pure virtual
call' tout seul comme un grand ;-) Et en plus je suis a la bourre pour
mon papier OOPSLA (date de cloture le 19 mars, sic!) donc d'ici la...
Il te reste 12 jours. Ca dépend s'il faut encore obtenir les
résultats ou juste mettre en forme le papier...
J'ai les resultats mais il me reste a les mettre en ordre et j'ai ecrit
seulement 25% du papier pour l'instant (en 4 jours). Le probleme, c'est
qu'il y a beaucoup de chose a dire et que 10000 mots c'est pas beaucoup
alors au debut je reflechissais murement a ce que j'allais dire (je
comptais meme les mots).
Maintenant j'ecris les lignes au kilometre et
j'effacerais / reformulerais a la fin en fonction du surplus (ce qui
suppose que je finisse en avance sic!).
Marc Boyer wrote:Marc Boyer wrote:class Min : public Fonction {
const Fonction& f;
const Fonction& g;
Probleme ici. Il ne faut pas utiliser des references mais des copies.
Avec des copies
const Fonction f;
je perds le polymorphisme (et sur ce coup, il se plaint que Fonction
a une méthode virtuelle pure).
ok, j'avais rate ce details.
Oui. En je pensais que tu me ferais un couplet sur le choix
inadéquat de C++ de privilégier la sémantique de valeur.
Plus la peine, tu le fait tout seul ;-) Ceci dit, je n'ai pas dis que
c'etait inadequat, j'ai dit que c'etait (beaucoup) plus complique. Mais
c'est obligatoire quand on fait le choix de 1) rester compatible avec le
C, 2) etre tres efficace et 3) conserver un modele proche de celui de la
machine.
Je réalise que quand on veut le polymorphisme, on est
obligé de ce taper pleins de pointeurs,
condition incontournable pour avoir le polymorphisme d'inclusion.
Non, pas vraiment. Je sais comment produire facilement des 'pure virtual
call' tout seul comme un grand ;-) Et en plus je suis a la bourre pour
mon papier OOPSLA (date de cloture le 19 mars, sic!) donc d'ici la...
Il te reste 12 jours. Ca dépend s'il faut encore obtenir les
résultats ou juste mettre en forme le papier...
J'ai les resultats mais il me reste a les mettre en ordre et j'ai ecrit
seulement 25% du papier pour l'instant (en 4 jours). Le probleme, c'est
qu'il y a beaucoup de chose a dire et que 10000 mots c'est pas beaucoup
alors au debut je reflechissais murement a ce que j'allais dire (je
comptais meme les mots).
Maintenant j'ecris les lignes au kilometre et
j'effacerais / reformulerais a la fin en fonction du surplus (ce qui
suppose que je finisse en avance sic!).
Marc Boyer writes:j'ai un problème 'pure virtual method called' (avec g++), et je n'arr ive
pas à faire d'exemple minimal qui reproduise le pb...
Generalement ca arrive quand on appelle un membre virtuel dans le
constructeur ou le destructeur d'un objet.
Mais j'ai peut etre identifié le pb. Quand j'écris un truc du genre
X x( Y(1) );
avec X et Y deux classes, quelle est la durée de vie de l'objet
temporaire Y ?
Comme tous les temporaires qui ne sont pas bindé a une
variable reference: jusqu'a la fin de l'expression.
Actuellement, je prends une référence sur cet objet,
Si tu la conserve au dela du constructeur de x (comme le
laisse croire la suite), c'est fort possible que ce soit la
source de ton probleme (et on ne se retrouve pas dans le cas
general mais vraissemblablement tu appelles le membre virtuel
apres la fin de l'execution du destructeur de Y(1)).
Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid> writes:
j'ai un problème 'pure virtual method called' (avec g++), et je n'arr ive
pas à faire d'exemple minimal qui reproduise le pb...
Generalement ca arrive quand on appelle un membre virtuel dans le
constructeur ou le destructeur d'un objet.
Mais j'ai peut etre identifié le pb. Quand j'écris un truc du genre
X x( Y(1) );
avec X et Y deux classes, quelle est la durée de vie de l'objet
temporaire Y ?
Comme tous les temporaires qui ne sont pas bindé a une
variable reference: jusqu'a la fin de l'expression.
Actuellement, je prends une référence sur cet objet,
Si tu la conserve au dela du constructeur de x (comme le
laisse croire la suite), c'est fort possible que ce soit la
source de ton probleme (et on ne se retrouve pas dans le cas
general mais vraissemblablement tu appelles le membre virtuel
apres la fin de l'execution du destructeur de Y(1)).
Marc Boyer writes:j'ai un problème 'pure virtual method called' (avec g++), et je n'arr ive
pas à faire d'exemple minimal qui reproduise le pb...
Generalement ca arrive quand on appelle un membre virtuel dans le
constructeur ou le destructeur d'un objet.
Mais j'ai peut etre identifié le pb. Quand j'écris un truc du genre
X x( Y(1) );
avec X et Y deux classes, quelle est la durée de vie de l'objet
temporaire Y ?
Comme tous les temporaires qui ne sont pas bindé a une
variable reference: jusqu'a la fin de l'expression.
Actuellement, je prends une référence sur cet objet,
Si tu la conserve au dela du constructeur de x (comme le
laisse croire la suite), c'est fort possible que ce soit la
source de ton probleme (et on ne se retrouve pas dans le cas
general mais vraissemblablement tu appelles le membre virtuel
apres la fin de l'execution du destructeur de Y(1)).