operator delete privé

Bonjour,

Pourquoi ceci ne compile pas (au moins sous gcc 4 et vs2005) ? :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

struct S { S() {} };   class C { void operator delete(void *) {} //line 8 S s; };   int main() { new C; //line 15 }

---

D'après le message d'erreur, l'operator delete semble avoir besoin d'être appelé... mais pourquoi :? ?
De plus si j'enlève le constucteur de S, il n'y a plus de problème.

Sacré colle O__O


Ce qui est fou c'est qu'il suffit de commenter le membre S de C pour que ça compile... là je vois pas trop le rapport mais j'imagine qu'il y a une manip dans le constructeur qui utilise l'operateur delete....???

C'est quoi les messages d'erreur ?

L'erreur c'est que l'operateur delete est inaccessible. (VS2008)

Code:

---

1 2 3 4 5 6

1>Compiling... 1>MAin.cpp 1>e:\tests\test_delete\test_delete\main.cpp(19) : error C2248: 'C::operator delete' : cannot access private member declared in class 'C' 1> e:\tests\test_delete\test_delete\main.cpp(13) : see declaration of 'C::operator delete' 1> e:\tests\test_delete\test_delete\main.cpp(7) : see declaration of 'C'

---

Le plus étrange c'est que la ligne pointée par l'erreur est la ligne du new...d'où mon test de virer le membre voir.

Ca viendrai pas du fait que l'operator delete est private ?
Tu devrais peut-être mettre :

Code:

---

1 2	public : void operator delete(void *) {}

---

Effectivement cela résoud le problème, mais ne l'explique pas ;)

En plus j'ai besoin que l'opérateur delete soit privé.

Sous gcc 4.2.3 les messages sont équivalents :

Citation:

---

g++ -O0 -g3 -pedantic -pedantic-errors -Wall -Werror -c -std=c++98 -Wextra -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp"
../main.cpp: In function 'int main()':
../main.cpp:8: error: 'static void C::operator delete(void*)' is private
../main.cpp:15: error: within this context
../main.cpp:8: error: 'static void C::operator delete(void*)' is private
../main.cpp:15: error: within this context

---

Est-ce que par hasard il est dit dans le standard que si l'objet a des membres il doit avoir un operateur delete publique? C'est vraiment super bizarre...
Je comprends pas le rapport entre le membre, le constructeur et le delete, mais ya forcément un rapport...

Heu, à quoi ça peut te servir un operator delete privé 8O.

Et puis sur le :

Code:

---

new C

---

Y a pas comme un problème ?
Là tu crée un objet C n'importe où dans la mémoire sans récupéré l'adresse.
D'habite on fait plutôt :

Code:

---

1 2 3 4

C *pC;   pC = new C;

---

C'est tout a fait valide de faire le new dans le vent, simplement la mémoire est perdue.

D'ailleurs la première chose que j'ai vérifié c'est que l'erreur est toujours là si tu met un pointeur tel que tu l'écris.

Le problème ne viens pas de là.

Le problème c'est que a part si ya une subtilitée de fourbe OU un problème du a la façon du compilateur de lire le code, le code en exemple est bien valide : même si tu déclares un operateur delete en privé, tant qu'il est pas appelé par du code quelque part, le compilateur ne peut pas le détecter!

Surtout que là l'erreur ne survient QUE si la classe en question possede un membre...

O___O;


Ya forcément du code généré sans qu'on le veuille mais c'est encore plus bizarre que le problème soit le même sous gcc ET sous VS...

Si le problème survient sous gcc + vc++, c'est peut-être que le standard interdit une telle chose.

Quelqu'un peut regarder la norme ?

J'ai hâte de savoir pourquoi ils n'en veulent pas. Peut-être qu'un gourou pourra nous expliquer ça :)

Je ne suis pas un gourou mais je vais quand même tenter une explication.
Dans le standard il est dit :

Citation:

---

If the new-expression creates an object or an array of objects of class type, access and ambiguity control are
done for the allocation function, the deallocation function (12.5), and the constructor (12.1). If the new
expression creates an array of objects of class type, access and ambiguity control are done for the destructor
(12.4).

---

et également :

Citation:

---

If the new-expression begins with a unary :: operator, the deallocation function’s name is looked up in the
global scope. Otherwise, if the allocated type is a class type T or an array thereof, the deallocation
function’s name is looked up in the scope of T. If this lookup fails to find the name, or if the allocated type
is not a class type or array thereof, the deallocation function’s name is looked up in the global scope.

---

Cela parait intéressant, mais que veulent dire exactement :

Citation:

---

access and ambiguity control are done

---

et

Citation:

---

is looked up

---

Si cela veut dire que l'operator delete doit être accessible au niveau de la new expression, outre le fait que je n'en vois pas l'intérêt, je ne commprends pas pourquoi le fait de ne pas définir l'opérateur par défaut de T, ne pose plus le problème de compilation.

Je crois que c'est au cas où le constructeur lancerait une exception.

Ce doit être pour la même raison que si l'on définit un opérateur new spécial dans une classe, il faut définir un opérateur delete avec une signature similaire (si on ne le fait pas, Visual donne un message d'erreur ou un warning disant spécifiquement qu'on a besoin d'un opérateur delete au cas où le constructeur excepterait)

