Discussion :

[Klaim]

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.

[loufoque]

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 ?

[Jean-Marc.Bourguet]

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.

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.

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.

[screetch]

+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()

[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.

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

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
}

[3DArchi]

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.

[Jean-Marc.Bourguet]

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.

[Médinoc]

Merci.