Discussion :

[Flint]

Concernant les problèmes d'identification, j'en vois 2 :

1. si on a une classe statique stat dans un objet de classe X, on peut écrire X.stat(), mais on peut aussi écrire, sur un objet x de classe X : x.stat(). Cette dernière forme prête à confusion, car on risque de croire que stat est une méthode d'instance, hors c'est une méthode statique.
2. Alors que l'appel des méthodes d'instance dépend de la classe réelle de l'objet sollicité, l'appel des méthodes statiques dépend de la classe déclarée de l'objet sollicité. Cela ajoute à la confusion.

Pour le 2, je suis d'accord.
Pour le 1, cela n'est pas spécifique à JAVA tu peux très bien avoir une méthode statique toto() d'une classe X en C++, tu peux écrire X::toto()
et si tu as une instance x de X tu peux écrire x->toto()
alors rien ne te dit que toto() est une méthode statique...

[yann2]

Bonjour,

j'avoue avoir du mal à comparer Java et C++.

Java est complètement objets mais pas le C++.

Surtout :

Java a été développé dans le cadre du projet GREEN (si mes souvenirs sont bons) qui devait faire communiquer votre cafetière avec votre grille-pains (en gros, c'est ça). Au départ, le C++ devait être utilisé, mais il a vite été écarté par les membres du projet qui ont décidé de mettre au point un nouveau langage (Java).


Donc : pouvons nous vraiment comparer Java et C++ ?
Il semble évident que ces deux langages ne touchent pas les mêmes types d'applications. Il y à toujours quelque chose qui va faire que l'on va choisir tel ou tel langage.

[Glob]

Java est complètement objets mais pas le C++.

Je dirais plutôt que Java est un petit plus objet que C++, mais pas complètement.
"2+2" n'est pas objet. "2.ajouter(2)" serait déjà plus "orienté objet". Il est vrai qu'il y a certaines différences (héritage simple vs. multiple, interfaces, ...) mais je trouve que sur le principe c'est la même chose.

Il semble évident que ces deux langages ne touchent pas les mêmes types d'applications. Il y à toujours quelque chose qui va faire que l'on va choisir tel ou tel langage.

Mmmhh... Je pense plutôt qu'il s'agit d'une question de goût et de connaissance du langage.
On préférera en principe d'utiliser le langage que l'on a eu l'opportunité d'apprendre. J'ai eu la chance de commncer en C, puis C++ (2-3 ans). Finalement, avec mes seules connaissances C++ et avec quelques indications sur les librairies à utiliser, j'ai codé un mini-chat mode console en une semaine. C'est dire si les langages sont proches dans leur syntaxe et dans les principes d'utilisation.
Finalement, à l'exception de 2 ou 3 domaines (en particulier l'accès direct à des couches basses du système), Java ou C++ c'est kif kif...

[yann2]

Je dirais plutôt que Java est un petit plus objet que C++, mais pas complètement.
"2+2" n'est pas objet. "2.ajouter(2)" serait déjà plus "orienté objet". Il est vrai qu'il y a certaines différences (héritage simple vs. multiple, interfaces, ...) mais je trouve que sur le principe c'est la même chose.

Ja, c'est vrai. Mais, en Java, quoiqu'il arrive, tu es obligé d'écrire une classe. En C++, tu fais comme tu veux (d'ailleurs trop de personnes utilises le C++ comme le C ). Ca m'est arrivé de voir des sources qui utilisaient Java comme un langage procédurale (berk!), mais on en voit moins que dans le C++ (et surtourt utilisait Java en procédural est une aberration).

Mmmhh... Je pense plutôt qu'il s'agit d'une question de goût et de connaissance du langage.

Il est vrai que dans certains cas, le choix du langage n'est pas important. Mais je persiste à dire que le C++ et le Java touchent un domaine d'applications différents (malgrès leurs ressemblances).
Je te renvoie à mon ancien post. Le C++ ne correspondait pas aux attentes du projet GREEN. Ils ont donc développé un nouveau langage différent du C++.

En fait, des applications que l'on peut faire en Java aujourd'hui pouvaient être réalisées en C++ avant l'existence de Java ("mais pourquoi faire simple quand on peut faire compliqué !" ).

On préférera en principe d'utiliser le langage que l'on a eu l'opportunité d'apprendre.

Je suis d'accord, mais ce n'est pas forcément le bon choix.

Finalement, à l'exception de 2 ou 3 domaines (en particulier l'accès direct à des couches basses du système), Java ou C++ c'est kif kif...