Effectivement la levée d'exception possible dans le constructeur de T, obligerait l'appel à l'operator delete dans la new exepression. Bien vu :P

Par contre la norme semble dire qu'il faut que l'operator delete soit tout le temps accessible depuis la new expression (du moins sur un class type) ?

Bien vu Médinoc, ton explication parrait logique.
Et dire que je me suis creuse la tete un bon moment :aie:
On en apprend tous les jours...

C'est clair, un sacré puzzle.

Je viens de tester avec gcc si on met conjointement un objet de classe comme donnée membre ça ne compile pas

Code:

---

1 2 3 4 5

class C { void operator delete(void *) {} string s; }

---

mais si je met une variable ordinaire

Code:

---

1 2 3 4 5

class C { void operator delete(void *) {} int i; }

---

ça compile.

Si je met un constructeur public et aucune donnée membre

Code:

---

1 2 3 4 5 6

class C { void operator delete(void *) {} public: C() {} };

---

ça ne compile plus !


J'ai testé avec le compilateur Borland il compile tout sans boncher.

Code:

---

1 2 3 4 5 6

class C { void operator delete(void *) {} string s; }

---

Je suppose ici que que le constructeur de "string" qui pourrait eventuellement thrower une exception. Et donc l'operateur delete doit pouvoir etre apelle.

Code:

---

1 2 3 4 5 6

class C { void operator delete(void *) {} int i; }

---

La construction de 'i' ne peut pas generer une exception, donc ca compile.

Code:

---

1 2 3 4 5 6 7

class C { void operator delete(void *) {} public: C() {} };

---

La je suppose que le compilateur ne va pas regarder l'interieur du code du constructeur et donc suppose qu'une exception peut thrower.

Et sinon il fait beau dehors ?? :aie::aie: ^^

Effectivement dans les deux cas ou gcc ne veut pas compiler ton code, il pourrait y avoir une levée d'exception dans les constructeurs.

Par contre le compilateur pourrait être plus malin et regarder la définition du constructeur pour savoir s'il y a réellement un risque d'exception.
Peut être que le compilateur borland est plus malin justement.
Que donne la compilation de ce code avec borland ? :

Code:

---

1 2 3 4 5 6 7

class C { void operator delete(void *) {} public: C() { throw int(0);} };

---

Cependant si la norme oblige à rendre disponible l'operator delete dans tout les cas (je ne sais toujours pas si c'est le cas), ces compilateurs ne suivent pas le standard.

Citation:

---

Peut être que le compilateur borland est plus malin justement.
Que donne la compilation de ce code avec borland ? :

---

Peut-être pas tant que cela, car il compile quand même.

Pour revenir a ton probleme, il existe une specification (que je n'ai jamais utilise) qui permet de dire au compilateur qu'il n'y aura pas d'exceptions pendant la construction (ou tout autre methode) de ton objet:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class C { void operator delete(void *,size_t ) { } public: __declspec(nothrow) C() { }   };   int _tmain(int argc, _TCHAR* argv[]) { new C; }

---

Et la ca compile, ce qui prouve bien que c'etait bien le probleme. Par contre __declspec(nothrow) est Microsoft specific donc pas portable. Sur gcc l'equivalent ca serait __attribute__((nothrow)).

Il semble que l'equivalent a __declspec(nothrow) (en tout cas sur VC2005) soit:

Code:

---

1 2	C() throw() { }

---

A savoir qu'en l'absence de cet attribut, c'est comme si le constructeur etait declare comme ceci:

Code:

---

1 2	C() throw(...) { }

---

VC: http://msdn.microsoft.com/en-us/library/49147z04.aspx

Bon week end a tous :mouarf:

Citation:

---

Envoyé par unmanos

Pour revenir a ton probleme, il existe une specification (que je n'ai jamais utilise) qui permet de dire au compilateur qu'il n'y aura pas d'exceptions pendant la construction (ou tout autre methode) de ton objet:

Code:

---

C() throw();

---

---

Il est recommandé de ne pas l'utiliser, ça pose d'autres problèmes. (Je ne me souviens plus lesquels mais tu pourras trouver facilement sur le net ou même sur ce forum, on en a déjà parlé).

La seule recommandation que j'ai vu sur le net auparavant a ce propos c'était de le mettre à la fin du projet quand tu sais ce qui throw ou pas, parceque ça permet au compilo d'eventuellement optimiser les appels (vu qu'il n'y a pas d'exception possible du coup).

Sauf que si tu es sur un compilateur aux normes, au lieu d'optimiser ça pessimise.

__declspec(nothrow) a l'avantage sur throw() de ne pas se faire passer pour un truc standard, et de permettre véritablement une optimisation.