Probleme de vitualisation - C++ (French)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Probleme de vitualisation
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ (French)

View previous topic :: View next topic

Author

Message

Dominique Vaufreydaz
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Probleme de vitualisation

Bonjour,

j'ai ecrit une classe thread (suis pas le premier, hein ;-P) qui en fait contient une
fonction Run virtuelle pure qui doit etre redefini dans une classe dérivée. Rien
de vraiment difficile. Cette classe thread contient une fonction StartThread()

J'ai rajouté un booléen sur le constructeur du Thread. Si on lui passe true, il
demarre tout seul en appelant StartThread. Je me suis dit que de toute facon,
je ne peux pas instancier la classe Thread (car abstraite du fait du virtual ... = 0).

Le probleme qui se pose (sous g++ uniquement avec comme flags de compilation
-Werror -Wall -pedantic -std=c++98 -fPIC) c'est que je me retrouve avec
des erreurs (et pas a chacune des executions) du genre.

Quote:

pure virtual method called
terminate called without an active exception
Abort

A priori, pas de debordement ailleurs (je verifie encore) qui justifierait l'ecrasement
de la table des fonctions virtuelles. Des idées ? Notons que le meme mecanisme fonctionne
a merveille sous Visual Studio 2005. Peut-etre un flag a rajouter à g++ ?

Merci d'avance. Doms.

Dominique Vaufreydaz
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

Salut,

Quote:

Tu veux dire que l'erreur est cachée dans je ne sais combien de
milliers de lignes de code, et impossible à reproduire dans un code
plus simple ?

Non, que si tu veux tout, il te faut ca. Mais que ca merde qu'avec
le Thread (qui utilise Event soit).

Quote:

Dans ce cas, laisse tomber -- tu n'arriveras probablement jamais à
identifier le problème.

Ben il faudrait bien car c'est moi qui ai fait ce code et que ca me
gonfle ! Surtout que le pure virtual method call j'ai un peu l'impression
que ca n'est pas vraiment de mon fait.

Reste que la reponse de Michel va dans le sens de ce que je pensais.
C'est un peu l'aspect random des choses qui m'embete.

Merci. Doms.

James Kanze
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

On Apr 4, 7:46 am, "Dominique Vaufreydaz" <Doms@invalid> wrote:

Quote:

j'ai ecrit une classe thread (suis pas le premier, hein
;-P) qui en fait contient une fonction Run virtuelle pure
qui doit etre redefini dans une classe dérivée. Rien de
vraiment difficile. Cette classe thread contient une
fonction StartThread()

Ce n'est pas forcément une bonne idée. C'est le vieux argument
du modèle stratégie contre le modèle template : dans ce cas-ci,
je préfère nettement le modèle stratégie (qui permettrait aussi
par la suite de fournir des wrapper templatés pour des fonctions
ou des objets fonctionnels).

Quote:

J'ai rajouté un booléen sur le constructeur du Thread. Si
on lui passe true, il demarre tout seul en appelant
StartThread.

Dans le constructeur de Thread ? Ça, c'est une très mauvaise
idée. Tu veux démarrer le thread avant que l'objet qui
l'implémente soit construit. (Curieusement, c'est une erreur
fréquente. La première version de SwingHelper, pour Java, la
faisait, par exemple.)

C'est une des raisons pourquoi je préfère de loin le modèle
stratégie ici.

Quote:

Je me suis dit que de toute facon, je ne peux
pas instancier la classe Thread (car abstraite du fait du
virtual ... = 0).

Le probleme qui se pose (sous g++ uniquement avec comme flags de compilation
-Werror -Wall -pedantic -std=c++98 -fPIC) c'est que je me retrouve avec
des erreurs (et pas a chacune des executions) du genre.

pure virtual method called
terminate called without an active exception
Abort

A priori, pas de debordement ailleurs (je verifie encore)
qui justifierait l'ecrasement de la table des fonctions
virtuelles. Des idées ?

C'est un comportement indéfini. Lors de la construction de
Thread, le type dynamique de l'objet est Thread. Ce qui veut
dire que la résolution dynamique trouve la version de la
fonction dans Thread. Et la norme dit que si la résolution
dynamique trouve une fonction virtuelle pûre, c'est un
comportement indéfini (même si la fonction a une définition).