bof... (tableau en bas de la page : 11 domaines différents et y'en a plus)
http://www.emi.ac.ma/etudiants/cours...java_perf.html
...il y a de grandes différences entre le Java et le C++.

[Gabrielly]

Est-ce qu'on peut faire de la surcharge d'opérateur en Java sur une classe que tu définis comme en C++?
Est-ce qu'on peut utiliser des fonctions virtuelles en Java sans définir une interface comme classe de base.
Est-ce qu'il existe d'autre moyen de passation des variables que par références en Java.
Peut-on définir des classes templates au point de paramétrer la classe de base d'une classe enfant.
Utilise-t-on des fonctions templates comme en C++.
Peut-on déterminer avec précision la libération d'un objet car les desctructeur en java sont absents.
Et encore beaucoup d'autres techniques de la programmation orienté objet exclus en Java.

[Luc Hermitte]

Je réponds de mémoire.

a- Est-ce qu'on peut faire de la surcharge d'opérateur en Java sur une classe que tu définis comme en C++?
b- Est-ce qu'on peut utiliser des fonctions virtuelles en Java sans définir une interface comme classe de base.
c- Est-ce qu'il existe d'autre moyen de passation des variables que par références en Java.
d- Peut-on définir des classes templates au point de paramétrer la classe de base d'une classe enfant.
e- Utilise-t-on des fonctions templates comme en C++.
f- Peut-on déterminer avec précision la libération d'un objet car les destructeur en java sont absents.
g- Et encore beaucoup d'autres techniques de la programmation orienté objet exclus en Java.

a- Non. Mais sorti de la nécessité de définir des objets mathématiques l'intérêt est vite limité.

b- A ma connaissance, les "méthodes" java sont toutes des "fonctions virtuelles". Ceci dit, le "final" peut changer des petites choses à partir du moment où il intervient dans la (re)définition de la méthode.

c- Cela n'existe pas.. en java. En Java les paramètres sont tous systématiquement passés par valeur. C'est dans le texte qui sert de référence -- je sais qu'il y en aura qui vont douter, et pourtant...

La preuve, écris une fonction swap. Tu ne peux pas!
La référence est un type particulier, sorte de pointeur vers une donnée qui s'avère être un objet. Tu peux échanger (en passant par les paramètres de la fonction swap) les états de deux objets référencés, mais pas les valeurs des références (paramètres rééls (!= formel); i.e. on peut échanger les valeurs des paramètres formels, mais il n'y aura aucun impact sur les paramètres réels).

Maintenant, avec Java 1.5 (?) qui introduit l'auto-boxing (en java), la donne est peut-être changée. Mais je passe la main, là dessus, pour les personnes plus au courant que moi.

d- Java 1.5 introduit les générics. Qui correspondent à l'un des deux paradigmes rendus possibles en C++ via les templates : la généricité. Sorte de sucre syntaxique qui est fort pratique. Rien du côté du "generative programming" (j'ai bien aimé la distinction à ce sujet que j'ai croisée dans le forum associé à un récent article sur artima)

e- Je ne sais plus si les générics fonctionnent sur les fonctions. Si oui, même commentaire que pour d-

f- Le RAII se traduit par le "dispose pattern" (aka try-finally). Les destructeurs du C++ étant au service de la libération déterministe.
Donc, même si un objet Java ne sera pas exactement détruit, on peut libérer des ressources à coup sûr. Autre syntaxe, autre philosophie.

g- Diverses autres choses différent (sémantique de valeur, invariants, compléxité, ...) . Avec toutes ces pages, cela a bien dû déjà être traité.

EDIT: petit lien.

[adiGuba]

e- Je ne sais plus si les générics fonctionnent sur les fonctions. Si oui, même commentaire que pour d-

Oui, on peut très bien utiliser les générics sur les méthodes (indépendamment de sa classe), c'est par exemple le cas de la méthode getAnnotation() de Class<T> :

Code :

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

public <A extends Annotation> A getAnnotation&#40;Class<A> annotationClass&#41;

Sinon, pour revenir aux questions de Gabrielly : le C++ et Java ont une approche différente de la POO... chacune avec ses avantages et ses défauts...

a++

[Gabrielly]

J'ai fais un peu de prog en java et j'ai constaté que seul les types primitives comme int, double, ... sont passés par valeur. Mais un objet java est passé uniquement par référence. J'ai déjà fais des tests de "swap"

