Polymorphisme et cast dynamique

Bonjour,
Lorsque je compile le code suivant avec Visual Studio, j'obtiens le message d'erreur :
'static_cast' : la conversion de 'FileDataSource *' en 'DataSource *' existe, mais n'est pas accessible.

Code:

---

1 2 3 4 5 6

DataSource* ds; if (strcmp(type,"sql") == 0) ds = static_cast<DataSource*>(new SQLDataSource(".\\global.ini")); else ds = static_cast<DataSource*>(new FileDataSource(".\\global.ini"));

---

FileDataSource et SQLDataSource héritent bien de DataSource!
Avec un dynamic_cast, ça plante à l'exécution. C'est cohérent mais je ne comprends pas cette notion d'accessibilité.
Merci d'avance

En l'occurence, tu n'a pas besoin de caster lorsque tu assignes un pointeur vers une classe dérivée à un pointeur de classe de base. C'est dans le sens inverse que le cast a un intéret (pour pouvoir accéder aux propriétés/méthodes non virtuelles)

Héritage privé ou public ?

Merci de cette réponse rapide!
J'aimerais quand même aller un peu plus au fond des choses
En effet sans aucun cast, le compilateur me gronde de la même façon...
accessibilité tout ça (d'ailleurs si quelqu'un peut m'expliquer cette notion...)
C'est d'ailleurs la raison pour laquelle j'ai essayé de caster, car je pensais moi aussi ne pas en avoir besoin...

Avec un cast C classique (entre parenthèses), j'ai droit à un warning à la compilation(toujours problème d'accessibilité), mais le programme fonctionne correctement. Avec un reinterpret_cast, ça passe sans problème.

Citation:

---

Envoyé par Miles

Héritage privé ou public ?

---

Je ne connaissais pas cette notion d'héritage privé ou public. En effet je n'avais pas précisé! En précisant "public" ça marche. Merci

Pouvez-vous m'expliquer la notion d'héritage privé car j'ai du mal (ou m'aiguiller vers une ressource) ?

FAQ :
http://c.developpez.com/faq/cpp/?pag...private_public

Merci

Salut,

Pour aller un peu au fond des choses, il faut savoir qu'il n'y a que peu de différence entre une struct et une class, en C++ du moins...

La principale, c'est ce qu'on appelle "la visibilité" par défaut des membres, méthodes et héritages.