Quote:

Notons que le meme mecanisme
fonctionne a merveille sous Visual Studio 2005.

C'est probablement le résultat d'une optimisation. Le
compilateur, sachant que la fonction est pûre virtuelle, et ne
peut pas être appelée par la résolution dynamique dans le
constructeur, se passe d'initialiser le vtable pour la classe de
base, mais l'initialise immédiatement pour la classe dérivée.

Comme j'ai dit, en revanche, c'est un comportement indéfini. Tu
ne peux pas y compter. Et dans ce cas-ci, tu ne veux pas t'y
compter non plus, parce que tu risques fort que la fonction
s'exécute sur l'objet avant même qu'on y est entré dans son
constructeur. (Ça dépend en fait du scheduleur ; je pourrais
bien imaginer un algorithme de scheduling où ça marcherait 99,9%
des fois, pour échouer 0,1%. C-à-d que ça marcherait dans tous
tes tests, pour échouer deux fois de suite lors de la démo
ultra-importante devant le client.)

Quote:

Peut-etre
un flag a rajouter à g++ ?

Dans ce cas-ci, je crois que le comportement de g++ est le
mieux. Il ne te laisse pas croire que ça marche.

--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) 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

Dominique Vaufreydaz
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

Bonjour,

Quote:

C'est bien ce que je pensais... Le truc qui me gonfle quand meme
c'est :
- que ca plante aps tout le temps
- que c'est pas dependant du code. Pour un meme exe, 2 executions
successivent donnes 2 comportement différents. Notons que
ca plante systematiquement si lancé via gdb ou valgrind...

Quote:

Je dirais plutot qu'il faut trouver le flag necessaire a Visual Studio
pour qu'il cesse de faire n'importe quoi.

Mouai. Perso, ca perd de l'interet le virtuel dans ce cas la (meme
si c'est un peu particulier) et j'aurais aimé que l'initialisation des
fonctions virtuelles soitent faites avant l'appel des constructeurs des
classes meres...

Ca veut quand meme dire que le compilo devrait raler si on appelle
des fonctions virtuelles (pure) dans le constructeur d'une classe.
Ce que ne font pas ni cl (VS2005) ni g++...

Merci. Doms.

James Kanze
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

On Apr 4, 8:53 am, Michel Decima <michel.dec...@orange-ft.com> wrote:

Quote:

Dominique Vaufreydaz a écrit :

j'ai ecrit une classe thread (suis pas le premier, hein
;-P) qui en fait contient une fonction Run virtuelle
pure qui doit etre redefini dans une classe dérivée.
Rien de vraiment difficile. Cette classe thread contient
une fonction StartThread()

J'ai rajouté un booléen sur le constructeur du Thread.
Si on lui passe true, il demarre tout seul en appelant
StartThread. Je me suis dit que de toute facon, je ne
peux pas instancier la classe Thread (car abstraite du
fait du virtual ... = 0).

Le probleme qui se pose (sous g++ uniquement avec comme
flags de compilation
-Werror -Wall -pedantic -std=c++98 -fPIC) c'est que je me retrouve avec
des erreurs (et pas a chacune des executions) du genre.
pure virtual method called
terminate called without an active exception
Abort

Si tu appelle une fonction membre virtuelle dans un constructeur d'une
classe de base, c'est la version disponible dans la classe de base qui
est appelee,

Est choisie par la résolution dynamique. Elle n'est pas
forcément appelée, si elle est (comme ici) virtuelle pûre.

Quote:

pas celle de la classe derivee. Si la fonction est
virtuelle pure, alors tu as un abort.

Si la fonction trouvée par la résolution dynamique est virtuelle
pûre, tu as un comportement indéfini. Il y a (malheureusement)
fort peu de cas où la norme exige un abort. Traditionnellement,
les premières compilateurs C++ mettait bien l'adresse de la
fonction abort() dans la vtable à cet endroit. (C'était gentil.
Un core dump, sans la moindre indication de pourquoi.) La
plupart, aujourd'hui, y mettent l'adresse d'une fonction
spéciale, mais commune à toutes les classes, qui affiche un
message d'erreur avant d'appeler abort(). Encore mieux serait de
mettre l'adresse d'un petit stub, qui appelle la fonction avec
le nom de la classe en paramètre.