En C++, tu peux crées différents types de variables (primitives et objets inclus).
Soit des variables locales sur la pile.
Soit des variables créées dynamiquement sur le tas; avec new et delete ou avec gcnew où le delete est optionel (C++ CLI avec tas non mangé et managé)
Soit des varibles globales statiques en dehors de toutes classes.
Soit des variables locales statiques.

Je suis curieux de constaté que toutes les méthodes en Java sont virtuelles. Mais je doute sur cette affirmation. Au contraire sur le forum de Java. Les javamen m'ont dit qu'il faut utiliser une interface avec des méthodes virtuelles pures et ensuite faire de cette interface une classe de base d'une classe enfant qui surchargerait ces méthodes. Moi j'affirme crée des fonctions virtuelles sans qu'elles aient besoin d'être pure (abstract) et sans null besoin d'utiliser une interface comme classe de base.

A ma liste des questions j'oubliais les différents types d'héritage supportés en C++.
-Héritage simple ( un parent un enfant) : Java le fais aussi
-Héritage multiple ( des parents un enfant) : Non pas en java
-Héritage virtuelle ( un parent commun des enfants) : non pas en java.

Et encore je constate que le fait que les fonctions globales sont absentes en java; ce dernier a contourné le problème avec des fonctions membres static dans ces classes.
Le C++ les utilise déjà bien et il ajoute également les membres amis d'une classe.

Est-ce qu'on peut obtenir une référence sur les fonctions pour ne pas dire des pointeurs sur des fonctions?
Y-a-t-il des macros, des typedefs, des enums???

Quand j'observe la bibliothèques ATL je suis admiré par le professionnalisme avec lequel ils utilisent le C++. Un C++ avec toute sa puissance et ses techniques de constructions objets. En tout cas un débutant va se perde rien qu'a examiner soigneusement les fichiers atlcom.h et atlbase.h. Ce sont des pro.

Sincèrement parlant, Je ne vois pas un langage autre que le C++ qui peut faire cela. Toutes les constructions sont possibles. Pas de limitation dans sa philosophie de la POO. Je ne vise pas le types de projets où sont terrains d'actions pour les applications. Mais je parle du C++ de part sa conception en POO.

Le C++ ne touche pas seulement au bas niveau (pour ceux qui veulent restreindre le C++ aux matériels). De bas en haut il est présent.
Je crois que je m'arrête...

[Luc Hermitte]

J'ai fais un peu de prog en java et j'ai constaté que seul les types primitives comme int, double, ... sont passés par valeur. Mais un objet java est passé uniquement par référence. J'ai déjà fais des tests de "swap"

Ah ? Et tu as réussi à écrire un swap ? Je suis surpris. Avec Java 1.5 peut-être ?
Je t'assure, tout est toujours passé par valeur en java. Et de même que les pointeurs sont passés par valeur en C, les références sont passées par valeur en Java -- et maintenant, il y a l'auto-boxing ...
Hop, un petit lien http://javadude.com/articles/passbyvalue.htm
Etrangement, je me souviens avoir lu très clairement et explicitement dans ce qui leur servait de norme (la spec Java, quoi), que le pass-by-value était la règle. Mais je n'arrive pas à retrouver le texte. Des fois je me demande si le paragraphe n'aurait pas été réécrit.
Bref, essaie google avec "Java" et "pass-by-value". Il n'y a pas de pinaillage possible. Le passage par valeur est la règle!

Je suis curieux de constaté que toutes les méthodes en Java sont virtuelles. Mais je doute sur cette affirmation. Au contraire sur le forum de Java. Les javamen m'ont dit qu'il faut utiliser une interface avec des méthodes virtuelles pures et ensuite faire de cette interface une classe de base d'une classe enfant qui surchargerait ces méthodes. Moi j'affirme crée des fonctions virtuelles sans qu'elles aient besoin d'être pure (abstract) et sans null besoin d'utiliser une interface comme classe de base.

Je ne vois pas où tu veux en venir, ni le rapport avec ce qu'ils t'auraient dit. La liaison est toujours tardive (aka dynamique) en Java. En C++, on a le choix entre la liaison tardive/dynamique (virtual) et la statique (celle par défaut sans le "virtual").

Le "pure" ne change absolument rien à la donne.
BTW, ils voulaient certainement dire "rédéfinition", et non "surcharge" qui est un sucre syntaxique sans grand rapport avec la liaison tardive.

A ma liste des questions j'oubliais les différents types d'héritage supportés en C++.
-Héritage simple ( un parent un enfant) : Java le fais aussi
-Héritage multiple ( des parents un enfant) : Non pas en java
-Héritage virtuelle ( un parent commun des enfants) : non pas en java.

