Discussion :

[kpouer]

Salut, je ne pense pas que l'introspection ait été ajoutée a java pour pallier un manque mais tout simplement parce que ca apporte des fonctionnalités intéréssantes.
Par exemple un système de plugin en tire parti a merveille, on définit une interface, et on ne connait pas les implémentations. Ces dernières sont ajoutées plus tard et on ne change qu'un fichier de config pour définir l'implémentation que l'on veut utiliser. Cela peut même se faire dynamiquement sans redémarrer.

Sinon sans rapport avec l'introspection : j'entend partout que les templates c'est bien mieux que les generics. Oui mais en quoi ? J'ai utilisé les 2, mais je n'ai pas une aussi grande expérience du c++ que du java et donc je n'ai pas vu d'avantage décisif aux templates, quelqu'un pourrait il éclairer ma lanterne ?

[adiGuba]

Sinon sans rapport avec l'introspection : j'entend partout que les templates c'est bien mieux que les generics. Oui mais en quoi ?

C'est surtout une approche différente :

• Les templates du C++ représente en faite un "modèle" que le compilateur utilise pour générer du nouveau code. En gros c'est comme s'il faisait un copier-coller + un remplacement de valeur.
  Cela permet beaucoup de chose car les vérifications sont faitent pour chaque type lors de leurs utilisations, mais cela a aussi le défaut de générer une nouvelle classe par type utilisé en paramétrage.
  
• Les Generics de Java se basent sur des classes génériques, et en fait le compilateur se charge de vérifier l'utilisation et de cacher les cast. Du coup cela ne génère pas plusieurs versions de la même classe, mais cela a le désavantage de rendre certaines choses impossible (new T() par exemple) puisqu'on ne connait jamais le type en paramétrage...

J"vais fait un billet un peu plus complet sur le sujet : Les Generics ne sont pas des Templates comme les autres !


a++

[Alp]

adiGuba > dans le blog tu te trompes. Une méthode peut être template sans que la classe à laquelle elle appartient le soit. Et si la classe est template aussi, la méthode peut en plus l'être également.
Enfin bon

D'ailleurs j'ai une question. Est-ce que ce genre de chosess se fait en Java avec les Generics ?

[ac_wingless]

adiGuba, tu résumes bien les objectifs initiaux des templates C++, tels qu'ils étaient perçus en 1994 lors de la présentation de la STL. Depuis, le moins qu'on puisse dire, c'est que que les templates C++ se sont révélés formidablement plus puissants que prévu, d'ailleurs à la surprise des spécialistes du langage.

generic programming is the area where use of C++ has progressed the furthest relative to the support offered by the language

My understanding of templates was still at the container-of-T stage, while Barton, Nackman, Stepanov and others were demonstrating that such uses barely scratched the surface of what templates could do.

Les travaux d'Alexandrescu, Abrahams et Gurtovoy ont popularisé des techniques insoupçonnées à l'époque de la définition des templates. Ces utilisations (quelques exemples ici) montrent la différence avec les Generics de Java et le "duck typing" de Ruby. Les concepts de C++0x devraient étendre ces principes, et aussi mettre un peu d'huile dans les rouages des écritures actuellement utilisées dans la métaprogrammation, qui sont assez peu lisibles il faut le reconnaitre (en particulier les messages d'erreur à la compilation).