Je crois que VC++ met l'adresse de la fonction, si elle est
implémentée, mais je ne suis pas sûr qu'elle le fasse
systèmatiquement. (Je pourrais même imaginer que ce qu'elle met
dépend du dégrée d'optimisation qu'on a démandée.)

Quote:

Ca peut paraitre tordu, mais c'est assez normal: le constructeur de la
classe de base va etre appelé avant celle de la classe derivee, et la
fonction virtuelle de la classe derivee utilise potentiellement des
membre de cette classe dérivee, qui ne seraient pas initialises lors
de l'appel par le constructeur de la base.

En effet : Java appelle toujours la fonction dans la classe que
l'objet va être, et c'est une source constante de problèmes. Si
tu dérives d'une classe que tu n'as pas écrite (genre quelque
chose dans Swing), il faut pratiquement que toutes les fonctions
membres que tu écrives commencent par tester si la classe a été
construite, avant de commencer leur travail. (En C++, ça serait
pire, parce qu'il serait impossible de savoir même si ton
constructeur a démarré.)

Note que dans l'exemple qu'il a posté en réponse à Fabien, il a
exactement ce problème : sa fonction Run() sera appelée avant
que la variable id sera initialisé, et même l'incrémentation
pourrait avoir lieu avant l'initialisation. (Fort peu probable à
cause du « sleep(10) », mais toujours possible. Et j'imagine
que dans l'application réele, il n'y a pas toujours un sleep(10)
au début de Run().)

[...]

Quote:

A priori, pas de debordement ailleurs (je verifie
encore) qui justifierait l'ecrasement de la table des
fonctions virtuelles. Des idées ? Notons que le meme
mecanisme fonctionne a merveille sous Visual Studio
2005. Peut-etre un flag a rajouter à g++ ?

Je dirais plutot qu'il faut trouver le flag necessaire a Visual Studio
pour qu'il cesse de faire n'importe quoi.

Il a le droit de faire n'importe quoi, dans la mesure que le
code contient un comportement indéfini. (Évidemment, du point de
vue de la qualité de l'implémentation...)

--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) 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

Dominique Vaufreydaz
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

Bonjour,

Quote:

Note que dans l'exemple qu'il a posté en réponse à Fabien, il a
exactement ce problème : sa fonction Run() sera appelée avant
que la variable id sera initialisé, et même l'incrémentation
pourrait avoir lieu avant l'initialisation. (Fort peu probable à
cause du « sleep(10) », mais toujours possible. Et j'imagine
que dans l'application réele, il n'y a pas toujours un sleep(10)
au début de Run().)

Notons comme je l'ai ecrit que c'etait un test bidon montrant
le probleme. Normalement, je n'ecris pas ce genre de chose.
Je voulais aussi tester dans ce cas, si le comportement du compilo
changeait avec une variable membre accèder dans la fonction Run.

Vala, vala. Merci donc, j'ai changé l'API de ma classe Thread.
Demarre plus toute seul ;oP Au moins, j'aurais appris qqchose
aujourd'hui.

Doms.

James Kanze
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

On Apr 4, 9:49 am, "Dominique Vaufreydaz" <Doms@invalid> wrote:

Quote:

À mon avis, je crois que là, tu es en train de voir le deuxième
phénomène dont j'ai parlé. Que le compilateur VC++ met bien
l'adresse de la fonction de la classe dérivée dans le vtable,
mais que selon les aléas du schéduleur, Run() s'exécute parfois
avant le constructeur, parfois après. Et parfois, sans doute, il
interrompt le constructeur au milieu, et vice versa. De toute
façon, selon ce que j'ai compris, tu exécute Run() dans un
thread différent du constructeur, tous les deux accédent (et le
constructeur, au moins, modifie) aux même variables, et qu'il
n'y a pas de synchronisation entre les deux. Selon les règles de
Posix (et je crois Windows aussi), c'est aussi un comportement
indéfini. Dans ce cas-ci, que la résolution de l'appel dynamique
fasse que tu veux ne fait qu'en créer un autre problème. Bien
plus subtile, d'ailleurs, et qui n'apparaît que de façon
aléatoire.