Java supporte l'héritage multiple d'interfaces -- cela ressemble pas mal à ce à quoi COM a dû t'habituer (pour les interfaces, uniquement). Par contre, cela reste des interfaces et non des contrats -> pas possible de rajouter les invariants (& pre-, & post-conditions) nativement -- il existe un outil externe qui pallie à cela.

Et sans héritage multiple d'implémentation, il n'y a plus besoin de l'héritage virtuel. Ceci dit en interne, il y a peut-être bien quelque chose de similaire qui se passe par défaut.

Est-ce qu'on peut obtenir une référence sur les fonctions pour ne pas dire des pointeurs sur des fonctions?

C'est dans leur FAQ d'ici. "Non", est ce que je crois bien avoir lu.
Mais c'est un détail, avec un peu de "refactoring", on tranforme les fonctions en objets (foncteurs) et on obtient la même chose. Même en C++, c'est parfois mieux de procéder de la sorte.

Le C++ ne touche pas seulement au bas niveau (pour ceux qui veulent restreindre le C++ aux matériels). De bas en haut il est présent.
Je crois que je m'arrête...

Vers le début du fil, il y a pas mal de mécompréhension et mélange entre C et C++ effectivement. Cela donne des échanges parfois sur-réalistes. Bien qu'il faille reconnaitre que l'héritage du C donne d'excessivement mauvaises habitudes qui sont critiquées avec raison.

PS: attention à ne pas virer dans le troll -- et c'est quelqu'un qui n'aime pas le Java, en tant que langage (hors JVM et technologies associées), qui te dit ça.

[adiGuba]

J'ai fais un peu de prog en java et j'ai constaté que seul les types primitives comme int, double, ... sont passés par valeur. Mais un objet java est passé uniquement par référence.

C'est vrai à 100%. Mais je n'ai jamais été géné par cela (au contraire).
Le seul intérêt de passer une copie d'un objet à une méthode est d'éviter que ce dernier soit modifié par la suite. En java on utilise pour cela des classes immuables...

En C++, tu peux crées différents types de variables (primitives et objets inclus).
Soit des variables locales sur la pile.
Soit des variables créées dynamiquement sur le tas; avec new et delete ou avec gcnew où le delete est optionel (C++ CLI avec tas non mangé et managé)
Soit des varibles globales statiques en dehors de toutes classes.
Soit des variables locales statiques.

C'est encore tout à fait vrai, et c'est encore une différence de philosophie : Java laisse la gestion de la mémoire à la machine virtuelle...

Je suis curieux de constaté que toutes les méthodes en Java sont virtuelles. Mais je doute sur cette affirmation. Au contraire sur le forum de Java. Les javamen m'ont dit qu'il faut utiliser une interface avec des méthodes virtuelles pures et ensuite faire de cette interface une classe de base d'une classe enfant qui surchargerait ces méthodes. Moi j'affirme crée des fonctions virtuelles sans qu'elles aient besoin d'être pure (abstract) et sans null besoin d'utiliser une interface comme classe de base.

Soit il y a eu une erreur de compréhension, soit on t'a mal renseigné... car toutes les méthodes en Java sont virtuelles (sauf bien sur les méthodes static, final, ou private). Le mot clef final permet d'interdir la redéfinition. Que signifie le mot-clé final ?.
La preuve :

Code :

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

1
2
3
4
5
public class A {
    public void method() {
    	System.out.println("A.method()");
    }
}

Code :

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

1
2
3
4
5
6
public class B extends A {
	@Override
    public void method() {
    	System.out.println("B.method()");
    }
}

Code :

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

1
2
3
4
5
6
7
	public static void main(String[] args) throws Exception {
		A a1 = new A();
		A a2 = new B();
		
		a1.method();
		a2.method();
	}

A ma liste des questions j'oubliais les différents types d'héritage supportés en C++.
-Héritage simple ( un parent un enfant) : Java le fais aussi
-Héritage multiple ( des parents un enfant) : Non pas en java
-Héritage virtuelle ( un parent commun des enfants) : non pas en java.

L'héritage multiple n'est pas implémenté volontairement. L'héritage de deux classes différentes peut poser des problèmes si elles possedent chacunes une méthode virtuelle avec une signature identique. Ce problème est moindre en C++ puisque par défaut les méthodes ne sont pas virtuelles...

