Discussion :

[GyZmoO]

Bonjour a tous !
Bon ben tout est dans le titre, je dois me mettre a C++ dans pas lontemps, et j'ai jamais programmé dans ce langage. Je connais Java pas trop mal, et tous les principes OO, alors je me tourne vers vous car dans les tutos etc, je ne sais pas par quoi commencer? Peut être y'a t il des trucs inutiles a apprendre étant donné que j'ai déja fait de l'OO avec Java?

Merci

[aoyou]

Peut être y'a t il des trucs inutiles a apprendre étant donné que j'ai déja fait de l'OO avec Java?

Ca t'aidera sûrement et refaire une passe sur l'OO ne te fera pas de mal d'autant plus que certains concepts OO sont propres au C++ : je pense en particulier à l'amitié, à l'héritage multiple ou à la notion d'interface (à la Java) qui n'existe pas en C++.

C'est un peu court...
http://www.metz.supelec.fr/~frezza/D...C++/index.html

Tu trouveras ici les tutoriels C++ (mais tu dois déjà le savoir)
http://cpp.developpez.com/cours/

Si tu as le courage, un bestof sur Java vs C++.
http://www.developpez.net/forums/showthread.php?t=1886

[Mat007]

Salut,

(...) la notion d'interface (à la Java) qui n'existe pas en C++.

Oui enfin une classe avec que des méthodes virtuelles pures joue le même rôle, mais c'est vrai qu'il n'y a pas de mot clef consacré.

MAT.

[Kujara]

Salut,


Oui enfin une classe avec que des méthodes virtuelles pures joue le même rôle, mais c'est vrai qu'il n'y a pas de mot clef consacré.

MAT.

Chose peu connue apparemment : vc++ a un mot clef pour ça : __interface

Mais effectivement c'est pas standard ^^.

[Médinoc]

Et ça réclame un VC++ pas trop vieux.

[Suryavarman]

la notion d'interface (à la Java)

A la delphi , java et .net l'ont repiqué.

[GyZmoO]

Merci pour vos réponses , je vais me tourner vers les liens cités

[JolyLoic]

C'est marrant, moi j'aurais dit le contraire, Java supporte très mal les interfaces, contrairement à C++, car il ne permet pas dans ces interfaces de vérifier des pré/post conditions.


Autrement, du Java au C++, je pense que ce qui va être le plus déroutant au départ va être :
- Le modèle mémoire, où tout n'est pas pointeur, et où il faut gérer soi même des choses que Java gère tout seul (attention, soi-même ne veut pas dire à la main, on s'aide généralement d'outils comme les smart pointers), mais qui permet une destruction déterministe de manière plus légère (RAII, plutôt qu'un dispose dans un finally).
- La façon d'organiser son code en plusieurs fichiers, avec le système archaïque des .h que l'on inclus textuellement, et ce qui en découle
- La pauvreté relative de la bibliothèque standard, ce qui oblige assez vite à se plonger dans l'extrême richesse des bibliothèques non standard de styles/qualités divers et variés, et les difficultés de choix que ça implique.

[Mat007]

C'est marrant, moi j'aurais dit le contraire, Java supporte très mal les interfaces, contrairement à C++, car il ne permet pas dans ces interfaces de vérifier des pré/post conditions.

Je crois que je vois ce à quoi tu fais allusion (on en avait un peu parlé dans un autre sujet) mais ça ne serait pas plus quelque chose de basé sur le modèle de conception template method ?
A la limite ça peut se réaliser en Java de la même façon qu'en C++ avec une classe abstraite qui factorise les vérifications de conditions communes aux classes concrètes, ou bien c'est plus subtil que ça ?

MAT.

[JolyLoic]

C'est un peu ça sur le plan de la réalisation technique, sauf que sur le plan conceptuel le template method, tel que décrit dans les design patterns, est à la fois plus générique que la validation de pré/post conditions, et beaucoup moins fondamental et omniprésent. Il est extrêmement rare que j'écrive une fonction virtuelle publique (quand ça m'arrive, c'est en général non prévu au départ, quand je n'ai pas le temps de faire du refactoring correct).

La où la réalisation bloque en Java, c'est que bien qu'une classe puisse implémenter plusieurs interfaces, elle ne peut dériver que d'une classe abstraite. Donc sur n interfaces d'accès à une classe, (n-1) ne peuvent pas vérifier leurs contrats.