Discussion :

[quidimi]

Bonjour,

Voici mon problème :

Mon compilateur me dit qu'il n'arrive pas a convertir mon type class quand j'essaye d'ajouter un élément à ma map :

Code :

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

1
2
 
error C2664: 'std::pair<_Ty1,_Ty2>::pair<std::string&,maClass(void)>(_Other1,_Other2 (__cdecl &&))' : cannot convert parameter 2 from 'maClass(__cdecl *)(void)' to 'maClass(__cdecl &&)(void)'

Le code ressemble seulement à ceci et je ne vois pas où est l'erreur.

Code :

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

1
2
3
4
5
6
7
8
 
std::map<std::string, maClass> classList;
 
void AddClass(std::string _name)
{
	maClass temp();
	classList.insert(std::pair<std::string, maClass>(_name,temp)); 
}

Merci d'avance à tous

[Flob90]

Bonjour,

La réponse est dans la FaQ : http://cpp.developpez.com/faq/cpp/?p..._list_list_fct

[quidimi]

Merci

[Kaamui]

Tu créés un objet std::pair que tu veux insérer (insert prend en paramètre une référence constante de ton objet) dans ta classList, mais l'objet sera détruit à la sortie de ta fonction AddClass.

Essaie ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
std::map<std::string, maClass*> classMap;
 
void Add(const string name)
{
    //non exception-safe
    classMap[name] = new maClass();
    // OU
    //exception-safe (out of range)
    classMap.at(name) = new maClass();
 
    //dans les deux cas, la map sera responsable de la durée de vie de ton objet nouvellement créé. Il ne sera pas détruit à la sortie de cette fonction.
}

[Flob90]

@Kaamui: Comme dans tout les conteneurs, ce sont des copies qui sont insérées (déplacées si ce sont des temporaires en C++11).

Utiliser l'allocation dynamique pour mettre des éléments dans des conteneurs demande de gérer la durée de vie des objets, typiquement avec des pointeurs intelligents. Rien n'est automatique comme tu l'entends.

Quand à la différence [] / at elle concerne bien l'exception que tu nommes, mais ça n'a rien à voir avec l'idée d'exception safety.

[Kaamui]

Comme j'ai vu dans les paramètres de la méthode insert une référence constante sur le value_type, ça me parait étrange ce que tu dis.

Ce que j'entendais, c'est qu'à la destruction de la map, les destructeurs des objets contenus serait appelé, alors avec des pointeurs (c'est pour ça que j'utilisais new (pas spécialement pour faire une allocation dynamique).

Par contre exception-safety, je croyais que c'était cela justement : une méthode est exception-safe quand les exceptions déclenchables sont gérées ? Qu'est-ce que c'est finalement ?

[Médinoc]

La différence entre [] et at() ne concerne pas l'exception-safety mais la vérification de bornes (bounds-checking): Utiliser at() permet d'avoir la vérification de bornes, mais c'est à toi de rendre ton code exception-safe en plus de cela.

[Kaamui]

J'aurais du écrire un truc comme ça ?

Code :

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
 
void Add(const string name)
{
    //non exception-safe
    classMap[name] = new maClass();
    // OU
    //exception-safe (out of range)
    try
    {
       classMap.at(name) = new maClass();
    }
    catch()
   {
     throw blablabla; // ?  
    }
 
    //dans les deux cas, la map sera responsable de la durée de vie de ton objet nouvellement créé. Il ne sera pas détruit à la sortie de cette fonction.
}

[Médinoc]

L'exception-safety ce n'est pas seulement catcher les exceptions, c'est s'assurer que les objets manipulés seront toujours dans un état cohérent et qu'il n'y aura pas de fuite de mémoire.

Ici, si le at() pète, ton new maClass() sera leaké.

[Kaamui]

Et comment tu évites ça du coup ?? Sur cet exemple, à quoi ressemble un code exception-safe ?

[Flob90]

Tu ne peux pas savoir ce que fait une fonction simplement avec sa signature, c'est là qu'interviennent les cours, documentations et références.

Oui, les destructeurs seront appelés à la destruction. Et donc si tu stockes des pointeurs, il te faut les détruire. C'est là qu'interviennent les pointeurs intelligents.

Non, on distingue plusieurs niveau de résistance aux exceptions pour une fonction :

1. Le plus faible : si une exception se déclenche, alors l'état du programme peut devenir invalide. C'est très génant, car dans ce cas même si l'on connait l'exception, il n'est pas forcément évident de retrouver un état valide.
2. Le deuxième niveau : si une exception se déclenche, alors l'état du programme reste valide, mais peut être quelconque. On a un peu améliorer les choses, cependant il reste un problème, est ce qu'on pourra récupérer le déroulement normal du programme depuis cet état et l'exception ?
3. Le plus fort : si une exception lance, alors l'état du programme ne change pas. C'est le plus confortable, dans ce cas tu sais où tu es en cas d'exception et celle-ci te servira à déterminer le chemin à prendre pour rejoindre le déroulement normal du programme.

[Médinoc]

Je dirais un truc du genre:

Code C++ :

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

1
2
3
4
5
6
7
8
9
void Add(const string name)
{
	{
		ptrIntelligent<MaClass> spNew = new MaClass();
		classMap.at(name) = spNew.get();
		spNew.detach();
	}
	//La suite...
}

Si ça pète au at(), spNew.detach() ne sera jamais appelé, donc son destructeur fera un delete sur l'objet pointé.

Et encore, ce code date d'avant C++11 et les move semantics...

[Kaamui]

Génial. Vous êtes trop forts. Donc c'est mon raw pointer qui vous défrisait ? A cause de son côté "non-owning pointer" ?

[Médinoc]

Pas le Raw Pointer en particulier, seulement la fuite de mémoire.
Tu aurais pu t'en sortir avec un raw pointer aussi:

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
void Add(const string name)
{
	maClass *rawPtr = nullptr;
	try
	{
		rawPtr = new maClass();
		classMap.at(name) = rawPtr;
		rawPtr = nullptr;
	}
	catch()
	{
		if(rawPtr != nullptr)
			delete rawPtr;
		throw blablabla; // ?  
	}
}

C'est juste plus compliqué.

[Kaamui]

La fuite mémoire potentielle avec l'utilisation de at ?

[Bousk]

Génial. Vous êtes trop forts. Donc c'est mon raw pointer qui vous défrisait ? A cause de son côté "non-owning pointer" ?

Tu peux utiliser des pointeurs nus, mais ils ne seront pas du tout automatiquement libérés avec la map.

la map sera responsable de la durée de vie de ton objet nouvellement créé.

C'est cette affirmation qui est fausse, en tous cas en partie.
La libération de chaque élément de la map devra être faite par l'utilisateur et ne sera en aucun cas faîte par la map elle-même.

A la destruction d'un vector<T>, c'est T::~T() qui est appelé sur chaque élément.
Si T est un pointeur, il ne s'agira en aucun cas d'un appel à un delete de la mémoire pointée, mais toujours à ~T().

[Kaamui]

Oui oui j'avais déjà compris que j'avais dis une connerie à ce niveau là. L'objet est détruit, pas le pointeur que j'ai créé en même temps que l'objet (c'est pas de ma faute je suis fatigué )

[Bousk]

Oui oui j'avais déjà compris que j'avais dis une connerie à ce niveau là. L'objet est détruit, pas le pointeur que j'ai créé en même temps que l'objet (c'est pas de ma faute je suis fatigué )

Après on est dans le chipotage grammatical, mais perso je dirais plutôt que le pointeur est détruit, pas l'objet (pointé).