En quoi consiste l'héritage virtuelle ? S'il s'agit de plusieurs classes qui héritent d'une même classe c'est tout à fait possible en Java (d'ailleurs toutes les classes héritent de Object).

Et encore je constate que le fait que les fonctions globales sont absentes en java; ce dernier a contourné le problème avec des fonctions membres static dans ces classes. Le C++ les utilise déjà bien et il ajoute également les membres amis d'une classe.

Est-ce vraiment un concept de POO ???
Sinon fonctions globales ou méthodes statiques... à mon sens c'est juste une différence d'écriture... et les méthodes statiques ont accès aux divers membres de la classe conteneur, ce qui est similaire au mot-clef friends si je ne me trompe pas... (si je me rappelle bien mes cours de C++, friends permet d'autoriser une fonction à d'utiliser les membres d'une autre classe... non ?)

Est-ce qu'on peut obtenir une référence sur les fonctions pour ne pas dire des pointeurs sur des fonctions?

Non, on utilise généralement une interface pour cela (on passe ainsi en même temps la référence de l'objet). Sinon on peut toujours utiliser la reflexivité...

Y-a-t-il des macros, des typedefs, des enums???

Pas de macros ni de typedefs... mais ce ne sont pas des concepts de POO...
Pour les enums, ils ont été introduit avec Java 5.0 et correspondent à de vrai objet et non pas à des int...

Quand j'observe la bibliothèques ATL je suis admiré par le professionnalisme avec lequel ils utilisent le C++. Un C++ avec toute sa puissance et ses techniques de constructions objets. En tout cas un débutant va se perde rien qu'a examiner soigneusement les fichiers atlcom.h et atlbase.h. Ce sont des pro.

Je ne connais pas ATL... mais les fichiers headers ne devraient-ils pas être lissible pour tous ???

Sincèrement parlant, Je ne vois pas un langage autre que le C++ qui peut faire cela. Toutes les constructions sont possibles. Pas de limitation dans sa philosophie de la POO. Je ne vise pas le types de projets où sont terrains d'actions pour les applications. Mais je parle du C++ de part sa conception en POO.

Mis à part l'héritage multiple, il n'y a pas à ma connaissance de concept POO en plus dans le C++ par rapport à Java...
Et personnellement je trouve la POO de Java plus clair et moins "casse-gueule" que celle du C++.

Le C++ ne touche pas seulement au bas niveau (pour ceux qui veulent restreindre le C++ aux matériels). De bas en haut il est présent.

On est tout à fait d'accord sur ce point.
Mais en haut niveaux le Java permet d'ignorer (en partie) les problèmes de gestion de la mémoire et des pointeurs...

a++

[Gabrielly]

Gabrielly a écrit:

Le C++ ne touche pas seulement au bas niveau (pour ceux qui veulent restreindre le C++ aux matériels). De bas en haut il est présent.

On est tout à fait d'accord sur ce point.
Mais en haut niveaux le Java permet d'ignorer (en partie) les problèmes de gestion de la mémoire et des pointeurs...

Le C++ managé gère aussi la gestion de la mémoire et des pointeurs.
Les pointeurs intelligents de C++ le font également.

Merci de préciser que l'héritage mulitple en Java est valable uniquement pour les interfaces et non pour les classes ordinaires comme en C++

En quoi consiste l'héritage virtuelle ? S'il s'agit de plusieurs classes qui héritent d'une même classe c'est tout à fait possible en Java (d'ailleurs toutes les classes héritent de Object).

Attention l'héritage virtuel n'est pas pour les javamen.
Qu'est-ce que tu racontes? Les MFC dispose aussi d'une classe de base CObject mais la différence est que la classe Object n'est pas commune dans le sens où les classes enfants disposent chacune de sa propre copie de sa classe de base Object.
Avec une classe de base virtuelles les classes enfants partagent la même copie.

[soleuh]

Le C++ n'a jamais eu pour but de d'être un langage sur-simplifié. Il défini tous les concepts objets, même ceux dont l'utilisation est à presque tout les coups une mauvaise pratique comme l'héritage privé, l'héritage multiple, les friends, et j'en passe... Parceque parfois, ça peut être utile !
Mais le C++ n'est pas qu'objet. Aujourd'hui, on préfère l'utilisation des templates sur celle des méthodes virtuelles, pour des raisons de typage et de performances (calculé à compile-time contre runtime pour les méthodes virtuelles).

D'ailleur les Generics en java n'ont pas grand chose à voir avec les templates en C++. Bon le minimum est bien là, mais il est, à ma connaissance, pas possible par ce biais de générer du code, utiliser des expressions templates (avec quelques surcharges d'opérateurs en plus...) et tout ce genre de choses qu'on retrouve assez souvent en C++ (dans les designs dits modernes) aujourd'hui.

Enfin, en utilisant la STL et BOOST, on arrive à faire pas mal de choses (portable, optimisé un minimum, ...) en C++ contrairement à ce qu'on a l'habitude d'entendre. Tout le framework java n'y est pas, c'est certain !!! Mais bon ça se construit petit à petit. Pour le reste, le problème est qu'il y a trop de choix en C++ (comment choisir entre 36 bibliotèques graphiques ?!).

Mais bon c'est vrai que le C++ Standards Committee ne dépense pas autant que chez sun pour promouvoir le C++, et pour cause !

I'm not as paternalistic as some language designers. I may have romantic notions of how competent users—in this case programmers—are, but I don't consider programmers on average stupid, and I would like to see them as more respected professionals.

Bon c'est sorti du contexte, mais je vais pas citer tout l'interview qui se situe ici : http://www.artima.com/intv/eleganceP.html

PS : Outre l'utilisation des smart_ptr et autres auto_ptr de la STL ou de BOOST, la gestion de la mémoire, avec un peu d'habitude, ne prend pas plus de temps que ne pas la gérer... mais bon ils sont fort chez sun pour nous faire croire qu'on est tous des boulets qui ne peuvent pas faire un delete ... et par conséquent, qu'il faut un GC pour gérer ça, et qu'on ne peut pas faire autrement ! D'ailleur, le C++0X devrait intégrer un GC il me semble, mais ce, de façon optionnelle !

[soleuh]

(Je peux pas éditer mon post ? flute.... je double mon post précédent alors, désolé !)

Avec une classe de base virtuelles les classes enfants partagent la même copie.

Je n'ai pas compris de quelle copie tu parlais...

[®om]

Est-ce qu'on peut obtenir une référence sur les fonctions pour ne pas dire des pointeurs sur des fonctions?

Non, mais en POO, on utilise le design pattern "Commande"...

Sinon, dans certains de tes posts, je trouve que tu énumères tout ce que tu peux faire en C++, et que tu cherches ce qui n'existe pas en java, sans te demander si c'est mieux que ça n'existe pas pour la conception

Ce n'est que mon avis

[badra]

"C++ beaucoup plus rapide que java."

C'est ce que j'ai croyé moi aussi mais en testant une fonction récursive qui résoud la suite de Fibonacci:
U(0)=1
U(1)=2
U(n)=U(n-2)+U(n-1)
j'ai découvert que la même version de la fonction écrite en java était plus rapide que en celle écrite en c++(tout en respectant les petites différences syntaxiques entre les deux langages).

[Luc Hermitte]

Il défini tous les concepts objets, même ceux dont l'utilisation est à presque tout les coups une mauvaise pratique comme l'héritage privé, l'héritage multiple, les friends, et j'en passe... Parceque parfois, ça peut être utile !

Ou parce quand ce n'est pas utilisé à tord et à travers, c'est une excellente et efficace approche ?
C'est exactement le même problème qu'une mauvaise utilisation d'un idiome (/d'un élement de syntaxe) dans une sémantique pour laquelle il n'est pas prévu -- ex: héritage (public en C++, quelconque en Java) pour modéliser autre chose que le LSP (ex: liste triée qui hérite de liste, carré qui hérite de rectangle), opérateur d'affectation et autres opérateurs mathématiques sur les types à sémantique d'entité, ...

Mais le C++ n'est pas qu'objet. Aujourd'hui, on préfère l'utilisation des templates sur celle des méthodes virtuelles, pour des raisons de typage et de performances (calculé à compile-time contre runtime pour les méthodes virtuelles).

D'accord avec la première phrase. Pas du tout avec les suivantes. On ne sort pas les templates parce que c'est "mieux", mais parce qu'ils seront plus adaptés à la résolution d'un problème précis où le paradigme objet était appliqué de manière imparfaite et pas toujours appropriée -- cf les conteneurs de void * (ou quelconque autre type Object racine de toute chose) ; cf les types modélisant des unités physiques, même celles qui n'ont pas forcément de nom (m^4 . s^-2)

Mais bon c'est vrai que le C++ Standards Committee ne dépense pas autant que chez sun pour promouvoir le C++, et pour cause !

Tout à fait. Mais il n'est inscrit dans aucune logique mercantile, et il n'a pas vraiment à le faire. A nous de faire comprendre que le C++ n'est pas le C avec quelques malheureux mots-clés en plus (class, public, virtual, new, delete).

PS : Outre l'utilisation des smart_ptr et autres auto_ptr de la STL ou de BOOST, la gestion de la mémoire, avec un peu d'habitude, ne prend pas plus de temps que ne pas la gérer...

Il y a eu un "débat" sur la pertinence des GC dans le coin. Mais le côté gestion implicite déterministe de la mémoire et autre ressources n'a pas vraiment été considéré comme une alternative aux GC ou à la gestion manuelle.

Non, mais en POO, on utilise le design pattern "Commande"...

soleuh a cité artima, qui est un excellent site que je conseille à tous, quelque soit le langage. Dernièrement, dans le weblog de James O' Coplien, sur artima donc, je suis tombé sur ses "ruminations" quant au multi-paradigm design au sujet duquel il avait sorti une thèse et un peu plus tard un bouquin. Il y a maintenant 13ans.
(Le bouquin peut changer dans son style. C'est pas que de la technique, loin de là. Je pense qu'il faut avoir un peu de recul pour l'aborder sereinement, peut-être plus que le GoF. Et je ne regrette pas du tout de l'avoir acquis)
Bref, un truc a été dit comme quoi les DP devraient trascender les paradigmes. Et quelques part, un DP qui contourne une faille d'un paradigme n'en est plus forcément un.

Ce n'est que ma maladroite interprétation de ses propos que vous pourrez consulter ici:
Signs of the Next Paradigm Shift: Part II
Signs of the Next Paradigm Shift: Part I
Sa thèse, consultez-là ansi que d'autres critiques avant d'investir dans le bouquin.


Quant au pattern commande, ce qui est important, c'est la notion de commande. Pas un type de hierarchie particulière. Les closures (je crois) et autres types function conviennent parfaitement à la définition de commandes.

"C++ beaucoup plus rapide que java."

C'est ce que je croyais moi aussi mais en testant une fonction récursive qui résoud la suite de Fibonacci:
U(0)=1
U(1)=2
U(n)=U(n-2)+U(n-1)
j'ai découvert que la même version de la fonction écrite en java était plus rapide que en celle écrite en c++(tout en respectant les petites différences syntaxiques entre les deux langages).

Pourquoi suis-je méfiant ? On pourrait voir les codes ? Et les compilos ?

[soleuh]

Ou parce quand ce n'est pas utilisé à tord et à travers, c'est une excellente et efficace approche ?

Oui pour l'héritage public, l'héritage multiple et les friends qui peuvent effectivement être très utile. Moins vrai pour l'héritage privé ou protected à mon sens. A vrai dire, je n'en vois pas trop d'autre que le bidouillage, mais j'imagine qu'il doit bien y avoir un façon de l'utiliser efficacement.

On ne sort pas les templates parce que c'est "mieux", mais parce qu'ils seront plus adaptés à la résolution d'un problème précis où le paradigme objet était appliqué de manière imparfaite et pas toujours appropriée -- cf les conteneurs de void * (ou quelconque autre type Object racine de toute chose) ; cf les types modélisant des unités physiques, même celles qui n'ont pas forcément de nom (m^4 . s^-2)

Mouai. Disons qu'il y a deux sortes de polymorphisme : statique et dynamique. En java (entre autre, même si à priori c'est moins vrai avec les Generics maintenant... une pauvre rustine pour combler les lacunes du langage), on utilise à tord et à travers le polymorphisme dynamique (qui marche dans tous les cas) au détriment de son homologue dynamique. Le polymorphisme statique assure un typage plus fort, donc, d'après moi, à utiliser dès qu'on peut !