Quote:

Je dirais plutot qu'il faut trouver le flag necessaire a Visual Studio
pour qu'il cesse de faire n'importe quoi.

Mouai. Perso, ca perd de l'interet le virtuel dans ce cas la (meme
si c'est un peu particulier) et j'aurais aimé que l'initialisation des
fonctions virtuelles soitent faites avant l'appel des constructeurs des
classes meres...

Non, tu ne l'aurais pas aimé, au moins pas dans ce cas-ci. Je
t'assure. Échanger un core dump pour un problème aléatoire de
threading, ce n'est pas un échange gagnant.

Quote:

Ca veut quand meme dire que le compilo devrait raler si on appelle
des fonctions virtuelles (pure) dans le constructeur d'une classe.
Ce que ne font pas ni cl (VS2005) ni g++...

C'est en effet un peu curieux qu'aucun compilateur y génère
d'avertissement quand l'appel est directement dans le
constructeur. (La norme n'exige pas de diagnostique parce qu'il
y a des cas où on ne peut pas facilement déterminer. Si l'appel
a lieu dans une autre fonction, par exemple, ou à travers un
pointeur à fonction membre. Mais la norme n'interdit
certainement pas d'avertissement quand la violation est
flagrante, comme dans ton case.)

De toute façon, la solution, c'est l'utilisation du modèle de
stratégie (un délégué), à la place du modèle de template. Voire
même d'utiliser une fonction libre (ou membre statique) pour
démarrer le thread (en donnant la classe thread une sémantique
de valeur, à la Boost, ou -- dans le cas des threads détachés,
au moins -- en s'arrangeant à ce que le thread gère lui-même
sa mémoire).

--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) 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

Fabien LE LEZ
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

On Wed, 4 Apr 2007 08:53:17 +0200, "Dominique Vaufreydaz"
<Doms@invalid>:

Quote:

Il faut scons pour compiler et libxml2... Sinon, vous trouverez

Tu veux dire que l'erreur est cachée dans je ne sais combien de
milliers de lignes de code, et impossible à reproduire dans un code
plus simple ?

Dans ce cas, laisse tomber -- tu n'arriveras probablement jamais à
identifier le problème.

Dominique Vaufreydaz
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

Bonjour,

Fabien LE LEZ wrote:

Quote:

Même réponse que d'habitude : identifie et poste le code _minimal_ qui
reproduit le problème.

Toute l'attirail pour installer les choses se trouve ici :
http://gforge.inria.fr/frs/?group_id=363

Il faut scons pour compiler et libxml2... Sinon, vous trouverez
la classe Thread ici :
http://www.cijoint.fr/cij10255612339302.zip

