Ch Classes (libres voire gratuites) gérant les fuites mémoires
10 réponses
J-C.gibier
Bonjour,
J'ai cherché (un peu mais à tout les coups je suis passé au travers)
dans la faq pour voir s'il n'y avait pas de références pour ce problème
récurrent.
Je cherche précisément un classe (ou un recette, ou un listing) pas trop
lourde simple à implémenter, n'ayant pas de contrindications avec Builder
pour sauver quelques heures de travail (et quelques cheveux) sur un projet.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Matthieu Moy
"J-C.gibier" writes:
Bonjour,
Bonjour,
J'ai cherché (un peu mais à tout les coups je suis passé au travers) dans la faq pour voir s'il n'y avait pas de références pour ce problème récurrent.
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire, mais le programme Valgrind réponds peut-être à ta question.
J'ai cherché (un peu mais à tout les coups je suis passé au travers)
dans la faq pour voir s'il n'y avait pas de références pour ce problème
récurrent.
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire,
mais le programme Valgrind réponds peut-être à ta question.
J'ai cherché (un peu mais à tout les coups je suis passé au travers) dans la faq pour voir s'il n'y avait pas de références pour ce problème récurrent.
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire, mais le programme Valgrind réponds peut-être à ta question.
-- Matthieu
J-C.gibier
"Matthieu Moy" a écrit dans le message de news:
"J-C.gibier" writes:
Bonjour,
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire, mais le programme Valgrind réponds peut-être à ta question.
C'est vrai c'est un mot valise à la con, je voulais bien sûr dire : supprimer, éradiquer ou exterminer ;-) Ceci dit la home page indique :Valgrind is a GPL'd system for debugging and profiling x86-Linux programs. J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut être facilement portable mais sans confirmation je ne m'y risquerais pas.
Thx
"Matthieu Moy" <MatthieuNOSPAM.Moy@imag.fr.invalid> a écrit dans le message
de news:vpqekq8dypo.fsf@ubaye.imag.fr...
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire,
mais le programme Valgrind réponds peut-être à ta question.
C'est vrai c'est un mot valise à la con, je voulais bien sûr dire :
supprimer, éradiquer ou exterminer ;-)
Ceci dit la home page indique :Valgrind is a GPL'd system for debugging and
profiling x86-Linux programs.
J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut
être facilement portable mais sans confirmation je ne m'y risquerais pas.
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire, mais le programme Valgrind réponds peut-être à ta question.
C'est vrai c'est un mot valise à la con, je voulais bien sûr dire : supprimer, éradiquer ou exterminer ;-) Ceci dit la home page indique :Valgrind is a GPL'd system for debugging and profiling x86-Linux programs. J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut être facilement portable mais sans confirmation je ne m'y risquerais pas.
Thx
damien gautherin
J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut être facilement portable mais sans confirmation je ne m'y risquerais pas.
Bonjour,
memproof et MemorySleuth font ce genre de chose A+ Damien
J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut
être facilement portable mais sans confirmation je ne m'y risquerais pas.
Bonjour,
memproof et MemorySleuth font ce genre de chose
A+
Damien
J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut être facilement portable mais sans confirmation je ne m'y risquerais pas.
Bonjour,
memproof et MemorySleuth font ce genre de chose A+ Damien
Pierre Maurette
"J-C.gibier" typa:
"Matthieu Moy" a écrit dans le message de news:
"J-C.gibier" writes:
Bonjour,
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire, mais le programme Valgrind réponds peut-être à ta question.
C'est vrai c'est un mot valise à la con, je voulais bien sûr dire : supprimer, éradiquer ou exterminer ;-) Ceci dit la home page indique :Valgrind is a GPL'd system for debugging and profiling x86-Linux programs. J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut être facilement portable mais sans confirmation je ne m'y risquerais pas. Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ?
Il signale les fuites et situe leur origine. -- Pierre
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire,
mais le programme Valgrind réponds peut-être à ta question.
C'est vrai c'est un mot valise à la con, je voulais bien sûr dire :
supprimer, éradiquer ou exterminer ;-)
Ceci dit la home page indique :Valgrind is a GPL'd system for debugging and
profiling x86-Linux programs.
J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut
être facilement portable mais sans confirmation je ne m'y risquerais pas.
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ?
Il signale les fuites et situe leur origine.
--
Pierre
Je ne sais pas ce que tu entends par « gérer » les fuites de mémoire, mais le programme Valgrind réponds peut-être à ta question.
C'est vrai c'est un mot valise à la con, je voulais bien sûr dire : supprimer, éradiquer ou exterminer ;-) Ceci dit la home page indique :Valgrind is a GPL'd system for debugging and profiling x86-Linux programs. J'avais précisé dans mes doléances 'compatible avec Builder C++'. C'est peut être facilement portable mais sans confirmation je ne m'y risquerais pas. Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ?
Il signale les fuites et situe leur origine. -- Pierre
J-C.gibier
"Pierre Maurette" a écrit dans le message de news:
"J-C.gibier" typa:
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ? Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de l'allocation non libérée mais avec les boucles, les récursion ou les méthodes imbriquées, l'indication de la ligne fautive ne suffit plus. On en vient vite à rechercher d'autres solutions qui précisent le contexte dans lequel l'allocation à eut lieu. Si je parviens à customiser la classe de façon à enregistrer des éléments de contexte, le débuggage sera plus rapide (enfin j'espère:-).
"Pierre Maurette" <maurette.pierreAT@ATfree.fr> a écrit dans le message de
news:lvev80huaffelr7miin6vcd8u03vjnalk3@4ax.com...
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ?
Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de l'allocation
non libérée mais avec les boucles, les récursion ou les méthodes imbriquées,
l'indication de la ligne fautive ne suffit plus. On en vient vite à
rechercher d'autres solutions qui précisent le contexte dans lequel
l'allocation à eut lieu.
Si je parviens à customiser la classe de façon à enregistrer des éléments de
contexte, le débuggage sera plus rapide (enfin j'espère:-).
"Pierre Maurette" a écrit dans le message de news:
"J-C.gibier" typa:
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ? Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de l'allocation non libérée mais avec les boucles, les récursion ou les méthodes imbriquées, l'indication de la ligne fautive ne suffit plus. On en vient vite à rechercher d'autres solutions qui précisent le contexte dans lequel l'allocation à eut lieu. Si je parviens à customiser la classe de façon à enregistrer des éléments de contexte, le débuggage sera plus rapide (enfin j'espère:-).
J-C.gibier
"damien gautherin" a écrit dans le message de news:c6odam$kln$
memproof et MemorySleuth font ce genre de chose
Je regarde ça. Merci.
"damien gautherin" <spam@xpow.org> a écrit dans le message de
news:c6odam$kln$1@aphrodite.grec.isp.9tel.net...
"damien gautherin" a écrit dans le message de news:c6odam$kln$
memproof et MemorySleuth font ce genre de chose
Je regarde ça. Merci.
kanze
"J-C.gibier" wrote in message news:<408fc0fa$0$15659$...
"Pierre Maurette" a écrit dans le message de news:
"J-C.gibier" typa:
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ? Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de l'allocation non libérée mais avec les boucles, les récursion ou les méthodes imbriquées, l'indication de la ligne fautive ne suffit plus. On en vient vite à rechercher d'autres solutions qui précisent le contexte dans lequel l'allocation à eut lieu.
Je doute qu'il y ait un programme qui afficherait la ligne de code où tu aurais du libérer la mémoire. Le mieux qu'on peut espérer, c'est bien les informations sur où la mémoire a été allouée. Chez moi, il y a GB_MemoryCheck, qui peut afficher la trace de la pile au moment de l'allocation. Je développe actuellement sur Sparc, mais il y a aussi des versions pour Linux sur Intel à ma site. A priori, une porte vers Windows ne doit pas être trop difficile. (J'ai de nouveau accès à une machine Windows ; c'est donc prévu de ma part. Mais je ne sais pas quand. Mon client est toujours plus intéressé par ce que je fais sur Sparc, voire sous Linux.)
Si je parviens à customiser la classe de façon à enregistrer des éléments de contexte, le débuggage sera plus rapide (enfin j'espère:-).
Il y a deux problèmes à résoudre : comment saisir le contexte sur la pile, et comment l'interpréter. Pour le premier, il n'y a pas de solution portable, et il se peut que même avec la version Linux sur Intel, il faudrait rétoucher le fichier StackTrace.mcc (où se trouve le code qui rémonte la pile en sauvegardant les adresses de rétour).
Quant à l'interprétation : pour l'instant, je n'ai pas cherché loin. Je sors les adresses en hexadécimal, et quand j'en ai besoin, je tire un « map » (sous Unix, avec la commande nm, mais si je me rappelle bien, sous Windows, il faut le démander à l'éditeur de liens). En principe, on doit pouvoir trouver ce genre d'information dans les informations de déboggage de l'executable, mais c'est pas mal du boulot, et dans la pratique, je n'en ai besoin qu'une ou deux fois par an, maximum.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"J-C.gibier" <jeancharlesg_RMVTHIS_@free.fr> wrote in message
news:<408fc0fa$0$15659$626a14ce@news.free.fr>...
"Pierre Maurette" <maurette.pierreAT@ATfree.fr> a écrit dans le
message de news:lvev80huaffelr7miin6vcd8u03vjnalk3@4ax.com...
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ?
Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de
l'allocation non libérée mais avec les boucles, les récursion ou les
méthodes imbriquées, l'indication de la ligne fautive ne suffit
plus. On en vient vite à rechercher d'autres solutions qui précisent
le contexte dans lequel l'allocation à eut lieu.
Je doute qu'il y ait un programme qui afficherait la ligne de code où tu
aurais du libérer la mémoire. Le mieux qu'on peut espérer, c'est bien
les informations sur où la mémoire a été allouée. Chez moi, il y a
GB_MemoryCheck, qui peut afficher la trace de la pile au moment de
l'allocation. Je développe actuellement sur Sparc, mais il y a aussi des
versions pour Linux sur Intel à ma site. A priori, une porte vers
Windows ne doit pas être trop difficile. (J'ai de nouveau accès à une
machine Windows ; c'est donc prévu de ma part. Mais je ne sais pas
quand. Mon client est toujours plus intéressé par ce que je fais sur
Sparc, voire sous Linux.)
Si je parviens à customiser la classe de façon à enregistrer des
éléments de contexte, le débuggage sera plus rapide (enfin
j'espère:-).
Il y a deux problèmes à résoudre : comment saisir le contexte sur la
pile, et comment l'interpréter. Pour le premier, il n'y a pas de
solution portable, et il se peut que même avec la version Linux sur
Intel, il faudrait rétoucher le fichier StackTrace.mcc (où se trouve le
code qui rémonte la pile en sauvegardant les adresses de rétour).
Quant à l'interprétation : pour l'instant, je n'ai pas cherché loin. Je
sors les adresses en hexadécimal, et quand j'en ai besoin, je tire un
« map » (sous Unix, avec la commande nm, mais si je me rappelle bien,
sous Windows, il faut le démander à l'éditeur de liens). En principe, on
doit pouvoir trouver ce genre d'information dans les informations de
déboggage de l'executable, mais c'est pas mal du boulot, et dans la
pratique, je n'en ai besoin qu'une ou deux fois par an, maximum.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"J-C.gibier" wrote in message news:<408fc0fa$0$15659$...
"Pierre Maurette" a écrit dans le message de news:
"J-C.gibier" typa:
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ? Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de l'allocation non libérée mais avec les boucles, les récursion ou les méthodes imbriquées, l'indication de la ligne fautive ne suffit plus. On en vient vite à rechercher d'autres solutions qui précisent le contexte dans lequel l'allocation à eut lieu.
Je doute qu'il y ait un programme qui afficherait la ligne de code où tu aurais du libérer la mémoire. Le mieux qu'on peut espérer, c'est bien les informations sur où la mémoire a été allouée. Chez moi, il y a GB_MemoryCheck, qui peut afficher la trace de la pile au moment de l'allocation. Je développe actuellement sur Sparc, mais il y a aussi des versions pour Linux sur Intel à ma site. A priori, une porte vers Windows ne doit pas être trop difficile. (J'ai de nouveau accès à une machine Windows ; c'est donc prévu de ma part. Mais je ne sais pas quand. Mon client est toujours plus intéressé par ce que je fais sur Sparc, voire sous Linux.)
Si je parviens à customiser la classe de façon à enregistrer des éléments de contexte, le débuggage sera plus rapide (enfin j'espère:-).
Il y a deux problèmes à résoudre : comment saisir le contexte sur la pile, et comment l'interpréter. Pour le premier, il n'y a pas de solution portable, et il se peut que même avec la version Linux sur Intel, il faudrait rétoucher le fichier StackTrace.mcc (où se trouve le code qui rémonte la pile en sauvegardant les adresses de rétour).
Quant à l'interprétation : pour l'instant, je n'ai pas cherché loin. Je sors les adresses en hexadécimal, et quand j'en ai besoin, je tire un « map » (sous Unix, avec la commande nm, mais si je me rappelle bien, sous Windows, il faut le démander à l'éditeur de liens). En principe, on doit pouvoir trouver ce genre d'information dans les informations de déboggage de l'executable, mais c'est pas mal du boulot, et dans la pratique, je n'en ai besoin qu'une ou deux fois par an, maximum.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J-C.gibier
a écrit dans le message de news:
"J-C.gibier" wrote in message news:<408fc0fa$0$15659$...
"Pierre Maurette" a écrit dans le message de news:
"J-C.gibier" typa:
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ? Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de l'allocation non libérée mais avec les boucles, les récursion ou les méthodes imbriquées, l'indication de la ligne fautive ne suffit plus. On en vient vite à rechercher d'autres solutions qui précisent le contexte dans lequel l'allocation à eut lieu.
Je doute qu'il y ait un programme qui afficherait la ligne de code où tu aurais du libérer la mémoire. Le mieux qu'on peut espérer, c'est bien les informations sur où la mémoire a été allouée. Chez moi, il y a GB_MemoryCheck, qui peut afficher la trace de la pile au moment de l'allocation. Je développe actuellement sur Sparc, mais il y a aussi des versions pour Linux sur Intel à ma site. A priori, une porte vers Windows ne doit pas être trop difficile. (J'ai de nouveau accès à une machine Windows ; c'est donc prévu de ma part. Mais je ne sais pas quand. Mon client est toujours plus intéressé par ce que je fais sur Sparc, voire sous Linux.)
[...]
Intéressant, mais je ne sais pas si j'aurai la carure requise pour travailler sur cette classe ;-) Lorsque je parlais de contexte je voulais pas parler du contexte de pile mais simplement d'une mémorisation de certaines variables du programme, chose que ne peut faire Codeguard (pour autant que je sache). Ceci dit si les sources sont disponibles et qu'il y a matière à contribuer ne serait ce qu'en testant je le ferais avec plaisir.
JCG
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0404290139.2191d789@posting.google.com...
"J-C.gibier" <jeancharlesg_RMVTHIS_@free.fr> wrote in message
news:<408fc0fa$0$15659$626a14ce@news.free.fr>...
"Pierre Maurette" <maurette.pierreAT@ATfree.fr> a écrit dans le
message de news:lvev80huaffelr7miin6vcd8u03vjnalk3@4ax.com...
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ?
Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de
l'allocation non libérée mais avec les boucles, les récursion ou les
méthodes imbriquées, l'indication de la ligne fautive ne suffit
plus. On en vient vite à rechercher d'autres solutions qui précisent
le contexte dans lequel l'allocation à eut lieu.
Je doute qu'il y ait un programme qui afficherait la ligne de code où tu
aurais du libérer la mémoire. Le mieux qu'on peut espérer, c'est bien
les informations sur où la mémoire a été allouée. Chez moi, il y a
GB_MemoryCheck, qui peut afficher la trace de la pile au moment de
l'allocation. Je développe actuellement sur Sparc, mais il y a aussi des
versions pour Linux sur Intel à ma site. A priori, une porte vers
Windows ne doit pas être trop difficile. (J'ai de nouveau accès à une
machine Windows ; c'est donc prévu de ma part. Mais je ne sais pas
quand. Mon client est toujours plus intéressé par ce que je fais sur
Sparc, voire sous Linux.)
[...]
Intéressant, mais je ne sais pas si j'aurai la carure requise pour
travailler sur cette classe ;-)
Lorsque je parlais de contexte je voulais pas parler du contexte de pile
mais simplement d'une mémorisation de certaines variables du programme,
chose que ne peut faire Codeguard (pour autant que je sache). Ceci dit si
les sources sont disponibles et qu'il y a matière à contribuer ne serait ce
qu'en testant je le ferais avec plaisir.
"J-C.gibier" wrote in message news:<408fc0fa$0$15659$...
"Pierre Maurette" a écrit dans le message de news:
"J-C.gibier" typa:
Pourquoi n'utilisez-vous pas Codeguard, intégré dans C++Builder ? Il signale les fuites et situe leur origine.
Codeguard indique effectivement (mais pas toujours) la ligne de l'allocation non libérée mais avec les boucles, les récursion ou les méthodes imbriquées, l'indication de la ligne fautive ne suffit plus. On en vient vite à rechercher d'autres solutions qui précisent le contexte dans lequel l'allocation à eut lieu.
Je doute qu'il y ait un programme qui afficherait la ligne de code où tu aurais du libérer la mémoire. Le mieux qu'on peut espérer, c'est bien les informations sur où la mémoire a été allouée. Chez moi, il y a GB_MemoryCheck, qui peut afficher la trace de la pile au moment de l'allocation. Je développe actuellement sur Sparc, mais il y a aussi des versions pour Linux sur Intel à ma site. A priori, une porte vers Windows ne doit pas être trop difficile. (J'ai de nouveau accès à une machine Windows ; c'est donc prévu de ma part. Mais je ne sais pas quand. Mon client est toujours plus intéressé par ce que je fais sur Sparc, voire sous Linux.)
[...]
Intéressant, mais je ne sais pas si j'aurai la carure requise pour travailler sur cette classe ;-) Lorsque je parlais de contexte je voulais pas parler du contexte de pile mais simplement d'une mémorisation de certaines variables du programme, chose que ne peut faire Codeguard (pour autant que je sache). Ceci dit si les sources sont disponibles et qu'il y a matière à contribuer ne serait ce qu'en testant je le ferais avec plaisir.
JCG
Mathieu Roger
Bonjour, J'ai cherché (un peu mais à tout les coups je suis passé au travers) dans la faq pour voir s'il n'y avait pas de références pour ce problème récurrent. Je cherche précisément un classe (ou un recette, ou un listing) pas trop lourde simple à implémenter, n'ayant pas de contrindications avec Builder pour sauver quelques heures de travail (et quelques cheveux) sur un projet.
Merci JCG
regardez dans http://www.philippe.prados.name/ il y a des classes de pointeurs de composition qui permettent de gérer la mémoire de manière très élégante
Bonjour,
J'ai cherché (un peu mais à tout les coups je suis passé au travers)
dans la faq pour voir s'il n'y avait pas de références pour ce problème
récurrent.
Je cherche précisément un classe (ou un recette, ou un listing) pas trop
lourde simple à implémenter, n'ayant pas de contrindications avec Builder
pour sauver quelques heures de travail (et quelques cheveux) sur un projet.
Merci
JCG
regardez dans http://www.philippe.prados.name/ il y a des classes de
pointeurs de composition qui permettent de gérer la mémoire de manière
très élégante
Bonjour, J'ai cherché (un peu mais à tout les coups je suis passé au travers) dans la faq pour voir s'il n'y avait pas de références pour ce problème récurrent. Je cherche précisément un classe (ou un recette, ou un listing) pas trop lourde simple à implémenter, n'ayant pas de contrindications avec Builder pour sauver quelques heures de travail (et quelques cheveux) sur un projet.
Merci JCG
regardez dans http://www.philippe.prados.name/ il y a des classes de pointeurs de composition qui permettent de gérer la mémoire de manière très élégante
kanze
Mathieu Roger wrote in message news:<40b07f24$0$19646$...
J'ai cherché (un peu mais à tout les coups je suis passé au travers) dans la faq pour voir s'il n'y avait pas de références pour ce problème récurrent.
Je cherche précisément un classe (ou un recette, ou un listing) pas trop lourde simple à implémenter, n'ayant pas de contrindications avec Builder pour sauver quelques heures de travail (et quelques cheveux) sur un projet.
regardez dans http://www.philippe.prados.name/ il y a des classes de pointeurs de composition qui permettent de gérer la mémoire de manière très élégante
Tiens, il te paie pour faire de la pub.
J'y ai jeté un coup d'oeil ; ce n'est pas terrible. Si c'est vrai qu'il y en a pire, j'ai quand même relevé plusieurs erreurs de C++, ce qui ne s'excuse pas dans une site dont la vocation est d'enseigner le C++. Et certaines de ses solutions de conception sont pour le moins douteuses.
Je n'ai pas trouvé les pointeurs dont tu parles, mais s'il s'agit des pointeurs intelligents au comptage de référence, il faut d'abord régarder de côté de Boost, et sinon, utiliser plus ou moins ce que décrit Scott Meyers. (J'ai une implémentation de ce que décrit Scott Meyers sur mon site. Mais comme j'ai dit, c'est surtout intéressant pour le cas où tu ne peux pas te servir de Boost.)
-- James Kanze GABI Software 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
Mathieu Roger <mathieu.roger@imag.fr> wrote in message
news:<40b07f24$0$19646$626a14ce@news.free.fr>...
J'ai cherché (un peu mais à tout les coups je suis passé au
travers) dans la faq pour voir s'il n'y avait pas de références pour
ce problème récurrent.
Je cherche précisément un classe (ou un recette, ou un listing) pas
trop lourde simple à implémenter, n'ayant pas de contrindications
avec Builder pour sauver quelques heures de travail (et quelques
cheveux) sur un projet.
regardez dans http://www.philippe.prados.name/ il y a des classes de
pointeurs de composition qui permettent de gérer la mémoire de manière
très élégante
Tiens, il te paie pour faire de la pub.
J'y ai jeté un coup d'oeil ; ce n'est pas terrible. Si c'est vrai qu'il
y en a pire, j'ai quand même relevé plusieurs erreurs de C++, ce qui ne
s'excuse pas dans une site dont la vocation est d'enseigner le C++. Et
certaines de ses solutions de conception sont pour le moins douteuses.
Je n'ai pas trouvé les pointeurs dont tu parles, mais s'il s'agit des
pointeurs intelligents au comptage de référence, il faut d'abord
régarder de côté de Boost, et sinon, utiliser plus ou moins ce que
décrit Scott Meyers. (J'ai une implémentation de ce que décrit Scott
Meyers sur mon site. Mais comme j'ai dit, c'est surtout intéressant pour
le cas où tu ne peux pas te servir de Boost.)
--
James Kanze GABI Software
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
Mathieu Roger wrote in message news:<40b07f24$0$19646$...
J'ai cherché (un peu mais à tout les coups je suis passé au travers) dans la faq pour voir s'il n'y avait pas de références pour ce problème récurrent.
Je cherche précisément un classe (ou un recette, ou un listing) pas trop lourde simple à implémenter, n'ayant pas de contrindications avec Builder pour sauver quelques heures de travail (et quelques cheveux) sur un projet.
regardez dans http://www.philippe.prados.name/ il y a des classes de pointeurs de composition qui permettent de gérer la mémoire de manière très élégante
Tiens, il te paie pour faire de la pub.
J'y ai jeté un coup d'oeil ; ce n'est pas terrible. Si c'est vrai qu'il y en a pire, j'ai quand même relevé plusieurs erreurs de C++, ce qui ne s'excuse pas dans une site dont la vocation est d'enseigner le C++. Et certaines de ses solutions de conception sont pour le moins douteuses.
Je n'ai pas trouvé les pointeurs dont tu parles, mais s'il s'agit des pointeurs intelligents au comptage de référence, il faut d'abord régarder de côté de Boost, et sinon, utiliser plus ou moins ce que décrit Scott Meyers. (J'ai une implémentation de ce que décrit Scott Meyers sur mon site. Mais comme j'ai dit, c'est surtout intéressant pour le cas où tu ne peux pas te servir de Boost.)
-- James Kanze GABI Software 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