Il y a eu un "débat" sur la pertinence des GC dans le coin. Mais le côté gestion implicite déterministe de la mémoire et autre ressources n'a pas vraiment été considéré comme une alternative aux GC ou à la gestion manuelle.

Une alternative, peut être pas, mais une aide à la gestion manuelle, pourquoi pas

Pourquoi suis-je méfiant ? On pourrait voir les codes ? Et les compilos ?

Tout pareil, ne sont comparable que deux programmes optimisés. Deux bouts de codes non optimaux (même tous les deux) ne peuvent pas être comparé sans introduire un biais lié à la connaissance qu'à le rédacteur des deux langages qu'il veut comparer.
De toutes façons, il n'y a pas que le temps d'exécution à prendre en compte (espace mémoire utilisé, mais aussi temps de compilation, etc....)

[soleuh]

Encore une fois, je ne peux pas éditer et je m'en excuse.
Je me pausais juste la question, à savoir si les Genercis étaient bien géré à la compilation en java, il me semble avoir lu qu'il s'agissait d'un void * ? Auquel cas, je présume qu'il n'y a pas de spécialisation partielle, et donc que le polymorphisme statique ne vaut pas grand chose en java ? Une rustine, un jouet qui marche pour les cas les plus simples tels que les conteneurs

Enfin, c'est juste une question, je ne connais pas vraiment le java. Si j'ai dit une grosse bétise, je m'en excuse et serais content d'en apprendre plus !