Le lien fourni par Ksempac explique plus que correctement les trois termes, donc, je vais aller juste un peu plus loin en précisant que, en C++, une classe aura une visibilité par défaut (si tu ne précise pas avant si c'est public, protected ou private) à private, alors que la struct aura une visibilité par défaut à public...

Un exemple pour comprendre:

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

class A { //tout ce qui précede le mot clé public est... private, donc accessible //seulement au départ d'un objet du type de la classe elle-même int machin; float brol void truc(); public: //ce qui suit est... public (accessible de partout) A(); ~A(); float fonct(); };   // à contrario, pour la struct, c'est l'inverse struct B { //si rien n'est spécifié, c'est public (donc accessible de partout) int machin; float brol; (...) // mais on peut déclarer des choses private (inaccessible en dehors de la // struct) private: float fonct();//inaccessible }; // Assez surprenant, quoi que logique :P : l'héritage...   class C: A //comme rien n'est indiqué, et que A est une classe //ca revient à class C: private A, { (...) };   class D: B //comme rien n'est indiqué, et que B est une struct, // ca revient à class D: public B { (...) };   struct E: A//comme rien n'est indiqué, et que A est une classe //ca revient à struct E: private A { (...) }; struct F: B //comme rien n'est indiqué, et que B est une struct, // ca revient à struct F: public B { (...) };

---

Pour comprendre l'utilité d'un héritage privé:

En simplifiant à l'extrème, on peut considérer l'héritage public comme créant une relation de type "est-un";

Tu as surement déjà entendu parler d'un autre type de relation: la relation "a un/des", qui sort du contexte précis de l'héritage.

L'héritage privé aurait pour conséquence de créer un troisième type de relation: la relation "tenir un(:question:)" (en anglais, tu verra le terme "hold a")

C'est une relation qui ne trouvera vraissemblablement un intérêt qu'avec la directive using, de manière à rendre certaines méthodes de la classe de base accessibles à la classe dérivée ;)

Tout ça est également expliqué dans la FAQ, juste en dessous de la Q/R précédemment citée...

D'ailleurs ce que tu dis est en contradiction avec ce qui est dit dans la FAQ, à savoir que ce serait le type de la dérivée qui détermine le type d'héritage par défaut, non celui de la base.

Je ne m'avancerai pas à dire qui a raison ou tord, je ne retient jamais cette règle :D

Ah... à en croire le bouquin "ANSI-ISO CPP programmers handbook, il y aurait donc bien une erreur dans la FAQ...

Citation:

---

Using structs as A Shorthand for Public Classes
Traditionally, structs serve as data aggregates. However, in C++ a struct can have constructors, a
destructor, and member functions -- just like a class. The only difference between the two is the default access
type: By default, a class has private access type to its members and derived objects, whereas a struct has
public access. Consequently, structs are sometimes used as shorthand for classes, whose members are all
public. Abstract classes are a good example of classes that have all public members.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#include <cstdio> using namespace std; struct File //interface class. all members are implicitly public { virtual int Read() = 0; File(FILE *); virtual ~File() = 0; }; class TextFile: File //implicit public inheritance; File is a struct { private:   string path; public: int Flush(); int Read(); }; class UnicodeFile : TextFile //implicit private inheritance { public: wchar_t convert(char c); };

---

---

Maintenant, avant de crier haro sur la FAQ, peut etre est-ce le bouquin qui a tord :question:

En ayant fait un test (avec g++), il semble effectivement que ce soit la FAQ qui aie raison... je présente toutes mes excuses à son auteur :oops:

Citation:

---

Envoyé par koala01

Maintenant, avant de crier haro sur la FAQ, peut etre est-ce le bouquin qui a tord :question:

---

La FAQ est correcte. On peut d'ailleurs faire:

Code:

---

1 2 3 4 5 6 7 8 9 10

struct x; class y;   class x { ... }; struct y { ... };

---

meme si j'ai cru comprendre que certaines versions du compilateur de MS ne l'acceptent pas.

J'ai vu, jean marc... nos posts se sont simplement croisé ;) :P

C'est quand meme grave qu'un bouquin qui prétend etre le sous main d'un programmeur fasse ce genre d'erreur ...:aie: :evil:

Citation:

---

Envoyé par koala01

C'est quand meme grave qu'un bouquin qui prétend etre le sous main d'un programmeur fasse ce genre d'erreur ...:aie: :evil:

---

Rien qu'au titre, j'ai l'impression que c'est le genre de bouquin ecrit a la va vite sur commande d'un editeur par quelqu'un n'ayant aucune experience professionnelle de programmation et aucune connaissance approfondie du langage decrit. Se copiant entre eux, leur seul effet est d'enrichir l'editeur et de creer et perpetuer des mythes.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Rien qu'au titre, j'ai l'impression que c'est le genre de bouquin ecrit a la va vite sur commande d'un editeur par quelqu'un n'ayant aucune experience professionnelle de programmation et aucune connaissance approfondie du langage decrit. Se copiant entre eux, leur seul effet est d'enrichir l'editeur et de creer et perpetuer des mythes.

---

Je ne te contredirai pas sur cette idée, car, il se fait que j'en étais presque parvenu à la meme conclusion...

Ceci dit, il ne dit pas non plus que des c:aie:

Citation:

---

Envoyé par koala01

Ceci dit, il ne dit pas non plus que des c:aie:

---

Si c'etait le cas, ils seraient beaucoup moins nuisibles.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Si c'etait le cas, ils seraient beaucoup moins nuisibles.

---

De fait, car, qui va avoir le courage de tester TOUT ce qu'ils peuvent dire sur plusieurs centaines de pages :P...

S'il ne disaient que des c:aie:, ce serait vite fait: on essaye deux trucs, ca foire, on a compris...

Mais quand ils en disent "de temps en temps", on essaye deux trucs, ca marche, on commence à leur faire confiance et c'est là que... bobo!!! :P