Bonjour,
je voudrais utiliser le garbage collector de Boehm sur Linux avec la std. ... J'ai du zapper quelques étapes dans la compil du source car je n'arrive pas à le faire fonctionner.
Quelqu'un peut-il m'aider ?

bah -I/.../machin -lmachin
 
la routine. Mais ça marche très mal avec les destructeurs, car tu n'a pas l'assurance qu'ils soient appelés.

Merci pour ta réponse.
Mais bon,si mon souci est d'être sûr que la mémoire soit libérée lorsque je n'utilise plus un objet, Le GC-Boehm est quand même pas mal, non ?

bof. Tu utilises des smart pointer partout ? tu as viré tous tes char * ? s'il te reste la moindre gestion manuelle de la mémoire, alors t'as encore du travail.

je n'utilise pas de smart pointeurs. Peut-être que je devrais ...
En fait mon problème est le suivant :
j'ai une fonction que j'appelle souvent dans laquelle j'instancie un std:vector<matrice*> (matrice est une classe perso demandant beaucoup de mémoire).
D'après ce que je sais, à la sortie de la fonction, cette instance de vector est déréférencée ; mais je me rends compte que la mémoire n'est pas libérée. Donc, les smart pointeurs sont adaptés à ce cas  ?

absolument

zieutez tous aussi les nouveaux conteneurs de boost.

 
comment ça marche très mal ?
A la lecture des propositions d'inclusion de GC en standard. Il m'a semblé lire qu'aucun destructeur non trivial n'était appelé lorsqu'un objet alloué dynamiquement n'était plus référencé.
L'operateur delete garderait (malheureusement ?) un sens puisqu'il permettrait d'invoquer le destructeur.
Est-ce que le boehm est fait dans cette optique ? il me semble que oui, mais je ne l'ai pas essayé ...

bah ça fout en l'air le style RAII C++. Donc ça sert à rien.

ca sert a quoi d'etre obligé d'utiliser delete sur un objet pour en appeler le destructeur, pour ensuite laisser sa mémoire en vrac pour le GC ?

 
Si c'est ca ton pb, alors il te faut suivre le conseil de Taz : les matrices de Boost (par exemple), car ta classe matrice est probablement  mal concue. Un GC ou meme des smart pointers ne le resolveront pas.

 
tu donnes toi meme la réponse à ta question. delete invoque le destructeur, mais ne désalloue pas. Cette dernière tache est confiée au GC.

Je viens de l'essayer, et j'en suis très agréablement surpris.
ça fout pas le style RAII en l'air. Pour se servir du GC pour une classe donnée, la seule chose à faire est de masquer ::new , ::new[], ::delete, et ::delete[], en héritant publiquement de gc par exemple.  
Apres, tout est comme avant, on appelle toujours delete, sauf que secretement, la gestion de la mémoire n'est plus controlée par le programmeur, et il n'y a plus de fuites, tout au plus des absences d'appel de destructeur.
 
D'ailleurs au niveau perf, c'est pas catastrophique du tout. C'est meilleur que boost::shared_ptr<> dans pas mal de situation, notament dans le cas de petits objets, et dans les contextes multithreads.
 
La seule chose qui est bizarre, c'est que la classe gc ne soit pas dans un namespace, c'est hallucinant.

sauf qu'un destructeur, ça n'est pas qu'une histoire de mémoire.
 
(sinon je l'ai déjà essayé, et l'intégration C++ est bidon quand même).

entièrement d'accord. Je pense que ce n'est pas parce qu'on utilise le boehm que l'on est exempté d'appel au destructeur.
Comme tu le dis, la mémoire n'est pas la seule ressource que peut acquérir un objet.
 

Comment veux-tu faire autrement ? Tu sais bien que operator new et consorts ne peuvent etre surchargés qu'en tant que membre statique.