Je ne pense pas que ce soit possible. Ne pas mettre de destructeur virtuel est un bon encouragement, mais sinon, la meilleure solution reste de mettre un "Prière de ne pas dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
-- ;-)
On Sun, 30 Jan 2005 01:35:52 +0100, "nico" <spam@spam.spam>:
Comment déclarer une classe indérivable en C++ ?
Je ne pense pas que ce soit possible.
Ne pas mettre de destructeur virtuel est un bon encouragement, mais
sinon, la meilleure solution reste de mettre un "Prière de ne pas
dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
Je ne pense pas que ce soit possible. Ne pas mettre de destructeur virtuel est un bon encouragement, mais sinon, la meilleure solution reste de mettre un "Prière de ne pas dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
-- ;-)
nico
Salut,
Pour le moment c'est de la simple curiosité (je n'en ai jamais eu besion) j'ai juste vu que c'était possible en dotNet.
-- nico
Fabien LE LEZ wrote:
On Sun, 30 Jan 2005 01:35:52 +0100, "nico" :
Comment déclarer une classe indérivable en C++ ?
Je ne pense pas que ce soit possible. Ne pas mettre de destructeur virtuel est un bon encouragement, mais sinon, la meilleure solution reste de mettre un "Prière de ne pas dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
Salut,
Pour le moment c'est de la simple curiosité (je n'en ai jamais eu besion)
j'ai juste vu que c'était possible en dotNet.
--
nico
Fabien LE LEZ wrote:
On Sun, 30 Jan 2005 01:35:52 +0100, "nico" <spam@spam.spam>:
Comment déclarer une classe indérivable en C++ ?
Je ne pense pas que ce soit possible.
Ne pas mettre de destructeur virtuel est un bon encouragement, mais
sinon, la meilleure solution reste de mettre un "Prière de ne pas
dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
Pour le moment c'est de la simple curiosité (je n'en ai jamais eu besion) j'ai juste vu que c'était possible en dotNet.
-- nico
Fabien LE LEZ wrote:
On Sun, 30 Jan 2005 01:35:52 +0100, "nico" :
Comment déclarer une classe indérivable en C++ ?
Je ne pense pas que ce soit possible. Ne pas mettre de destructeur virtuel est un bon encouragement, mais sinon, la meilleure solution reste de mettre un "Prière de ne pas dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
Olivier Azeau
Fabien LE LEZ wrote:
On Sun, 30 Jan 2005 01:35:52 +0100, "nico" :
Comment déclarer une classe indérivable en C++ ?
Je ne pense pas que ce soit possible. Ne pas mettre de destructeur virtuel est un bon encouragement, mais sinon, la meilleure solution reste de mettre un "Prière de ne pas dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
Fabien LE LEZ wrote:
On Sun, 30 Jan 2005 01:35:52 +0100, "nico" <spam@spam.spam>:
Comment déclarer une classe indérivable en C++ ?
Je ne pense pas que ce soit possible.
Ne pas mettre de destructeur virtuel est un bon encouragement, mais
sinon, la meilleure solution reste de mettre un "Prière de ne pas
dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
Je ne pense pas que ce soit possible. Ne pas mettre de destructeur virtuel est un bon encouragement, mais sinon, la meilleure solution reste de mettre un "Prière de ne pas dériver" dans la documentation.
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
Fabien LE LEZ
On Sun, 30 Jan 2005 12:01:04 +0100, Olivier Azeau :
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
J'y avais sérieusement pensé (comme seule cause valable), mais je n'ai pas osé l'écrire ;-P
-- ;-)
On Sun, 30 Jan 2005 12:01:04 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
J'y avais sérieusement pensé (comme seule cause valable), mais je n'ai
pas osé l'écrire ;-P
On Sun, 30 Jan 2005 12:01:04 +0100, Olivier Azeau :
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
J'y avais sérieusement pensé (comme seule cause valable), mais je n'ai pas osé l'écrire ;-P
-- ;-)
Alexandre
"nico" a écrit dans le message de news: 41fc2b97$0$14473$
Bonjour,
Comment déclarer une classe indérivable en C++ ?
Merci.
-- nico
Si tu n'as que des membres privés, et que tu déclares une 2e classe comme
amie (afin de pouvoir utiliser la 1ère classe), la 1ère n'est pas dérivable. En fait, elle l'est mais on ne peut pas se servir des membres hérités. Ceci dit, la 2e classe, elle, est dérivable, mais comme l'amitié ne s'hérite pas, on ne peut toujours pas utiliser les membres privés de la 1ère... C'est un peu lourd mais c'est une méthode possible pour empecher une dérivation efficace.
"nico" <spam@spam.spam> a écrit dans le message de news:
41fc2b97$0$14473$636a15ce@news.free.fr...
Bonjour,
Comment déclarer une classe indérivable en C++ ?
Merci.
--
nico
Si tu n'as que des membres privés, et que tu déclares une 2e classe comme
amie (afin de pouvoir utiliser la 1ère classe), la 1ère n'est pas dérivable.
En fait, elle l'est mais on ne peut pas se servir des membres hérités. Ceci
dit, la 2e classe, elle, est dérivable, mais comme l'amitié ne s'hérite pas,
on ne peut toujours pas utiliser les membres privés de la 1ère... C'est un
peu lourd mais c'est une méthode possible pour empecher une dérivation
efficace.
"nico" a écrit dans le message de news: 41fc2b97$0$14473$
Bonjour,
Comment déclarer une classe indérivable en C++ ?
Merci.
-- nico
Si tu n'as que des membres privés, et que tu déclares une 2e classe comme
amie (afin de pouvoir utiliser la 1ère classe), la 1ère n'est pas dérivable. En fait, elle l'est mais on ne peut pas se servir des membres hérités. Ceci dit, la 2e classe, elle, est dérivable, mais comme l'amitié ne s'hérite pas, on ne peut toujours pas utiliser les membres privés de la 1ère... C'est un peu lourd mais c'est une méthode possible pour empecher une dérivation efficace.
James Kanze
nico wrote:
Comment déclarer une classe indérivable en C++ ?
C'est un problème classique. (Je l'ai lu de Rob Murray il y a environ dix ans.)
! class NonDerivable : public virtual BloqueLaDerivation ! { ! // ... ! } ;
Depuis, j'en ai vu des solutions avec un BloqueLaDerivation templatées.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
nico wrote:
Comment déclarer une classe indérivable en C++ ?
C'est un problème classique. (Je l'ai lu de Rob Murray il y a
environ dix ans.)
! class NonDerivable : public virtual BloqueLaDerivation
! {
! // ...
! } ;
Depuis, j'en ai vu des solutions avec un BloqueLaDerivation
templatées.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
! class NonDerivable : public virtual BloqueLaDerivation ! { ! // ... ! } ;
Depuis, j'en ai vu des solutions avec un BloqueLaDerivation templatées.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Michel Michaud
Dans le message ,
On Sun, 30 Jan 2005 12:01:04 +0100, Olivier Azeau :
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
J'y avais sérieusement pensé (comme seule cause valable), mais je n'ai pas osé l'écrire ;-P
Par souci de clarté, je précise ici (pour les lecteurs non avertis) que même si la classe a un destructeur non virtuel, il n'y a aucune raison a priori de vouloir empêcher la dérivation.
En fait, je vois mal pourquoi on ferait même une documentation disant de ne pas dériver, plutôt que d'indiquer quels sont les problèmes potentiels si on dérive... En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible) autrement qu'en se servant de la possibilité d'optimisation, qui me paraît bien faible dans des langages qui offrent (ou devraient offrir) des possibilités d'optimisation bien supérieures...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message vpfpv01o26lg03e0nblaf0hjnpntc3258p@4ax.com,
On Sun, 30 Jan 2005 12:01:04 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
J'y avais sérieusement pensé (comme seule cause valable), mais je
n'ai pas osé l'écrire ;-P
Par souci de clarté, je précise ici (pour les lecteurs non avertis)
que même si la classe a un destructeur non virtuel, il n'y a aucune
raison a priori de vouloir empêcher la dérivation.
En fait, je vois mal pourquoi on ferait même une documentation disant
de ne pas dériver, plutôt que d'indiquer quels sont les problèmes
potentiels si on dérive... En un mot, je suis contre les « sealed »
et équivalents, qui existent pourtant en C# et Java (et j'imagine
ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de
leur utilité (si c'est possible) autrement qu'en se servant de la
possibilité d'optimisation, qui me paraît bien faible dans des
langages qui offrent (ou devraient offrir) des possibilités
d'optimisation bien supérieures...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
On Sun, 30 Jan 2005 12:01:04 +0100, Olivier Azeau :
Pourquoi veux-tu empêcher la dérivation, au fait ?
Parce que la classe a un destructeur non virtuel ;-)
J'y avais sérieusement pensé (comme seule cause valable), mais je n'ai pas osé l'écrire ;-P
Par souci de clarté, je précise ici (pour les lecteurs non avertis) que même si la classe a un destructeur non virtuel, il n'y a aucune raison a priori de vouloir empêcher la dérivation.
En fait, je vois mal pourquoi on ferait même une documentation disant de ne pas dériver, plutôt que d'indiquer quels sont les problèmes potentiels si on dérive... En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible) autrement qu'en se servant de la possibilité d'optimisation, qui me paraît bien faible dans des langages qui offrent (ou devraient offrir) des possibilités d'optimisation bien supérieures...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Fabien LE LEZ
On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" :
En fait, je vois mal pourquoi on ferait même une documentation disant de ne pas dériver, plutôt que d'indiquer quels sont les problèmes potentiels si on dérive... En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java
J'ai l'impression que Java (et Microsoft Java, alias C#) veulent enfermer le programmeur dans le mode de pensée prévu par l'auteur du langage, et d'une manière générale cherchent à réduire les possibilités. La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends tes responsabilités et affronte les conséquences".
-- ;-)
On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" <mm@gdzid.com>:
En fait, je vois mal pourquoi on ferait même une documentation disant
de ne pas dériver, plutôt que d'indiquer quels sont les problèmes
potentiels si on dérive... En un mot, je suis contre les « sealed »
et équivalents, qui existent pourtant en C# et Java
J'ai l'impression que Java (et Microsoft Java, alias C#) veulent
enfermer le programmeur dans le mode de pensée prévu par l'auteur du
langage, et d'une manière générale cherchent à réduire les
possibilités.
La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends
tes responsabilités et affronte les conséquences".
On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" :
En fait, je vois mal pourquoi on ferait même une documentation disant de ne pas dériver, plutôt que d'indiquer quels sont les problèmes potentiels si on dérive... En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java
J'ai l'impression que Java (et Microsoft Java, alias C#) veulent enfermer le programmeur dans le mode de pensée prévu par l'auteur du langage, et d'une manière générale cherchent à réduire les possibilités. La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends tes responsabilités et affronte les conséquences".
-- ;-)
Gabriel Dos Reis
Fabien LE LEZ writes:
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" : | | >En fait, je vois mal pourquoi on ferait même une documentation disant | >de ne pas dériver, plutôt que d'indiquer quels sont les problèmes | >potentiels si on dérive... En un mot, je suis contre les « sealed » | >et équivalents, qui existent pourtant en C# et Java | | J'ai l'impression que Java (et Microsoft Java, alias C#) veulent | enfermer le programmeur dans le mode de pensée prévu par l'auteur du | langage, et d'une manière générale cherchent à réduire les | possibilités. | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | tes responsabilités et affronte les conséquences".
Comme std::map<> ou std::set<> ?
Désolé, je n'ai pas pu résister.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" <mm@gdzid.com>:
|
| >En fait, je vois mal pourquoi on ferait même une documentation disant
| >de ne pas dériver, plutôt que d'indiquer quels sont les problèmes
| >potentiels si on dérive... En un mot, je suis contre les « sealed »
| >et équivalents, qui existent pourtant en C# et Java
|
| J'ai l'impression que Java (et Microsoft Java, alias C#) veulent
| enfermer le programmeur dans le mode de pensée prévu par l'auteur du
| langage, et d'une manière générale cherchent à réduire les
| possibilités.
| La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends
| tes responsabilités et affronte les conséquences".
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" : | | >En fait, je vois mal pourquoi on ferait même une documentation disant | >de ne pas dériver, plutôt que d'indiquer quels sont les problèmes | >potentiels si on dérive... En un mot, je suis contre les « sealed » | >et équivalents, qui existent pourtant en C# et Java | | J'ai l'impression que Java (et Microsoft Java, alias C#) veulent | enfermer le programmeur dans le mode de pensée prévu par l'auteur du | langage, et d'une manière générale cherchent à réduire les | possibilités. | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | tes responsabilités et affronte les conséquences".
Comme std::map<> ou std::set<> ?
Désolé, je n'ai pas pu résister.
-- Gaby
Ludorg
"Michel Michaud" a écrit dans le message de news:KfiLd.1880$
En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible)
On peut développer une classe par exemple gérant la sécurité du système. On a pas envie que l'utilisateur rédéfinisse par exemple la classe de gestion du login...
Tschaw
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:KfiLd.1880$Ck1.411930@news20.bellglobal.com...
En un mot, je suis contre les « sealed »
et équivalents, qui existent pourtant en C# et Java (et j'imagine
ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de
leur utilité (si c'est possible)
On peut développer une classe par exemple gérant la sécurité du système.
On a pas envie que l'utilisateur rédéfinisse par exemple la classe de
gestion du login...
"Michel Michaud" a écrit dans le message de news:KfiLd.1880$
En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible)
On peut développer une classe par exemple gérant la sécurité du système. On a pas envie que l'utilisateur rédéfinisse par exemple la classe de gestion du login...
