bah, les listes chainées sont les listes de coups valides sur un jeu de plateau, j'en examine 2 500 000 par seconde en mileu de partie et pres de 7 000 000 en fin de partie [...] pour info: je reflechi aux modifications pour implementer un alpha beta parallele. l'instanciation sur la pile me fais gagner 15 % par rapport au tas (new/delete)
donc, dans ton main (ou assez proche) tu disposes d'un array de 2500000 items qui vers la fin de la partie passe à 7e6 items ?!?
heaper ou stacker ne fera aucune différence ... si on ne s'amuse pas à allouer (new-er) une à une les 7e6 références; le new de placement peux servir, le new [] également.
Sylvain.
Bruno Causse wrote on 27/08/2007 17:53:
bah, les listes chainées sont les listes de coups valides sur un jeu de
plateau, j'en examine 2 500 000 par seconde en mileu de partie et pres de 7
000 000 en fin de partie
[...]
pour info: je reflechi aux modifications pour implementer un alpha beta
parallele. l'instanciation sur la pile me fais gagner 15 % par rapport au
tas (new/delete)
donc, dans ton main (ou assez proche) tu disposes d'un array de 2500000
items qui vers la fin de la partie passe à 7e6 items ?!?
heaper ou stacker ne fera aucune différence ... si on ne s'amuse pas à
allouer (new-er) une à une les 7e6 références; le new de placement peux
servir, le new [] également.
bah, les listes chainées sont les listes de coups valides sur un jeu de plateau, j'en examine 2 500 000 par seconde en mileu de partie et pres de 7 000 000 en fin de partie [...] pour info: je reflechi aux modifications pour implementer un alpha beta parallele. l'instanciation sur la pile me fais gagner 15 % par rapport au tas (new/delete)
donc, dans ton main (ou assez proche) tu disposes d'un array de 2500000 items qui vers la fin de la partie passe à 7e6 items ?!?
heaper ou stacker ne fera aucune différence ... si on ne s'amuse pas à allouer (new-er) une à une les 7e6 références; le new de placement peux servir, le new [] également.
Sylvain.
Bruno Causse
"Sylvain" a écrit dans le message de news: 46d35e52$0$27374$
Bruno Causse wrote on 27/08/2007 17:53:
donc, dans ton main (ou assez proche) tu disposes d'un array de 2500000 items qui vers la fin de la partie passe à 7e6 items ?!?
non, la liste des coups valides pour une position est d'une quizaine en moyenne (cree a max_legal_move = 34 pour simplifier) la profondeur de recherche depasse rarement les 35/40 coups
soit de lordre de 40 listes de 34 moves
par contre plusieurs centaines de milliers de listes sont crées et detruites par seconde.
heaper ou stacker ne fera aucune différence ... si on ne s'amuse pas à allouer (new-er) une à une les 7e6 références; le new de placement peux servir, le new [] également.
j'utilisais jusqu'a present une de table de liste static (reutilisation plutot que creation) _mov[max_plies][max_legal_move]. mais comme je souhaite faire du multithreading (parrallelisme) je revois ma conception.
comme vous avez pu le contaster le c++ n'est pas mon fort. .
"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
46d35e52$0$27374$ba4acef3@news.orange.fr...
Bruno Causse wrote on 27/08/2007 17:53:
donc, dans ton main (ou assez proche) tu disposes d'un array de 2500000
items qui vers la fin de la partie passe à 7e6 items ?!?
non, la liste des coups valides pour une position est d'une quizaine en
moyenne (cree a max_legal_move = 34 pour simplifier)
la profondeur de recherche depasse rarement les 35/40 coups
soit de lordre de 40 listes de 34 moves
par contre plusieurs centaines de milliers de listes sont crées et detruites
par seconde.
heaper ou stacker ne fera aucune différence ... si on ne s'amuse pas à
allouer (new-er) une à une les 7e6 références; le new de placement peux
servir, le new [] également.
j'utilisais jusqu'a present une de table de liste static (reutilisation
plutot que creation) _mov[max_plies][max_legal_move]. mais comme je souhaite
faire du multithreading (parrallelisme) je revois ma conception.
comme vous avez pu le contaster le c++ n'est pas mon fort.
.
"Sylvain" a écrit dans le message de news: 46d35e52$0$27374$
Bruno Causse wrote on 27/08/2007 17:53:
donc, dans ton main (ou assez proche) tu disposes d'un array de 2500000 items qui vers la fin de la partie passe à 7e6 items ?!?
non, la liste des coups valides pour une position est d'une quizaine en moyenne (cree a max_legal_move = 34 pour simplifier) la profondeur de recherche depasse rarement les 35/40 coups
soit de lordre de 40 listes de 34 moves
par contre plusieurs centaines de milliers de listes sont crées et detruites par seconde.
heaper ou stacker ne fera aucune différence ... si on ne s'amuse pas à allouer (new-er) une à une les 7e6 références; le new de placement peux servir, le new [] également.
j'utilisais jusqu'a present une de table de liste static (reutilisation plutot que creation) _mov[max_plies][max_legal_move]. mais comme je souhaite faire du multithreading (parrallelisme) je revois ma conception.
comme vous avez pu le contaster le c++ n'est pas mon fort. .
Gabriel Dos Reis
On Mon, 27 Aug 2007, Sylvain wrote:
| Bruno Causse wrote on 27/08/2007 12:09: | > | >> Le code donne est insuffisant pour savoir si il detruit des descendant de | >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le | >> destructeur de A virtuel. | > | > Non, uniquement utilisé en variable "automatique", portée dans "scoop" | > | > la class A ne possede que les constructeur/destructeur par defaut. | | elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se | générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
-- Gaby
On Mon, 27 Aug 2007, Sylvain wrote:
| Bruno Causse wrote on 27/08/2007 12:09:
| >
| >> Le code donne est insuffisant pour savoir si il detruit des descendant de
| >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le
| >> destructeur de A virtuel.
| >
| > Non, uniquement utilisé en variable "automatique", portée dans "scoop"
| >
| > la class A ne possede que les constructeur/destructeur par defaut.
|
| elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se
| générer des ennuis plus tard) avoir un destructeur virtuel.
| Bruno Causse wrote on 27/08/2007 12:09: | > | >> Le code donne est insuffisant pour savoir si il detruit des descendant de | >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le | >> destructeur de A virtuel. | > | > Non, uniquement utilisé en variable "automatique", portée dans "scoop" | > | > la class A ne possede que les constructeur/destructeur par defaut. | | elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se | générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
-- Gaby
Gabriel Dos Reis
On Mon, 27 Aug 2007, Fabien LE LEZ wrote:
| On 27 Aug 2007 16:50:55 +0200, Jean-Marc Bourguet : | | >Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne | >vois par l'interet d'un destructeur virtuel. | | Dans le cas présent, on joue avec des A* qui pointent sur des B, et
L'auteur n'avait pas l'air de jouer...
-- Gaby
On Mon, 27 Aug 2007, Fabien LE LEZ wrote:
| On 27 Aug 2007 16:50:55 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
|
| >Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne
| >vois par l'interet d'un destructeur virtuel.
|
| Dans le cas présent, on joue avec des A* qui pointent sur des B, et
| On 27 Aug 2007 16:50:55 +0200, Jean-Marc Bourguet : | | >Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne | >vois par l'interet d'un destructeur virtuel. | | Dans le cas présent, on joue avec des A* qui pointent sur des B, et
L'auteur n'avait pas l'air de jouer...
-- Gaby
Gabriel Dos Reis
On Tue, 28 Aug 2007, Bruno Causse wrote:
| comme vous avez pu le contaster le c++ n'est pas mon fort.
Cela n'est pas un probleme -- ce n'est pas mon fort non plus. L'essentiel, c'est de ne pas trop se laisser distraire.
-- Gaby
On Tue, 28 Aug 2007, Bruno Causse wrote:
| comme vous avez pu le contaster le c++ n'est pas mon fort.
Cela n'est pas un probleme -- ce n'est pas mon fort non plus.
L'essentiel, c'est de ne pas trop se laisser distraire.
| comme vous avez pu le contaster le c++ n'est pas mon fort.
Cela n'est pas un probleme -- ce n'est pas mon fort non plus. L'essentiel, c'est de ne pas trop se laisser distraire.
-- Gaby
Jean-Marc Bourguet
Sylvain writes:
Jean-Marc Bourguet wrote on 27/08/2007 16:50:
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne vois par l'interet d'un destructeur virtuel.
hmm, une liste chainée sur la pile ?!... mais Fabien a déjà répondu.
Si ça correspond à la durée de vie des objets, pourquoi pas?
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
Sylvain <noSpam@mail.net> writes:
Jean-Marc Bourguet wrote on 27/08/2007 16:50:
Si par conception une classe n'a du sens qu'instanciee sur la pile, je
ne vois par l'interet d'un destructeur virtuel.
hmm, une liste chainée sur la pile ?!...
mais Fabien a déjà répondu.
Si ça correspond à la durée de vie des objets, pourquoi pas?
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
Si par conception une classe n'a du sens qu'instanciee sur la pile, je ne vois par l'interet d'un destructeur virtuel.
hmm, une liste chainée sur la pile ?!... mais Fabien a déjà répondu.
Si ça correspond à la durée de vie des objets, pourquoi pas?
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
Sylvain
Jean-Marc Bourguet wrote on 28/08/2007 14:34:
une liste chainée sur la pile Si ça correspond à la durée de vie des objets, pourquoi pas?
certes ! "durée de vie" ou "lieu de déclaration" étant remplacables ici, je ne m'attendais pas à ce que les élements d'une liste chainée soit en fait les éléments consécutifs d'un tableau.
si j'avais à ordonner de tels éléments (de tableau) j'utiliserais un tableau distinct d'index, pas des pointeurs avants; un tableau sur le tas (donc static) était incompatible avec l'idée que le chainage était (vraiment) nécessaire car dynamique.
Sylvain.
Jean-Marc Bourguet wrote on 28/08/2007 14:34:
une liste chainée sur la pile
Si ça correspond à la durée de vie des objets, pourquoi pas?
certes ! "durée de vie" ou "lieu de déclaration" étant remplacables ici,
je ne m'attendais pas à ce que les élements d'une liste chainée soit en
fait les éléments consécutifs d'un tableau.
si j'avais à ordonner de tels éléments (de tableau) j'utiliserais un
tableau distinct d'index, pas des pointeurs avants; un tableau sur le
tas (donc static) était incompatible avec l'idée que le chainage était
(vraiment) nécessaire car dynamique.
une liste chainée sur la pile Si ça correspond à la durée de vie des objets, pourquoi pas?
certes ! "durée de vie" ou "lieu de déclaration" étant remplacables ici, je ne m'attendais pas à ce que les élements d'une liste chainée soit en fait les éléments consécutifs d'un tableau.
si j'avais à ordonner de tels éléments (de tableau) j'utiliserais un tableau distinct d'index, pas des pointeurs avants; un tableau sur le tas (donc static) était incompatible avec l'idée que le chainage était (vraiment) nécessaire car dynamique.
Sylvain.
David Fleury
On Mon, 27 Aug 2007, Sylvain wrote:
| Bruno Causse wrote on 27/08/2007 12:09: | > | >> Le code donne est insuffisant pour savoir si il detruit des descendant de | >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le | >> destructeur de A virtuel. | > | > Non, uniquement utilisé en variable "automatique", portée dans "scoop" | > | > la class A ne possede que les constructeur/destructeur par defaut. | | elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se | générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ? Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Aujourd'hui, ma règle étant de toujours virtualiser le destructeur pour une classe pouvant être (et surtout étant) héritée. Du coup, j'ai un gros doute...
On Mon, 27 Aug 2007, Sylvain wrote:
| Bruno Causse wrote on 27/08/2007 12:09:
| >
| >> Le code donne est insuffisant pour savoir si il detruit des descendant de
| >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le
| >> destructeur de A virtuel.
| >
| > Non, uniquement utilisé en variable "automatique", portée dans "scoop"
| >
| > la class A ne possede que les constructeur/destructeur par defaut.
|
| elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se
| générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence
du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être
une façon de dire "est un", et le principe de substitution ne
devrait-il pas être de mise ?
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne
devrait-il pas être présent dans la classe mère ?
Aujourd'hui, ma règle étant de toujours virtualiser le destructeur
pour une classe pouvant être (et surtout étant) héritée.
Du coup, j'ai un gros doute...
| Bruno Causse wrote on 27/08/2007 12:09: | > | >> Le code donne est insuffisant pour savoir si il detruit des descendant de | >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le | >> destructeur de A virtuel. | > | > Non, uniquement utilisé en variable "automatique", portée dans "scoop" | > | > la class A ne possede que les constructeur/destructeur par defaut. | | elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se | générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ? Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Aujourd'hui, ma règle étant de toujours virtualiser le destructeur pour une classe pouvant être (et surtout étant) héritée. Du coup, j'ai un gros doute...
Jean-Marc Bourguet
Sylvain writes:
Jean-Marc Bourguet wrote on 28/08/2007 14:34:
une liste chainée sur la pile Si ça correspond à la durée de vie des objets, pourquoi pas?
certes ! "durée de vie" ou "lieu de déclaration" étant remplacables ici, je ne m'attendais pas à ce que les élements d'une liste chainée soit en fait les éléments consécutifs d'un tableau.
Est-ce qu'ils le sont réellement ou bien cette caractéristique n'est qu'une conséquence d'avoir simplifié des aspects non pertinents du problème pour le présenter?
(Et on commence à introduire des informations qui n'étaient pas disponible au début.)
si j'avais à ordonner de tels éléments (de tableau) j'utiliserais un tableau distinct d'index, pas des pointeurs avants; un tableau sur le tas (donc static) était incompatible avec l'idée que le chainage était (vraiment) nécessaire car dynamique.
C'est une approche possible. Mais elle a d'autres contraintes.
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
Sylvain <noSpam@mail.net> writes:
Jean-Marc Bourguet wrote on 28/08/2007 14:34:
une liste chainée sur la pile
Si ça correspond à la durée de vie des objets, pourquoi pas?
certes ! "durée de vie" ou "lieu de déclaration" étant remplacables ici, je
ne m'attendais pas à ce que les élements d'une liste chainée soit en fait
les éléments consécutifs d'un tableau.
Est-ce qu'ils le sont réellement ou bien cette caractéristique n'est qu'une
conséquence d'avoir simplifié des aspects non pertinents du problème pour
le présenter?
(Et on commence à introduire des informations qui n'étaient pas disponible
au début.)
si j'avais à ordonner de tels éléments (de tableau) j'utiliserais un
tableau distinct d'index, pas des pointeurs avants; un tableau sur le tas
(donc static) était incompatible avec l'idée que le chainage était
(vraiment) nécessaire car dynamique.
C'est une approche possible. Mais elle a d'autres contraintes.
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
une liste chainée sur la pile Si ça correspond à la durée de vie des objets, pourquoi pas?
certes ! "durée de vie" ou "lieu de déclaration" étant remplacables ici, je ne m'attendais pas à ce que les élements d'une liste chainée soit en fait les éléments consécutifs d'un tableau.
Est-ce qu'ils le sont réellement ou bien cette caractéristique n'est qu'une conséquence d'avoir simplifié des aspects non pertinents du problème pour le présenter?
(Et on commence à introduire des informations qui n'étaient pas disponible au début.)
si j'avais à ordonner de tels éléments (de tableau) j'utiliserais un tableau distinct d'index, pas des pointeurs avants; un tableau sur le tas (donc static) était incompatible avec l'idée que le chainage était (vraiment) nécessaire car dynamique.
C'est une approche possible. Mais elle a d'autres contraintes.
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
Michael DOUBEZ
On Mon, 27 Aug 2007, Sylvain wrote:
| Bruno Causse wrote on 27/08/2007 12:09: | > | >> Le code donne est insuffisant pour savoir si il detruit des descendant de | >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le | >> destructeur de A virtuel. | > | > Non, uniquement utilisé en variable "automatique", portée dans "scoop" | > | > la class A ne possede que les constructeur/destructeur par defaut. | | elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se | générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
L'héritage peut être utilisée pour signifier "Est un" (public) ou "Est implémenté en terme de" (privé).
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pas stricto-sensus dans le norme actuelle, le destructeur virtuel est surtout utilise en cas d'appel explicite à delete comme par exemple:
class A {...}; class B: public A {...};
A* a = new B();
delete a;
Si le destructeur de A n'est pas virtuel, le destructeur de B ne sera pas appelé.
Mais si l'objet est dans la pile, c'est le bon destructeur qui sera appelé.
Mais bon, en cas d'héritage le destructeur devrait être virtuel pour éviter ces problèmes et gcc émet un warning, je crois, si ce n'est pas le cas.
Michael
On Mon, 27 Aug 2007, Sylvain wrote:
| Bruno Causse wrote on 27/08/2007 12:09:
| >
| >> Le code donne est insuffisant pour savoir si il detruit des
descendant de
| >> A à partir de pointeurs vers A, ce qui est la seule raison de
rendre le
| >> destructeur de A virtuel.
| >
| > Non, uniquement utilisé en variable "automatique", portée dans
"scoop"
| >
| > la class A ne possede que les constructeur/destructeur par defaut.
|
| elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se
| générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence
du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être
une façon de dire "est un", et le principe de substitution ne
devrait-il pas être de mise ?
L'héritage peut être utilisée pour signifier "Est un" (public) ou "Est
implémenté en terme de" (privé).
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne
devrait-il pas être présent dans la classe mère ?
Pas stricto-sensus dans le norme actuelle, le destructeur virtuel est
surtout utilise en cas d'appel explicite à delete comme par exemple:
class A {...};
class B: public A {...};
A* a = new B();
delete a;
Si le destructeur de A n'est pas virtuel, le destructeur de B ne sera
pas appelé.
Mais si l'objet est dans la pile, c'est le bon destructeur qui sera appelé.
Mais bon, en cas d'héritage le destructeur devrait être virtuel pour
éviter ces problèmes et gcc émet un warning, je crois, si ce n'est pas
le cas.
| Bruno Causse wrote on 27/08/2007 12:09: | > | >> Le code donne est insuffisant pour savoir si il detruit des descendant de | >> A à partir de pointeurs vers A, ce qui est la seule raison de rendre le | >> destructeur de A virtuel. | > | > Non, uniquement utilisé en variable "automatique", portée dans "scoop" | > | > la class A ne possede que les constructeur/destructeur par defaut. | | elle devrait (parce qu'il vaut mieux y penser au départ pour ne pas se | générer des ennuis plus tard) avoir un destructeur virtuel.
contre vents et marees ?
Je ne suis pas sûr de comprendre le débat sur la présence ou absence du destructeur virtuel.
De manière générale, un héritage publique n'est pas censé être une façon de dire "est un", et le principe de substitution ne devrait-il pas être de mise ?
L'héritage peut être utilisée pour signifier "Est un" (public) ou "Est implémenté en terme de" (privé).
Du coup quel qu'en soit l'usage de la classe, le destructeur virtuel ne devrait-il pas être présent dans la classe mère ?
Pas stricto-sensus dans le norme actuelle, le destructeur virtuel est surtout utilise en cas d'appel explicite à delete comme par exemple:
class A {...}; class B: public A {...};
A* a = new B();
delete a;
Si le destructeur de A n'est pas virtuel, le destructeur de B ne sera pas appelé.
Mais si l'objet est dans la pile, c'est le bon destructeur qui sera appelé.
Mais bon, en cas d'héritage le destructeur devrait être virtuel pour éviter ces problèmes et gcc émet un warning, je crois, si ce n'est pas le cas.
