Discussion :

[asaleth]

Bonjour,

je suis actuellement en train de créer des pointeurs intelligents
cependant lorsque je surcharge mon opérateur new (dans ma classe, pas globalement) je rencontre une erreur.
Le compilateur me sort des erreurs car les attributs de ma classe ne sont pas static

Voilà les parties qui ne fonctionnent pas :

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
 
template<typename Type>
class Ptr_intelligent
{
	public:
		Ptr_intelligent(); //constructeur par défaut
		Ptr_intelligent(Type*); // constructeur par copie
		Ptr_intelligent(const Ptr_intelligent<Type>&); //constructeur par copie
		~Ptr_intelligent(); //destructeur
		void * operator new(size_t);
 
	private:
		Type* ptr;
		Compteur* cpt_ref;
		allocateur<Type> a;
 
};

Code :

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

1
2
3
4
5
6
7
8
 
template<typename Type>
void * Ptr_intelligent<Type>::operator new (size_t taille)
{
	ptr = a.allouer(taille);
	return ptr;
 
}

En surchargeant l'opérateur new on est obligé d'utiliser des membres static uniquement ?

Merci

[jo_link_noir]

> En surchargeant l'opérateur new on est obligé d'utiliser des membres static uniquement ?

Oui, car l'opérateur new s’applique avant la construction de l'objet, donc pas d'instance, donc static.

S'il fallait surcharger new pour un pointeur intelligent, se serait plutôt : void * operator new(size_t) = delete. Parce qu'allouer dynamiquement un pointeur intelligent et se balader avec un pointeur cause toujours des problèmes de durée de vie et la fameuse question: qui est le propriétaire ?

Pour construire une telle classe, les constructeurs sont largement suffisants (ne pas oublier le constructeur de mouvement, idem pour l'opérateur=).

PS: un constructeur qui prend un T* pour le copier n'est à mon sens pas une bonne idée. Devenir propriétaire oui, prendre une référence et la copier, bof. Mais copier le pointeur, clairement non.
PS2: pourquoi ne pas utiliser std::shared_ptr ?

[asaleth]

Merci pour la réponse.
Pourquoi ne pas utiliser shared_ptr ? : Parce que le sujet de mon TP est justement de réaliser des pointeurs intelligents "maisons"
mais je pense que je n'ai pas bien compris la situation.

Donc je vais abandonner cette histoire de new et utiliser mes constructeurs uniquement : merci !

Mais j'ai encore du mal à comprendre 2-3 trucs, comme par exemple pourquoi je peux déclarer :

Code :

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

1
2
 
Ptr_intelligent<int> p;

et faire :

Code :

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

1
2
 
printf("%d %d \n",*p,p[50]);

sans obtenir d'erreur ?

voilà le constructeur :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
template<typename Type>
Ptr_intelligent<Type>::Ptr_intelligent()
{
	allocateur<Type> alloc;
	a = alloc;
	ptr = a.allouer(1);
	cpt_ref = new Compteur();
	cpt_ref->incrementer();
}

et voilà le code dans l'allocateur :

Code :

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

1
2
3
4
5
6
7
8
9
 
template<typename Type>
Type * allocateur<Type>::allouer(size_t taille)
{
	Type* ptr;
	ptr = (Type*) malloc(taille*sizeof(Type));
	memoireAllouee= memoireAllouee+taille*sizeof(Type);
	return ptr;
}

as tu une idée à ce niveau là ?
Je pensais que a.allouer(1) allouerait 4 octets dans le tas et donc que je ne pourrais faire que *ptr ou ptr[0], mais certainement pas ptr[50] sans segfault.

J'ai du mal à comprendre la situation

[foetus]

Ton code est trop bancal

• Un malloc au lieu d'un new.
• ptr n'est pas désalloué
• cpt_ref n'est pas désalloué
• allocateur ne sert à rien? "Too much"?
• memoireAllouee ne sert à rien et en plus il n'y a pas de relation entre la mémoire allouée et ce compteur (si tu alloues 2 blocs mais qu'un seul est désalloué il se passe quoi?)

Tu sembles oublier que tu fais un sizeof : 1 * sizeof(int)

[asaleth]

Je n'ai pas copié le code en entier pour ne pas avoir plein de petits morceaux de code : ça serait trop long
et le malloc n'était là que pour tester de toute façon

