Threads et C++

Pas dans le cas d'utilisation de certaines libs, ou quand tu veux budgetter tes diff�rentes parties...

Un article de blog (en fran�ais) et des commentaires tr�s interessants sur le sujet : http://jeremy.chatelaine.name/blog/?p=36

L'article pr�sentant la EASTL a un chapitre r�sumant des contraintes qu'on a aussi dans le jeu vid�o, et qui expliquent les modifications/ajouts qu'ils proposent.

Pouvoir appeler le constructeur et le destructeur manuellement est bien entendu tr�s int�ressant d�s qu'on a d�j� la m�moire sur laquelle on veut placer l'objet...
Par exemple, comment impl�menter sans allocation dynamique boost::optional sans �a ?

Citation:

---

Envoy� par Profman

La franchement c'est ce que j'appel de la grosse bidouille !!

---

Non, c'est une technique de bas niveau utile pour impl�menter certaines abstractions, ce n'est pas tout a fait la m�me chose. A nouveau, impl�mente quelque chose de similaire a vector sans cela.

Citation:

---

De plus je ne vois pas l'int�r�t de ce code : allouer la taille de la string avec "malloc', appeler le destructeur explicitement et lib�rer avec "free" trop fort.

Pourquoi ne pas utiliser que "new" et "delete" c'est fait pour �a : �a alloue et appel les bons m�canismes au bon moment.

---

Il y a une diff�rence entre montrer comme mettre en �uvre une technique et expliquer dans quel contexte il faut le faire. J'�tais a mon avis clairement dans le premier cas. J'aurais pu utiliser ::operator new() et ::operator delete() a la place de malloc et free, �a n'aurais rien change sur le fond ni sur ce que je voulais montrer, et �a introduisait quelque chose de plus qui risquait d'�tre non familier a certains.

Citation:

---

Envoy� par deadalnix

Une surcharge de new et delete sera plus �l�gante dans une telle situation.

---

Je ne fais pas tricher et te demander une impl�mentation conforme de vector qui n'utilise pas cette technique (les specs de l'allocateur l'impose :-)) mais j'aimerais bien voir comment tu impl�menterais �l�gamment et sans appel explicite au destructeur un pop_back qui d�truit bien sans lib�rer la m�moire. Je vois bien un moyen ou deux, mais �a me semble tous des hacks bien plus gros que l'appel explicite au destructeur, �a revient fondamentalement � cela et je ne suis m�me pas sur de la conformit� formelle d'un d�tail.

+1 avec jean marc, boost::variant, boost::optional et std::vector sont des exemples typiques de ce genre de chose. Ca arrive de le faire, c'est pour ca que le placement new existe.

new -> delete
new[] -> delete []
new(void*) -> ~T()

Un truc que j'aimerais bien savoir, c'est si ce code est garanti marcher, ou bien s'il faut syst�matiquement faire les deux appels.

Je me doute que pour un tableau, c'est � ne surtout pas faire, mais pour un seul objet ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

class Nimp { public: int m_value;   Nimp(int value); ~Nimp(void); };   void TestNew(void) { Nimp *pNimp = static_cast< Nimp * >(::operator new(sizeof(Nimp))); new(pNimp) Nimp(42);   //Test: Un simple delete au lieu de appel au destructeur + operator delete delete pNimp; }   Nimp::Nimp(int value) : m_value(value) { std::cout << "<Nimp ctor=\"" << m_value << "\">" << std::endl; } Nimp::~Nimp(void) { std::cout << "</Nimp>" << std::endl; }

---

En tout cas, ca marche chez moi avec VC. En fait, je dirais que ca marche � partir du moment o� tu remplit les conditions suivantes:
-> La zone m�moire a �t� correctement initialis� au regarde de l'objet, i.d. t'es pass� au - une fois dans un constructeur de Nimp, ---> donc l'appel au destructeur se fera avec un objet valide
-> La zone m�moire a �t� allou�e de fa�on compatible avec le 'free' li� au delete ---> le delete sait lib�rer la m�moire.

Citation:

---

Envoy� par M�dinoc

Un truc que j'aimerais bien savoir, c'est si ce code est garanti marcher, ou bien s'il faut syst�matiquement faire les deux appels.

---

A priori c'est conforme tant que tu n'as pas d'operator delete dans la classe ou une classe de base.

Merci.