[Luc Hermitte]

Le polymorphisme peut être vu suivant d'autres axes : inclusion et paramétrique, si on reprend la taxinomie de Cardelli dans le cas des deux polymorphismes "universels" -- il en reste deux ad'hoc (surcharge et convertions implicites).

Les templates jouent aussi dans la cour du paramétrique. De même que les generics, bien que l'implémentation s'apparente à du sucre syntaxique sur du dynamique.
IIRC, les generics de Java manipulent des Objects en interne, mais downcastent pour nous (de façon transparente) vers le type déclaré. Le framework .NET a une autre approche si j'ai bien suivi.

"statique vs "dynamique" correspond pour moi à une vue limite orientée implémentation. Mais en fait, il y a deux autres degrés si je reprends le découpage de James Coplien : compile-time (compilation conditionnelle par flags ; manuel (NDEBUG) ou automatique (OS)), Link (and Load) Time, en plus de Source Time (typiquement les template), et Run Time (typiquement les fonctions virtuelles)

Dans le genre, cela me fait penser aux mixin-layers. En C++, on fait ça avec du CRTP en couches de classes. Soit du template. Par contre, c'est quelque chose orienté implémentation : en fonction des aspects et services que l'on veut voir implémentés, on assemble des couches. Les templates sont utilisés pour de la génération de code.
Si on repart sur le polymorphisme d'inclusion, et bien cela n'a rien à voir avec ce que l'on réalise. Le but n'est pas de permettre des substitutions, on assemble un objet par superposition de services atomiques.
La variabilité est effectivement statique, au niveau du code (ni d'exécution, ni d'OS, ...)


