Equivalent C++

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

Citation:

---

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

Citation:

---

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 :(

Citation:

---

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)

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

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 ...

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

Citation:

---

Envoyé par 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

---

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#...

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.

Citation:

---

Envoyé par 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.

---

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 :oops:

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.

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...

Fait des 2 coté ^^.

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

Citation:

---

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.

---

Pour les contrats:

Code:

---

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.

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