Je ne souhaite pas du tout entrer dans la controverse Java/C++, simplement souligner qu'il y a une différence bien plus grande entre les templates C++ et les Generics de Java qu'indiqué dans le blog (l'instanciation multiple de code n'est qu'un détail sans intérêt vis-à-vis de ce qui est effectivement apporté par les templates en termes de conception).

[adiGuba]

adiGuba > dans le blog tu te trompes. Une méthode peut être template sans que la classe à laquelle elle appartient le soit. Et si la classe est template aussi, la méthode peut en plus l'être également.
Enfin bon

Oui cela m'avait été signalé mais je n'avais pas modifié le billet... Il faudrait que je le fasse

Mais pour moi le principal n'était pas vraiment là : je voulais plutôt mettre le focus sur le fait que malgré une syntaxe proche il ne s'agit pas du tout des mêmes notions...

D'ailleurs j'ai une question. Est-ce que ce genre de chosess se fait en Java avec les Generics ?

Si j'ai bien compris cela permet de générer du code différent selon le type.
Ce n'est pas possible avec les Generics car on fait complètement abstraction du type.

Pour quelque chose de similaire j'utiliserais des interface générics...

adiGuba, tu résumes bien les objectifs initiaux des templates C++, tels qu'ils étaient perçus en 1994 lors de la présentation de la STL. Depuis, le moins qu'on puisse dire, c'est que que les templates C++ se sont révélés formidablement plus puissants que prévus, d'ailleurs à la surprise des spécialistes du langage.

Mon C++ est assez rouillé en effet

Par contre vous me titiller avec ce principe de "concepts"... il faudra que j'y jettes un coup d'oeil lorsque j'aurais un peu de temps


a++

[Alp]

On a un projet d'article en cours sur les concepts de C++0x.
Fais une recherche dans le forum C++ t'auras quelques éléments

[millie]

D'ailleurs j'ai une question. Est-ce que ce genre de chosess se fait en Java avec les Generics ?

Quoi précisement ?

Les classes de policies se font mais pas de la même manière.

Par contre, il n'est pas possible d'avoir un moment un code qui ressemble à :

Code :

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

1
2
UneClasse.unType truc;

Mais il y a d'autres manières de faire suivant ce que tu veux exactement faire.

[Alp]

Le fait est que pas mal des techniques avancées d'utilisation des templates permettent d'avoir un semblant de réflexivité. Enfin, on peut décrire une classe à la compilation, en tout cas.
Et il me semble bien qu'en Java tout est déjà pré-maché

Après, pour les policies, l'application la plus connue est celle issue du bouquin d'Alexandrescu : La bibliothèque Loki.

[davcha]

Java et C# ont choisi d'imposer le modèle objet. Je trouve ça dommage d'imposer ce paradigme [...]

En quoi est-ce dommage, exactement ?

Je veux dire, Hashkell impose un paradigme spécifique aussi, tout comme C/C++, ainsi que tous les autres langages.
Alors pourquoi est-ce dommage que Java/C# imposent le modèle objet ?...

Au final, plutôt que d'être imposé par un langage le choix du paradigme ne reste-t-il pas un choix de l'équipe de développement, du client et/ou du chef de projet... ?
Je veux dire, si ton client, chef de projet, ton équipe et/ou toi-même ne souhaitent pas développer en objet, rien ne vous impose d'utiliser un langage objet.

Je vois un cas où ça peut être dommage : le cas où tu as envie d'utiliser une technologie qui n'est disponible que dans un langage spécifique, mais que tu souhaites utiliser un autre langage ou paradigme que celui imposé par le langage en question (par exemple wpf supportant mal c++/cli).

Oui, les templates sont bien plus puissants que les generics.

A noter que les templates en tant que meta-programmation n'ont pas forcément un intérêt phénoménal en java ou en c#, puisque ces langages permettent de générer du code, typé, lors de l'exécution.

[LLB]

En quoi est-ce dommage, exactement ?

En fonction du problème, certaines approches sont beaucoup plus efficaces que d'autres. Je préfère quand je peux choisir la vision des choses à adopter, sans avoir à changer de langage (ce qui est rarement pratique).

A noter que les templates en tant que meta-programmation n'ont pas forcément un intérêt phénoménal en java ou en c#, puisque ces langages permettent de générer du code, typé, lors de l'exécution.

Le système de templates est turing-complet et reste plus puissant que l'approche des generics. Il permet aussi plus de généricité et n'est pas restreint par les interfaces. Il a aussi ses inconvénients, mais j'imagine que tout cela a été détaillé au cours des 70 pages de discussion.

[davcha]

En fonction du problème, certaines approches sont beaucoup plus efficaces que d'autres. Je préfère quand je peux choisir la vision des choses à adopter, sans avoir à changer de langage (ce qui est rarement pratique).

D'accord, cite-moi un exemple de solution plus efficace en C++ qui ne soit pas réalisable ou pas aussi efficace en Java/C# à cause du paradigme de ces langages, alors.

Le système de templates est turing-complet et reste plus puissant que l'approche des generics. Il permet aussi plus de généricité et n'est pas restreint par les interfaces. Il a aussi ses inconvénients, mais j'imagine que tout cela a été détaillé au cours des 70 pages de discussion.

Je ne parlais pas des generics, ici.
Je pensais plus à l'AOP et, en ce qui concerne C# en tout cas (je ne sais pas si Java a un équivalent, mais ça m'étonnerait pas) de la possibilité de générer du code MSIL au runtime.

[LLB]

D'accord, cite-moi un exemple de solution plus efficace en C++ qui ne soit pas réalisable ou pas aussi efficace en Java/C# à cause du paradigme de ces langages, alors.

Mon propos était assez général. Dans certains problèmes, on peut par exemple préférer un paradigme fonctionnel, logique ou autre. Ce n'est pas une question de faisabilité (!), ni de performances à l'exécution : c'est une question de conception et d'approche du problème. Je suis également un peu déçu par C++ sur ce point, aussi vaut-il mieux ne pas s'y attarder dans ce thread.

Dans certains cas, on peut ne pas vouloir de classe, or Java nous l'impose. Je trouve ça juste "dommage", mais ce n'est pas vraiment un problème, en soi.

Mais si tu veux quelque chose qui n'est pas faisable en Java, regarde du côté des templates, de la généricité et de la méta-programmation. Comme je l'ai dit, je suis convaincu que tout a déjà été abordé et je n'ai pas envie de m'étendre.

[Alp]

A ce sujet, lire "Modern C++ Design" et "C++ Template Metaprogramming" (2 oeuvres qui couvrent assez bien la programmation générique et la conception générique).

[davcha]

Mais si tu veux quelque chose qui n'est pas faisable en Java, regarde du côté des templates, de la généricité et de la méta-programmation. Comme je l'ai dit, je suis convaincu que tout a déjà été abordé et je n'ai pas envie de m'étendre.

Vous avez parlé de l'AOP (AspectJ, Postsharp...) et des possibilités offertes par MSIL (dynamicmethod, tout ça...) ?

Pour ce qui est du paradigme fonctionnel, logique ou autre préférable dans certains cas, je suis tout à fait d'accord. J'ai juste du mal à voir exactement où se situe cette question quand on compare c/c++ et java/c#

[Luc Hermitte]

Dans une moindre mesure le C++ les supporte.

[Alp]

Comme pour pas mal de choses, la souplesse du C++ permet de "simuler" ou encore "approcher" des techniques/paradigmes de programmation qui ne sont à l'origine pas fait pour le C++.

[Tommy31]

Je pensais plus à l'AOP et, en ce qui concerne C# en tout cas (je ne sais pas si Java a un équivalent, mais ça m'étonnerait pas) de la possibilité de générer du code MSIL au runtime.

En java, l'application des aspects peuvent se faire dynamiquement, avec donc génération du bytecode au runtime.

[Mat.M]

Donc pour conclure

Java=C++ avec Garbage Collector + Bibliothèques de code et fonctions

[Alp]

Qu'est-ce qu'il ne faut pas lire ...

[davcha]

Donc.... le C++, c'est de l'assembleur qui s'exécute dans une machine virtuelle ?...