L'héritage privé est très bien pour la réutilisation de code (soit disant le super truc génial que merci la POO pour nous donner gracieusement cette possibilité qui n'existe nulle part ailleurs) sans substituabilité -- cf les listes triés définies à partir de listes. Quand le couplage fort n'est pas un problème, où qu'il est désiré, c'est parfait. Sinon point de repit hors de la composition.
NB: l'héritage privé est aussi un couplage statique au contraire de la composition qui peut être dynamique.

Comme quoi il n'y a pas de "statique" c'est toujours mieux que "dynamique" ou vice versa. Ca dépend.

[soleuh]

Merci pour cette belle réponse !

"statique vs "dynamique" correspond pour moi à une vue limite orientée implémentation. Mais en fait, il y a deux autres degrés si je reprends le découpage de James Coplien : compile-time (compilation conditionnelle par flags ; manuel (NDEBUG) ou automatique (OS)), Link (and Load) Time, en plus de Source Time (typiquement les template), et Run Time (typiquement les fonctions virtuelles)

Je veux bien croire qu'il s'agisse d'une vue orientée implémentation. Je m'incline sur ce point. Mais ce que tu appelles compile-time et link time ne sont ils pas dépendant de la plateforme, et non du langage ?

L'héritage privé est très bien pour la réutilisation de code (soit disant le super truc génial que merci la POO pour nous donner gracieusement cette possibilité qui n'existe nulle part ailleurs) sans substituabilité -- cf les listes triés définies à partir de listes. Quand le couplage fort n'est pas un problème, où qu'il est désiré, c'est parfait. Sinon point de repit hors de la composition.
NB: l'héritage privé est aussi un couplage statique au contraire de la composition qui peut être dynamique.

Pour les listes triées définies à partir de listes, j'aurai justement utilisé la composition car la liste de base existe sans la liste triée... merci en tous cas de me faire avancer sur ce point là !

Comme quoi il n'y a pas de "statique" c'est toujours mieux que "dynamique" ou vice versa. Ca dépend.

Biensur que ça dépend, ça dépend toujours ! Seulement, lorsqu'on a le choix entre les deux (tout ce qui est fait statiquement peut être fait dynamiquement...), je ne vois pas pourquoi utiliser une méthode dynamique.