Comment "delete" connait-il la taille du block à désallouer ? (question dans le cadre d'une surcharge de l'opérateur delete)
Tout le monde t'a déjà répondu sur les différentes méthodes envisageables, mais si c'est pour surcharger l'opérateur delete, tu n'as pas à t'en soucier : Tu as le droit de fournir une des 2 versions suivantes de l'operateur delete : - void operator delete (void* p); - void operator delete(void* p, std::size_t size);
Si tu fournis la 2ème version, c'est à l'implémentation de te fournir la taille correcte de la zone pointée.
Arnaud
Bonjour,
Comment "delete" connait-il la taille du block à désallouer ?
(question dans le cadre d'une surcharge de l'opérateur delete)
Tout le monde t'a déjà répondu sur les différentes méthodes
envisageables, mais si c'est pour surcharger l'opérateur delete, tu
n'as pas à t'en soucier : Tu as le droit de fournir une des 2 versions
suivantes de l'operateur delete :
- void operator delete (void* p);
- void operator delete(void* p, std::size_t size);
Si tu fournis la 2ème version, c'est à l'implémentation de te
fournir la taille correcte de la zone pointée.
Comment "delete" connait-il la taille du block à désallouer ? (question dans le cadre d'une surcharge de l'opérateur delete)
Tout le monde t'a déjà répondu sur les différentes méthodes envisageables, mais si c'est pour surcharger l'opérateur delete, tu n'as pas à t'en soucier : Tu as le droit de fournir une des 2 versions suivantes de l'operateur delete : - void operator delete (void* p); - void operator delete(void* p, std::size_t size);
Si tu fournis la 2ème version, c'est à l'implémentation de te fournir la taille correcte de la zone pointée.
Arnaud
kanze
nico wrote:
Je n'avais pas pensé, par contre, à un système d'entête comme tu le suggères,
C'est quand même quasi universel. La norme permet tout, mais dans la pratique, je ne connais pas d'implémentation qui ne se sert pas des données cachées devant l'adresse renvoyée par malloc.
j'avoue que ca serait une bonne idée car on a plus à stocker l'adresse, et donc, si j'ai bien compris ce que tu as voulu dire, un block aurait cette tete :
[[taille sur un int][data]]
Je vais essayer comme ca (sauf si vous avez encore mieux :) ).
Il faut faire gaffe aux contraints de l'alignement, quand même. Sur les systèmes que j'utilise, au moins, la taille d'un int, c'est 4, mais les doubles ont besoin d'un alignement de 8.
Sinon, c'est une solution éprouée.
-- 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
nico wrote:
Je n'avais pas pensé, par contre, à un système d'entête comme
tu le suggères,
C'est quand même quasi universel. La norme permet tout, mais
dans la pratique, je ne connais pas d'implémentation qui ne se
sert pas des données cachées devant l'adresse renvoyée par
malloc.
j'avoue que ca serait une bonne idée car on a plus à stocker
l'adresse, et donc, si j'ai bien compris ce que tu as voulu
dire, un block aurait cette tete :
[[taille sur un int][data]]
Je vais essayer comme ca (sauf si vous avez encore mieux :) ).
Il faut faire gaffe aux contraints de l'alignement, quand même.
Sur les systèmes que j'utilise, au moins, la taille d'un int,
c'est 4, mais les doubles ont besoin d'un alignement de 8.
Sinon, c'est une solution éprouée.
--
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
Je n'avais pas pensé, par contre, à un système d'entête comme tu le suggères,
C'est quand même quasi universel. La norme permet tout, mais dans la pratique, je ne connais pas d'implémentation qui ne se sert pas des données cachées devant l'adresse renvoyée par malloc.
j'avoue que ca serait une bonne idée car on a plus à stocker l'adresse, et donc, si j'ai bien compris ce que tu as voulu dire, un block aurait cette tete :
[[taille sur un int][data]]
Je vais essayer comme ca (sauf si vous avez encore mieux :) ).
Il faut faire gaffe aux contraints de l'alignement, quand même. Sur les systèmes que j'utilise, au moins, la taille d'un int, c'est 4, mais les doubles ont besoin d'un alignement de 8.
Sinon, c'est une solution éprouée.
-- 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
kanze
wrote:
Comment "delete" connait-il la taille du block à désallouer ? (question dans le cadre d'une surcharge de l'opérateur delete)
Tout le monde t'a déjà répondu sur les différentes méthodes envisageables, mais si c'est pour surcharger l'opérateur delete, tu n'as pas à t'en soucier : Tu as le droit de fournir une des 2 versions suivantes de l'operateur delete :
Si tu fournis la 2ème version, c'est à l'implémentation de te fournir la taille correcte de la zone pointée.
D'où est-ce que tu tires ça ? Parce qu'il n'y en a pas mention dans la section §18.4 de la norme. Est-ce que tu ne serais pas en train de confondre avec les operator delete membre (où c'est bien le cas) ?
-- 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
adebaene@club-internet.fr wrote:
Comment "delete" connait-il la taille du block à désallouer
? (question dans le cadre d'une surcharge de l'opérateur
delete)
Tout le monde t'a déjà répondu sur les différentes méthodes
envisageables, mais si c'est pour surcharger l'opérateur
delete, tu n'as pas à t'en soucier : Tu as le droit de fournir
une des 2 versions suivantes de l'operateur delete :
Si tu fournis la 2ème version, c'est à l'implémentation de te
fournir la taille correcte de la zone pointée.
D'où est-ce que tu tires ça ? Parce qu'il n'y en a pas mention
dans la section §18.4 de la norme. Est-ce que tu ne serais pas
en train de confondre avec les operator delete membre (où c'est
bien le cas) ?
--
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
Comment "delete" connait-il la taille du block à désallouer ? (question dans le cadre d'une surcharge de l'opérateur delete)
Tout le monde t'a déjà répondu sur les différentes méthodes envisageables, mais si c'est pour surcharger l'opérateur delete, tu n'as pas à t'en soucier : Tu as le droit de fournir une des 2 versions suivantes de l'operateur delete :
Si tu fournis la 2ème version, c'est à l'implémentation de te fournir la taille correcte de la zone pointée.
D'où est-ce que tu tires ça ? Parce qu'il n'y en a pas mention dans la section §18.4 de la norme. Est-ce que tu ne serais pas en train de confondre avec les operator delete membre (où c'est bien le cas) ?
-- 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
Laurent Deniau
wrote:
nico wrote:
Comment "delete" connait-il la taille du block à désallouer ? (question dans le cadre d'une surcharge de l'opérateur delete)
void operator delete(void * obj) { //ici sizeof(obj) renvoie une taille incorrecte // dans le cadre d'héritage...
Même sans l'héritage:-). La taille d'un void* ne change pas beaucoup.
}
C'est le problème de l'implementation ; si elle a besoin de la taille, il faut qu'elle puisse le retrouver à partir de l'adresse.
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p = obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
a+, ld.
kanze@gabi-soft.fr wrote:
nico wrote:
Comment "delete" connait-il la taille du block à désallouer ?
(question dans le cadre d'une surcharge de l'opérateur delete)
void operator delete(void * obj)
{
//ici sizeof(obj) renvoie une taille incorrecte
// dans le cadre d'héritage...
Même sans l'héritage:-). La taille d'un void* ne change pas
beaucoup.
}
C'est le problème de l'implementation ; si elle a besoin de la
taille, il faut qu'elle puisse le retrouver à partir de
l'adresse.
Typiquement, l'implémentation va utiliser un en-tête au bloc,
avec toutes les informations dont elle a besoin. Au retour de
new, elle va faire « return p + quelqueChose », et la première
chose qu'elle va faire en delete, c'est « p = obj -
quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place
memoire. Il y a de nombreuses alternatives bien plus efficace ou la
taille est centralisee par arena/pool/allocator.
Comment "delete" connait-il la taille du block à désallouer ? (question dans le cadre d'une surcharge de l'opérateur delete)
void operator delete(void * obj) { //ici sizeof(obj) renvoie une taille incorrecte // dans le cadre d'héritage...
Même sans l'héritage:-). La taille d'un void* ne change pas beaucoup.
}
C'est le problème de l'implementation ; si elle a besoin de la taille, il faut qu'elle puisse le retrouver à partir de l'adresse.
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p = obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
a+, ld.
kanze
Laurent Deniau wrote:
wrote:
[...]
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p = obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore dans pas mal d'implémentations de malloc. Gérer plusieurs pools, c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que même avec des pools distincts, on utilise des informations devant le block pour retrouver le pool lors des deletes.)
-- 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
Laurent Deniau wrote:
kanze@gabi-soft.fr wrote:
[...]
Typiquement, l'implémentation va utiliser un en-tête au
bloc, avec toutes les informations dont elle a besoin. Au
retour de new, elle va faire « return p + quelqueChose », et
la première chose qu'elle va faire en delete, c'est « p =
obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en
place memoire. Il y a de nombreuses alternatives bien plus
efficace ou la taille est centralisee par
arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore
dans pas mal d'implémentations de malloc. Gérer plusieurs pools,
c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que
même avec des pools distincts, on utilise des informations
devant le block pour retrouver le pool lors des deletes.)
--
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
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p = obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore dans pas mal d'implémentations de malloc. Gérer plusieurs pools, c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que même avec des pools distincts, on utilise des informations devant le block pour retrouver le pool lors des deletes.)
-- 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
Laurent Deniau
wrote:
Laurent Deniau wrote:
wrote:
[...]
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p >>>obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore dans pas mal d'implémentations de malloc. Gérer plusieurs pools, c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que même avec des pools distincts, on utilise des informations devant le block pour retrouver le pool lors des deletes.)
En general ce n'est pas la peine parce que le bloc (l'objet) se trouve dans une page (un gros bloc) dediee a cette taille de bloc et qui est alignee sur une certaine adresse (typiquement 4K ou 8K). Donc un simple masque permet de retrouver le debut de page ou se trouve les informations, notament une reference sur le pool et quelques autres infos.
Je suppose que je ne t'apprends rien ;-) mais en ce moment on est entrain de reecrire la gestion memoire de OOC pour etre tres rapide, y compris en multi threads (2x 0T et 5x MT plus rapide que la derniere version de malloc de glibc). Alors je ne pouvais pas manquer de l'ouvrir ;-)
a+, ld.
kanze@gabi-soft.fr wrote:
Laurent Deniau wrote:
kanze@gabi-soft.fr wrote:
[...]
Typiquement, l'implémentation va utiliser un en-tête au
bloc, avec toutes les informations dont elle a besoin. Au
retour de new, elle va faire « return p + quelqueChose », et
la première chose qu'elle va faire en delete, c'est « p >>>obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en
place memoire. Il y a de nombreuses alternatives bien plus
efficace ou la taille est centralisee par
arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore
dans pas mal d'implémentations de malloc. Gérer plusieurs pools,
c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que
même avec des pools distincts, on utilise des informations
devant le block pour retrouver le pool lors des deletes.)
En general ce n'est pas la peine parce que le bloc (l'objet) se trouve
dans une page (un gros bloc) dediee a cette taille de bloc et qui est
alignee sur une certaine adresse (typiquement 4K ou 8K). Donc un simple
masque permet de retrouver le debut de page ou se trouve les
informations, notament une reference sur le pool et quelques autres infos.
Je suppose que je ne t'apprends rien ;-) mais en ce moment on est
entrain de reecrire la gestion memoire de OOC pour etre tres rapide, y
compris en multi threads (2x 0T et 5x MT plus rapide que la derniere
version de malloc de glibc). Alors je ne pouvais pas manquer de l'ouvrir ;-)
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p >>>obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore dans pas mal d'implémentations de malloc. Gérer plusieurs pools, c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que même avec des pools distincts, on utilise des informations devant le block pour retrouver le pool lors des deletes.)
En general ce n'est pas la peine parce que le bloc (l'objet) se trouve dans une page (un gros bloc) dediee a cette taille de bloc et qui est alignee sur une certaine adresse (typiquement 4K ou 8K). Donc un simple masque permet de retrouver le debut de page ou se trouve les informations, notament une reference sur le pool et quelques autres infos.
Je suppose que je ne t'apprends rien ;-) mais en ce moment on est entrain de reecrire la gestion memoire de OOC pour etre tres rapide, y compris en multi threads (2x 0T et 5x MT plus rapide que la derniere version de malloc de glibc). Alors je ne pouvais pas manquer de l'ouvrir ;-)
a+, ld.
kanze
Laurent Deniau wrote:
wrote:
Laurent Deniau wrote:
wrote:
[...]
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p = obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore dans pas mal d'implémentations de malloc. Gérer plusieurs pools, c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que même avec des pools distincts, on utilise des informations devant le block pour retrouver le pool lors des deletes.)
En general ce n'est pas la peine parce que le bloc (l'objet) se trouve dans une page (un gros bloc) dediee a cette taille de bloc et qui est alignee sur une certaine adresse (typiquement 4K ou 8K). Donc un simple masque permet de retrouver le debut de page ou se trouve les informations, notament une reference sur le pool et quelques autres infos.
C'est une solution possible. Pour diverses raisons, ce n'est pas la solution adoptée par Sun, par exemple. C'est peut-être lié au fait qu'on n'a pas de requête sous Unix pour obtenir de la mémoire alignée du système. Alors, le malloc par defaut de Sun régroupe bien les allocations d'une taille donnée dans un bloc, au moins pour les petites allocations (avec, apparament, une gestion optimisée avec liste chaînée), mais il met bien la longueur (ainsi qu'un drappeau d'allocation) caché avant chaque allocation.
Je suppose que je ne t'apprends rien ;-) mais en ce moment on est entrain de reecrire la gestion memoire de OOC pour etre tres rapide, y compris en multi threads (2x 0T et 5x MT plus rapide que la derniere version de malloc de glibc). Alors je ne pouvais pas manquer de l'ouvrir ;-)
Les threads introduisent encore une complication, parce que les locks sont pas gratuits non-plus. Mais encore, je ne cherchais pas à indiquer l'algorithmes le plus performant (qui dépend en fait de l'usage qu'on en fait), mais une solution simple à quelqu'un qui ne donne pas l'impression d'être un expert sur le sujet. Ensuite, s'il s'y intéresse plus, une recherche avec Google lui donnera de quoi lire pour un moment.
-- 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
Laurent Deniau wrote:
kanze@gabi-soft.fr wrote:
Laurent Deniau wrote:
kanze@gabi-soft.fr wrote:
[...]
Typiquement, l'implémentation va utiliser un en-tête au
bloc, avec toutes les informations dont elle a besoin. Au
retour de new, elle va faire « return p + quelqueChose »,
et la première chose qu'elle va faire en delete, c'est « p
= obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en
place memoire. Il y a de nombreuses alternatives bien plus
efficace ou la taille est centralisee par
arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert
encore dans pas mal d'implémentations de malloc. Gérer
plusieurs pools, c'est plus compliqué que n'en gerer qu'un.
(Il arrive aussi que même avec des pools distincts, on
utilise des informations devant le block pour retrouver le
pool lors des deletes.)
En general ce n'est pas la peine parce que le bloc (l'objet)
se trouve dans une page (un gros bloc) dediee a cette taille
de bloc et qui est alignee sur une certaine adresse
(typiquement 4K ou 8K). Donc un simple masque permet de
retrouver le debut de page ou se trouve les informations,
notament une reference sur le pool et quelques autres infos.
C'est une solution possible. Pour diverses raisons, ce n'est pas
la solution adoptée par Sun, par exemple. C'est peut-être lié au
fait qu'on n'a pas de requête sous Unix pour obtenir de la
mémoire alignée du système. Alors, le malloc par defaut de Sun
régroupe bien les allocations d'une taille donnée dans un bloc,
au moins pour les petites allocations (avec, apparament, une
gestion optimisée avec liste chaînée), mais il met bien la
longueur (ainsi qu'un drappeau d'allocation) caché avant chaque
allocation.
Je suppose que je ne t'apprends rien ;-) mais en ce moment on
est entrain de reecrire la gestion memoire de OOC pour etre
tres rapide, y compris en multi threads (2x 0T et 5x MT plus
rapide que la derniere version de malloc de glibc). Alors je
ne pouvais pas manquer de l'ouvrir ;-)
Les threads introduisent encore une complication, parce que les
locks sont pas gratuits non-plus. Mais encore, je ne cherchais
pas à indiquer l'algorithmes le plus performant (qui dépend en
fait de l'usage qu'on en fait), mais une solution simple à
quelqu'un qui ne donne pas l'impression d'être un expert sur le
sujet. Ensuite, s'il s'y intéresse plus, une recherche avec
Google lui donnera de quoi lire pour un moment.
--
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
Typiquement, l'implémentation va utiliser un en-tête au bloc, avec toutes les informations dont elle a besoin. Au retour de new, elle va faire « return p + quelqueChose », et la première chose qu'elle va faire en delete, c'est « p = obj - quelqueChose », pour pouvoir accéder à l'en-tête.
Cette approche est quelque peu ancienne et sous-optimale en place memoire. Il y a de nombreuses alternatives bien plus efficace ou la taille est centralisee par arena/pool/allocator.
Cette approche reste la plus simple à comprendre, et sert encore dans pas mal d'implémentations de malloc. Gérer plusieurs pools, c'est plus compliqué que n'en gerer qu'un. (Il arrive aussi que même avec des pools distincts, on utilise des informations devant le block pour retrouver le pool lors des deletes.)
En general ce n'est pas la peine parce que le bloc (l'objet) se trouve dans une page (un gros bloc) dediee a cette taille de bloc et qui est alignee sur une certaine adresse (typiquement 4K ou 8K). Donc un simple masque permet de retrouver le debut de page ou se trouve les informations, notament une reference sur le pool et quelques autres infos.
C'est une solution possible. Pour diverses raisons, ce n'est pas la solution adoptée par Sun, par exemple. C'est peut-être lié au fait qu'on n'a pas de requête sous Unix pour obtenir de la mémoire alignée du système. Alors, le malloc par defaut de Sun régroupe bien les allocations d'une taille donnée dans un bloc, au moins pour les petites allocations (avec, apparament, une gestion optimisée avec liste chaînée), mais il met bien la longueur (ainsi qu'un drappeau d'allocation) caché avant chaque allocation.
Je suppose que je ne t'apprends rien ;-) mais en ce moment on est entrain de reecrire la gestion memoire de OOC pour etre tres rapide, y compris en multi threads (2x 0T et 5x MT plus rapide que la derniere version de malloc de glibc). Alors je ne pouvais pas manquer de l'ouvrir ;-)
Les threads introduisent encore une complication, parce que les locks sont pas gratuits non-plus. Mais encore, je ne cherchais pas à indiquer l'algorithmes le plus performant (qui dépend en fait de l'usage qu'on en fait), mais une solution simple à quelqu'un qui ne donne pas l'impression d'être un expert sur le sujet. Ensuite, s'il s'y intéresse plus, une recherche avec Google lui donnera de quoi lire pour un moment.
-- 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
