Discussion :

[Luc Hermitte]

Une interface java correspondrait à une ABC C++ où toutes les fonctions membre sont virtuelles pure.

[NiamorH]

Je me disait aussi.
A votre avis, l'utilisation de politiques peut elle être une solution pour limiter l'héritage.

Pour moi non. En tout cas ce n'est pas une alternative équivalente. Une fois que tu as viré la classe de base, tu ne peux plus mettre tes animaux dans le même conteneur. Tu ne peux plus te servir que du polymorphisme statique, somme toute limité. Le remplacement de l'un par l'autre n'est généralement pas une option.

- Complexité de compréhension pour une personne tierce
- Fait peur à un client
- Debuggage plus complexe
- Difficulté de remodulation du code si besoin

C'est marrant mais dans ma boîte, c'est plutôt les classes de politiques et les templates qui répondraient aux trois premiers points.

[Klaim]

Au passage, un moyen de faire du sealing (empecher la possibilitée d'heritage d'une classe) est décrit dans cet article :
http://www.gamedev.net/reference/pro...tures/cppseal/

Personnellement, je trouve que faire en sorte que ce soit difficile (et induire chez l'utilisateur l'idée que c'est certainement inaproprié) est largement suffisant.

[NiamorH]

Avec :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template < class T >
class SealedBase
{
protected:
    SealedBase()
    {
    }
};
 
#define Sealed(_CLASS_NAME_) private virtual SealedBase<_CLASS_NAME_>
 
class Penguin : Sealed(Penguin)
{
};

il suffit d'écrire :

Code :

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

1
2
3
4
5
6
7
8
class BigZ : Penguin, Sealed(Penguin)
{
};
 
int main()
{
  BigZ test;
}

Pour que son astuce ne marche pas mieux que la premiere :p

Et pour la deuxieme astuce (compilo M$) j'écris :

Code :

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

1
2
3
class BigZ : Penguin, private virtual SealedBase<__COUNTER__-1>
{
};

Je te l'avoue, c'est tordu mais...

[Emmanuel Deloget]

Se servir de __COUNTER__ de cette manière est dangereux: supposons que la classe Penguin soit définie dans Penguin.h et que je définisse une autre classe Rotweiller dans Rotweiller.h. Si dans un cpp je fais un include de Penguin.h puis Rotweiller.h, __COUNTER__ vaudra respectivement N et N+1. Si dans un autre cpp j'inclus d'abord Rotweiller.h puis Penguin.h, les valeurs de __COUNTER__ ne seront plus les même. Au final, j'obtient plusieurs déclarations et définitions des classes sus-citées - ce qui provoque une phénomène du type "attention à la marche, oups, trop tard" au niveau du code...