[jo_link_noir]

pourquoi je peux faire printf("%d %d \n",*p,p[50]); sans segfault ?

Parce que personne ne vérifie que ptr[50] est alloué par ptr et que, manque de pot, ptr[50] est une zone mémoire accessible.
Des outils d'analyse comme valgrind ou asan (-fsanitize-adress=address pour la plupart des compilateurs) vont probablement râler.


Les lignes 5 et 6 concernant l'allocateur ne servent à rien. Dans le corps du constructeur, les variables membres sont déjà construites, donc a = alloc est totalement inutile. Si il y avait besoin de l'initialiser, c'est à faire dans la liste d'initialisation.
Et il y a une fuite mémoire. Que se passe-t-il quand new Compteur envoi une exception ? Un peu de lecture http://www.stroustrup.com/except.pdf

Concernant les allocateurs, leurs usages est généralement séparés en 2 parties: allocation de mémoire (allocate avec ::operator new) et construction de l'objet dans la zone alloué (construct avec [url=http://en.cppreference.com/w/cpp/language/new]placement new[/c]). Avec les fonctions inverses destruct et deallocate.

Tu peux aussi allouer le compteur en même temps que Type (allocateur<struct{Compteur compteur, Type * p}).

[asaleth]

Oh punaise d'accord je commence à voir mes erreurs.

Merci ! Je vais m'y remettre demain !

[koala01]

Salut,

Je ne vais pas revenir sur le reste, mais...

Code :

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

1
2
3
allocateur<Type> alloc;  // (1)
	a = alloc;  //(2)
	ptr = a.allouer(1); // (3)

...

Voyons si je comprend bien :
En (1), tu crées un objet, nommé alloc, quo est de type allocateur<Type>... soit, cela semble cohérent avec l'idée généralement véhiculée par les pointeurs intelligents

En (2), tu affecte à a (qui est une variable membre et qui a donc été créée automatiquement !!!) une copie de alloc... Et là, je commence à me poser de sérieuses questions :

• L'allocateur créé par défaut étant tout à fait identique à celui que tu crée en déclarant alloc, y aurait-il une raison cachée à travailler en deux fois
• Ne pourrais-tu pas, dans le pire des cas, écrire un code proche de a = allocateur<Type>{};
• Et, tant qu'à faire, es tu vraiment obligé de garder une instance de ton allocateur tout au long de la durée de vie de tes instances

Après tout, le besoin de l'allocateur est, théoriquement, limité à quelques fonctions bien particulières... Il pourrait être construit à chaque fois que tu veux faire une allocation et détruit dés que tu quitte la fonction dans laquelle cette allocation est effectuée, cela ne ralentirait pas les choses... Par contre, cela pourrait t'aider à "ménager" un tout petit peu la mémoire, en évitant d'utiliser inutilement quelques bytes

[asaleth]

Tu as tout à fait raison, mon code est plus ou moins rempli d'incohérence, je vais améliorer ça et le rendre plus propre,
en soi je n'avais pas suffisamment compris le rôle de l'allocateur et surtout la place qu'a l'allocateur !

Merci beaucoup en tout cas pour les remarques

[jo_link_noir]

• Et, tant qu'à faire, es tu vraiment obligé de garder une instance de ton allocateur tout au long de la durée de vie de tes instances

Après tout, le besoin de l'allocateur est, théoriquement, limité à quelques fonctions bien particulières... Il pourrait être construit à chaque fois que tu veux faire une allocation et détruit dés que tu quitte la fonction dans laquelle cette allocation est effectuée, cela ne ralentirait pas les choses...

Ce n'est pas une très bonne idée. Si l'allocateur à un état, tout fous le camp. Et si un allocateur ne peut pas avoir d'état, autant utiliser new/delete.
D'ailleurs, les nouveaux allocateurs du standard ont des états.

Une bonne implémentation de se type de pointeur devrait, amha, pouvoir prendre un allocateur en paramètre, allouer un segment de mémoire {T + Allocator} et déplacerait l'allocateur dans le segment alloué. Avec une optimisation comme EBO et si l'allocateur n'a pas d'état (cf: variable membre), il y a moyen d'avoir un segment mémoire de la taille d'un T. (petite article de présentation avec unique_ptr comme exemple).