Discussion :

[Heptaeon]

Bonjours je cherche l'equivalent C++
des interfaces Java ou
des methode virtuel qui sont overrid�.

En gros j'aimerais faire un type qui ne contient qu'une serie de fonction sans leur impl�mentation (probablement une virtuel pure)

et dans une fonction, appel� la m�thode de ce qu'est r�element l'objet.
Je connais l'existance du "dynamic cast" mais celui ci demande un nom... Et les nom varierons au cours du developpement de l'application.

De plus, cette facon doit etre tr�s performante car app�l� dans un code "critique".

Merci d'avance, en esperant ne pas �tre d�cu de ce language...

J'ai entendu parler d'interface en Vc++, mais est ce que les compilateur linux le prenne aussi ?


R�solu

[diogene]

En gros j'aimerais faire un type qui ne contient qu'une serie de fonction sans leur impl�mentation (probablement une virtuel pure)

La repr�sentation des interfaces en C++ est une classe abstraite ne contenant rien d'autre que des m�thodes virtuelles pures

et dans une fonction, appel� la m�thode de ce qu'est r�element l'objet

je ne comprends pas ce que tu veux dire

J'ai entendu parler d'interface en Vc++, mais est ce que les compilateur linux le prenne aussi

Le concept d'interface est ind�pendant (quoique si il s'agit des interfaces COM c'est du monde Windows)

[Luc Hermitte]

L'�quivalent d'une interface est une classe abstraite uniquement compos�e de fonctions virtuelles pures.
Toutes fois, le C++ permet (contrairement au Java) de d�finir nativement les invariants. Ce qui abouti � des classes "contrats" compos�es de fonctions membres publiques non virtuelles dont l'impl�mentation v�rifira les invariants et appellera des fonctions virtuelles (pures au niveau du contrat), non publiques, qui seront red�fini�es par la suite.

En Java comme en C++, le downcasting (fait avec des dynamic_cast<> en C++, un cast-�-la-C en Java) est g�n�ralement signe d'une erreur de conception.

Il est �trange que tu parles de m�thode virtuelle alors que Java, IIRC, n'a pas ce terme dans son vocabulaire.

terme Java <-> �quivalent direct C++
"m�thode" <-> "fonction (membre) virtuelle"
"interface" <-> classe abstraite compos�e uniquement de fonctions virtuelles pures

[Heptaeon]

Je vais tenter d'etre plus clair sur mes but et merci d�ja de vos r�ponse.

En gros j'aimerais faire une interface d'objet affichable. et laisser la possibilit� a d'autre de cr�er leur objet au nom qu'il veulent.

En c# je ferait une interface nom� Affichable qui aurais une m�thode virtuel "void Affiche()".

Les utilisateurs "overriderais" la m�thode Affiche(). Et donc mes fonctionalit� qui utiliserait les m�thode de mon interface, utiliserais la m�thode de l'utiliateur.


Je en sais pas si c'est clair, alors je tente un autre exemple.
Imaginons une class CT2 qui h�rrite de CT1. CT1 et CT2 ne contienent que une methode virtuel nom� Test().

La methode Test() de CT1 affiche "Class CT1" et celle de CT2 Affiche "Class CT1"

si je fait :

CT1 T1;
CT2 T2;
T1.Test();
T2.Test();

T1 = T2;
T1.Test();

Ca affiche en c++
"Class CT1"
"Class CT2"
"Class CT1"

En c# avec les override ca afficherais
"Class CT1"
"Class CT2"
"Class CT2"

Pourquoi ? Car il sais que l'objet est en r�alit� un CT2 donc applique la fonction des CT2 meme si dans la fonction c'est d�clar� comme une classe de plus bas niveau...

C'est le comportement c# que j'aimerais retrouv�...

Et en java on peu utiliser les type des interface dans ses fonction, genre :
void Fonction(MonInterface MonObjet)
{
MonObjet.MethodeDeLInterface();
}

Ce qui m'est impossible en C++ LEs class virtuel pure �tant abstraite ...

[M�dinoc]

Il suffit que la fonction soit virtuelle et non pas virtuelle pure...

En java, toutes les m�thodes non-statiques sont virtuelles.
virtuelle pure == m�thode abstraite

[Heptaeon]

Il suffit que la fonction soit virtuelle et non pas virtuelle pure...

En java, toutes les m�thodes non-statiques sont virtuelles.
virtuelle pure == m�thode abstraite

Le probl�me est que si je met une non virtuel pure dans mon interface, le linker dit qu'elle n'est pas d�finie. Et si je la d�fini, C'est celle la qui sera utilis� mais pas celle r�el de l'objet comme le ferais c#...

[Luc Hermitte]

Ca pue la tentative d'utilisation de s�mantique de valeur (la partie copie) avec une hi�rarchie polymorphe.
En clair, interdiction de passer (en param�tres) des objets, issus de hi�rarchies d'objets polymorphes, par valeur.

Les r�f�rences, constantes ou non, sont tes amies.

[Heptaeon]

Ca pue la tentative d'utilisation de s�mantique de valeur (la partie copie) avec une hi�rarchie polymorphe.
En clair, interdiction de passer (en param�tres) des objets, issus de hi�rarchies d'objets polymorphes, par valeur.

Les r�f�rences, constantes ou non, sont tes amies.

Tu veux dire que le constructeur de copie me pourris tout ?
et que donc en passant ca par des pointeur ca marcherais ?
Ou alors j'ai pas compris ton explication

[Heptaeon]

Excelent!!! c'etait bien ca. J'ai en gros garder l'habitude que tout soit des passage par r�f�rence en Java/C#. Merci beaucoup je vais editer mon message pour mettre R�solu.

[M�dinoc]

Tu n'as pas � �diter le message: il y a un bouton "r�solu" en bas � gauche, qui ins�re automatiquement le tag [R�solu] en noir...

[Heptaeon]

Fait des 2 cot� ^^.

Mais j'avouerais ne pas vraiment saisir le concept de classes "contrats".

Toutes fois, le C++ permet (contrairement au Java) de d�finir nativement les invariants. Ce qui abouti � des classes "contrats" compos�es de fonctions membres publiques non virtuelles dont l'impl�mentation v�rifira les invariants et appellera des fonctions virtuelles (pures au niveau du contrat), non publiques, qui seront red�fini�es par la suite.

[Luc Hermitte]

Pour les contrats:

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
19
20
21
22
23
24
25
struct Contract1 : boost::non_copyable 
{
    void f(int i) {
        if (i<42) 
            throw std::runtime_error("C1::f: précondition non respectée");
        do_f(i);
    }
private:
    virtual void do_f(int i) = 0;
};
 
struct Impl : Contract1, Contract2 {
private:
    virtual void do_f(int i) { ... code }
    virtual int  do_g() const { ... }
};
 
void fonction_client1(Contract1 & c)
{ c.f(55); }
void fonction_client2(Contract2 const& c)
{ const i = c.g(); ... }
.....
Impl i;
fonction_client1(i);
fonction_client2(i);

Pour ce qui est des copies et des hi�rarchies d'objets polymorphes.
La bonne r�gle simplifi�e consiste � :
- toujours interdire l'affectation
- interdire la recopie,
- ou la restreindre la recopie � une utilisation interne (prot�g�e) destin�e � la d�finition d'une fonction de clonage.

[Heptaeon]

En faite, c'est forc� a ne pas faire l'erreure que j'ai faite ^^.