Concernant la code posant (parfois) probleme :
class Server : public Thread {
int id;
public:
Server(int id): Thread(true), id(id) {
}
virtual void Run()
{
// ici n'importe quoi, ca change rien !
for(;; Wink

{
Sleep(10);
id++;
}
}
};

void maint()
{
new Server(i);
}

Voila. Doms.

Michel Decima
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

Dominique Vaufreydaz a écrit :

Quote:

Si tu appelle une fonction membre virtuelle dans un constructeur d'une
classe de base, c'est la version disponible dans la classe de base qui
est appelee, pas celle de la classe derivee. Si la fonction est
virtuelle pure, alors tu as un abort.

Ca peut paraitre tordu, mais c'est assez normal: le constructeur de la
classe de base va etre appelé avant celle de la classe derivee, et la
fonction virtuelle de la classe derivee utilise potentiellement des
membre de cette classe dérivee, qui ne seraient pas initialises lors
de l'appel par le constructeur de la base.

#include <iostream>

class Base {
public:
Base() {
func();
}

virtual void func() { std::cout << "Base" << std::endl; }
};

class Derived : public Base
{
public:
virtual void func() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d; // Affichera "Base".
}

Si je transforme Base::func() en fonction virtuelle pure, j'ai
le message suivant avec g++ (sans options particulieres):

pipo.C: In constructor 'Base::Base()':
pipo.C:6: warning: abstract virtual 'virtual void Base::func()' called
from constructor
ld: 0711-317 ERROR: Undefined symbol: .Base::func()

et xlC dit presque pareil:

"pipo.C", line 6.9: 1540-0285 (W) The expression calls the undefined
pure virtual function "Base::func()".
ld: 0711-317 ERROR: Undefined symbol: .Base::func()

Quote:

Je dirais plutot qu'il faut trouver le flag necessaire a Visual Studio
pour qu'il cesse de faire n'importe quoi.

Fabien LE LEZ
Guest

Posted: Wed Apr 04, 2007 9:11 am Post subject: Re: Probleme de vitualisation

Même réponse que d'habitude : identifie et poste le code _minimal_ qui reproduit le problème.

Dominique Vaufreydaz
Guest

Posted: Wed Apr 04, 2007 2:20 pm Post subject: Re: Probleme de vitualisation

Bonjour,

Quote:

Non, tu ne l'aurais pas aimé, au moins pas dans ce cas-ci. Je
t'assure. Échanger un core dump pour un problème aléatoire de
threading, ce n'est pas un échange gagnant.

Ouai, sauf qu'en general, le doe de Run verifie de les initialisations
ont ete faites... Donc pour moi ca fonctionne. Mais je confirme que
c'est forcement source d'erreur.

Quote:

Ouai, aucun de ceux que je n'ai essayé (pourtant je mets Wall
tout le temps !) ne le mentionne !

Quote:

De toute façon, la solution, c'est l'utilisation du modèle de
stratégie (un délégué), à la place du modèle de template. Voire
même d'utiliser une fonction libre (ou membre statique) pour
démarrer le thread (en donnant la classe thread une sémantique
de valeur, à la Boost, ou -- dans le cas des threads détachés,
au moins -- en s'arrangeant à ce que le thread gère lui-même
sa mémoire).

Je suis d'accord.

Merci ! Doms.

Guillaume GOURDIN
Guest

Posted: Thu Apr 05, 2007 2:32 pm Post subject: Re: Probleme de vitualisation

Quote:

Ce n'est pas forcément une bonne idée. C'est le vieux argument
du modèle stratégie contre le modèle template

Pourrais-je te demander ce que sont ces 2 modèles stp? Merci!

Jean-Marc Bourguet
Guest

Posted: Thu Apr 05, 2007 3:01 pm Post subject: Re: Probleme de vitualisation

Guillaume GOURDIN <gourdin (AT) liw (DOT) fr> writes:

Quote:

Ce n'est pas forcément une bonne idée. C'est le vieux argument
du modèle stratégie contre le modèle template

Pourrais-je te demander ce que sont ces 2 modèles stp? Merci!

"Il n'y est pas de probleme qui ne puisse etre resolu par une indirection
de plus."

En gros, le modele template permet d'adapter le fonctionnement d'une classe
en substituant des membres virtuels. Le modele strategie permet d'adapter
le fonctionnement d'une classe en lui donnant en parametre une autre classe
contenant (uniquement?) les membres qui sont adaptables. Il est plus
complique, mais plus souple.

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

Laurent Deniau
Guest

Posted: Thu Apr 05, 2007 3:20 pm Post subject: Re: Probleme de vitualisation

Jean-Marc Bourguet wrote:

Quote:

Guillaume GOURDIN <gourdin (AT) liw (DOT) fr> writes:

Ce n'est pas forcément une bonne idée. C'est le vieux argument
du modèle stratégie contre le modèle template
Pourrais-je te demander ce que sont ces 2 modèles stp? Merci!

"Il n'y est pas de probleme qui ne puisse etre resolu par une indirection
de plus."

En gros, le modele template permet d'adapter le fonctionnement d'une classe
en substituant des membres virtuels. Le modele strategie permet d'adapter
le fonctionnement d'une classe en lui donnant en parametre une autre classe
contenant (uniquement?) les membres qui sont adaptables. Il est plus
complique, mais plus souple.

Sans compter que le second est configurable au runtime, ce qui peut
s'averer utile dans le cas de la gestion de threads.

a+, ld.

Display posts from previous:

	C++Talk.NET Forum Index -> C++ (French)	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum