[Débat] C++ vs Java

Citation:

---

Envoyé par Ubiquité

Ce qui force un programme Lisp à intégrer un interpréteur ou un compilateur est une propriété que n'a pas Java.

---

parce que Java est compilé vers une VM pour sa version desktop... (JavaCard est par exemple bien plus limité dans ses features -- pas de GC par exemple)

mais quand on voit que .Net a été obligé d'introduire le DLR dans son runtime pour gérer les langages dynamiques, on voit bien que cette contrainte de Common Lisp est dupliquée de manière pragmatique (faire du neuf avec du vieux :aie:)

Citation:

---

Envoyé par Nemek

Il y a une grosse différence entre l'héritage d'une classe et l'implémentation d'une interface : le code à exécuter est forcément dans la hiérarchie d'héritage.

---

En Java oui.

Mais justement ma réponse à la question "comment ça se passe dans d'autres langages ayant fait le même choix que Java (i.e. pas d'héritage multiple mais implémentation de multiples interface)" était qu'au moins un langage, le D, permet d'avoir du code à exécuter dans l'interface à condition que la méthode en question soit finale. Ça me semble une bonne idée.

Citation:

---

Envoyé par Nemek

Je parlais surtout des pointeurs dont il faut faire particulièrement attention. Alors peut-être qu'avec le temps ca devient ultra intuitif en ayant des patterns simples et efficaces ; en attendant on doit focaliser une part d'attention à ça, ce qui nous prive de nous focaliser sur autre chose. C'est bien ça qu'offre des plateformes comme Java et .Net

---

Oui et non. C'est vrai qu'en C++ le développeur se doit de réfléchir à la durée de vie de ses objets (même si les smarts pointeurs permettent de se simplifier la vie, il reste néanmoins à les utiliser correctement). Après ce n'est pas parce que je dois penser à cela que je ne pense pas au reste. Mais c'est vrai que c'est une charge supplémentaire.

Citation:

---

Et quand je vois le nombre d'applications qui se terminent en Core Dump, je me dis que tout le monde ne les manipules pas si bien que ça.
Cependant il n'est pas rare des applications Java qui ont de graves fuites mémoires (surtout en environnement modulaire).

---

Ce qui montre que l'on doit quand même y réfléchir un minimum même en java (et contrairement à ce que l'on pourrait croire de prime abord).
Tiens à ce sujet, un petite question :
Existe-t-il en java un equivalent au destructeur en c++? Parce qu'en ce qui concerne la gestion des ressources (pas seulement de la mémoire mais aussi tout ce qui est accès à un fichier, connexion réseau, thread, ...) je trouve que c'est quelque chose de quasi indispensable.

Citation:

---

La permissivité (ou le laisser-aller/faire) ne sont pas, par expérience, didactique. Au contraire, plus tu laisses de liberté aux gens et plus ils en prennent plus que d'être ultra-rigoureux.

---

Et plus on leur tapes dessus ensuite parce qu'ils ont fait n'importe quoi :aie:

Citation:

---

Non ca me choque pas car

1. ce n'est pas à nous de déterminer si une infinité d'objet dans une infinité de contexte ont un lien ou pas.
2. si je veux les mettre dans un même panier c'est que je considère qu'il existe un lien
3. dans le cas de Java et des collections, ca rend le code générique, compatible avec toutes les classes et légèrement optimisé

---

Sauf que dans le contexte d'un programme donné, 2 objets peuvent avoir un lien ou ne pas en avoir. Si l'on reprend l'exemple des voitures, on peut très bien concevoir avoir une voiture, un camion ou un vélo dans une même liste. Par contre, je peux très bien considérer qu'un feux de signalisation n'a rien à y faire. Aussi je préfère que ce soit mon compilo qui m'envoie balader parce que je me suis trompé à un moment dans mon code plutot que de devoir tester mon appli puis chercher pendant des heures pour me rendre compte de mon erreur.
Après, je me trompe peut-être mais les generics en java doivent permettre d'arriver au même résultat non? (j'entends par là une erreur à la compilation). Dans ce contexte, j'aurai même tendance à dire que le fait que tout object hérite de la classe object etait surtout une nécéssité à une époque ou les générics n'existaient pas encore.
Quoi qu'il en soit, je considère perso que toute map, liste ou autre conteneur se doit d'être typés un maximum (via les générics en java et les templates en C++) et que les conteneurs contenant des objects sont à proscrire.
Enfin, je dirai qu'il ne faut pas forcément que tout soit objet pour pouvoir avoir un code générique. Après tous, les conteneurs de la STL y arrivent très bien.

Citation:

---

J'admet volontiers qu'il n'y a pas de nécessité d'avoir une base unique. Je dis en revanche que cela a ses avantages. Cela sert la cause de Java et non le contraire. Quiconque manipule un peu l'API se rend compte qu'Object n'est pas dénué de sens et de fonctionnalité contrairement à void.
N'oublie pas non plus que Object possède une méthode getClass() (qui remettra sûrement cause beaucoup de piliers de OO) qui permet d'en savoir beaucoup sur une instance donnée.

---

Pour ce qui est de void* (et non void ;)), son utilisation est à proscrire autant que possible.
Pour la méthode getClass, le C++ utilise un opérateur pour obtenir le type d'une variable donnée. Après, il est clair que les possibilités en la matière en c++ sont très limitée. Mais bon. Je ne suis pas un fan de la reflection de toute façon.

Citation:

---

Je suis peut-être un peu bisounours aussi dans l'âme mais je pense que quelqu'un de son "niveau" doit être apte à comprendre OO, d'autant plus s'il se permet d'y porter un jugement de valeur. Bon après je connais pas du tout le type ; je veux pas dire personnellement mais dans l'ensemble (l'image qu'il dégage, etc). C'est peut-être un petit con : tu me confirmeras ou pas !

---

Bof, perso quand je vois ce qu'il a écrit, j'ai quand même quelques doutes. En fait, j'ai un peu l'impression qu'il jette le bébé avec l'eau du bain. Tout n'est pas parfait en C++, mais quand on le compare avec le C, le C++ apporte quand même beaucoup de facilités je trouve. (le problème étant qu'il n'est pas toujours facile de toutes les maitriser).

Citation:

---

Bah dans une "Reference Map", je vois aucune obligation d'avoir des clés homogènes

---

Ben désolé mais moi j'en vois une!
Si je veux par exemple utiliser un id (donc un int) afin de stocker différents éléments dans ma map, j'apprécie que mon compilo vérifie ce fait et me prévienne si jamais à un moment donné j'essaie d'y mettre autre chose qu'un entier.
Après, il est possible que l'on veuille pouvoir utiliser n'importe quoi comme clé dans un cas précis, mais si je sais à l'avance que je n'y pettrai que des entiers, je préfère que mon compilo le vérifie.

Citation:

---

Pour information (et désolé du sacrilège de la syntaxe) mais est-ce que le code suivant compile ?

Code:

---

1 2 3 4 5

Foo* foo = ...; Bar* bar = ...; if (foo == bar) { ... }

---

---

Je viens de tester avec le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10

int main() { int *a; double *b; if(a == b) return 0; else return 1; }

---

J'obtient ceci:
test.cpp: In function ‘int main()’:
test.cpp:5:10: error: comparison between distinct pointer types ‘int*’ and ‘double*’ lacks a cast [-fpermissive]
donc non cela ne compile pas (ce qui est à mon sens une bonne chose).
Par contre, le code suivant compile :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int main() { int x = 3; double y = 5; void *a = &x; void *b = &y; if(a == b) return 0; else return 1; }

---

Citation:

---

Les templates, pwaaa. Et toutes façons ils vont supposer (comme les langages dynamiques) que les membres utilisés existent. Si je prends le cas des HashMap, ton code va supposer que les types qui vont "instancier le template" (?) dispose bien des méthodes de calculs du hash et de comparaison sans qu'ils aient de point commun. Tu ne fais que déclarer des interfaces implicites.

---

Tout à fait, et si un membre n'existe pas, on a une erreur à la compilation. C'est par ailleurs tout le sujet des concepts. (car actuellement, quand un membre n'existe pas l'erreur générée par le compilo est difficelent lisible, surtout pour un néophyte).

Citation:

---

Concernant le paradigme générique (s'il s'agit bien de la même chose qu'en Java), il faut bien un point commun. D'ailleurs c'est la raison de la présence de Boost::Any non ?

---

Je ne sais pas si c'est le même qu'en java. Mais s'il doit y avoir un point commun, je dirai qu c'est le fait qu'un type donné respecte ou pas tel ou tel concept (lesquels peuvent être vu comme tu l'a fort justement dit comme des interfaces implicites). Cependant les concepts ne font pas (encore) parti du langage.

Citation:

---

Que tu colles ta fonction/procédure dans un namespace Foo::Bar ou une méthode dans une classe foo.Bar, je vois pas la différence :x

---

Si ce n'est que comme dit plus haut les namespaces sont extensibles. Mais c'est vrai qu'au final cela ne change pas grand chose. (Par ailleurs, il m'arrive parfois de préférer avoir des méthodes statiques contenues dans une classe plutot que de les avoir au niveau du namespace.)

En espérant avoir contribué à faire avancer la discussion :D

Citation:

---

Envoyé par gl

En Java oui.

Mais justement ma réponse à la question "comment ça se passe dans d'autres langages ayant fait le même choix que Java (i.e. pas d'héritage multiple mais implémentation de multiples interface)" était qu'au moins un langage, le D, permet d'avoir du code à exécuter dans l'interface à condition que la méthode en question soit finale. Ça me semble une bonne idée.

---

Je reconnais aussi qu'il s'agit là d'un bon compromis. (même si perso je préfère disposer de l'héritage multiple, et ce malgré le fait qu'en pratique son utilisation reste marginale).

Citation:

---

Envoyé par bountykiler

Existe-t-il en java un equivalent au destructeur en c++? Parce qu'en ce qui concerne la gestion des ressources (pas seulement de la mémoire mais aussi tout ce qui est accès à un fichier, connexion réseau, thread, ...) je trouve que c'est quelque chose de quasi indispensable.

---

Il y a un mécanisme proche du destructeur : la finalisation.
Mais elle ne doit pas être utilisé pour cela (ou alors en garde fou), car on ne maitrise pas le moment précis où la finalisation aura lieu (puisque cela dépend du GarbageCollector).

A la place il faut utiliser la syntaxe try/finally afin de libérer explicitement la ressource :

Code:

---

1 2 3 4 5 6

InputStream input = new FileInputStream("file") try { // lecture du fichier } finally { input.close(); }

---

A noter que Java 7 a introduit une nouvelle syntaxe pour automatiser cela : le "try-with-ressource" :

Code:

---

1 2 3

try (InputStream input = new FileInputStream("file")) { // lecture du fichier }

---

Citation:

---

Envoyé par bountykiler

Après, je me trompe peut-être mais les generics en java doivent permettre d'arriver au même résultat non? (j'entends par là une erreur à la compilation).

---

Oui : les Generics génèrent pas mal d'erreurs et/ou warning...

Citation:

---

Envoyé par bountykiler

Dans ce contexte, j'aurai même tendance à dire que le fait que tout object hérite de la classe object etait surtout une nécéssité à une époque ou les générics n'existaient pas encore.

---

Cela a quand même d'autres avantages que pour les collections (je pense à la reflection par exemple)

Citation:

---

Envoyé par bountykiler

Quoi qu'il en soit, je considère perso que toute map, liste ou autre conteneur se doit d'être typés un maximum (via les générics en java et les templates en C++) et que les conteneurs contenant des objects sont à proscrire.

---

Oui en effet.

Citation:

---

Envoyé par bountykiler

Je viens de tester avec le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10

int main() { int *a; double *b; if(a == b) return 0; else return 1; }

---

---

Il s'agit de vérification basique du compilateur. Heureusement que tu as la même chose en Java (erreur : incomparable types).

Citation:

---

Envoyé par gl

Mais justement ma réponse à la question "comment ça se passe dans d'autres langages ayant fait le même choix que Java (i.e. pas d'héritage multiple mais implémentation de multiples interface)" était qu'au moins un langage, le D, permet d'avoir du code à exécuter dans l'interface à condition que la méthode en question soit finale. Ça me semble une bonne idée.

---

D'après ce que je lit sur wikipedia, ces méthodes final sont non-virtuelle. Donc cela ne pose aucun problème même avec l'héritage multiple.


Car plus que l'héritage multiple, c'est sur la notion de virtualité des méthodes que Java diffère du C++.

En C++ toute les méthodes sont non-virtuelle par défaut, et il faut explicitement les marquer comme tel pour qu'elle le deviennent. Cela limite bien les problèmes de l'héritage multiple, car si la méthode parente n'est pas virtuelle on peut utiliser le même nom de méthode sans que cela ne pose de conflit.

En Java, mis à part les méthodes private, toutes les méthodes d'instances sont virtuelles. En Java le mot clef final sert juste à interdire la redéfinition de la méthode (qui reste quand même virtuelle).
Donc en cas d'héritage multiple le risque de conflit est très élevé !




A noter que Java 8 apportera un nouveau concept qui permettra de simuler l'héritage multiple (même si ce n'est pas son objectif initial), via les "Default Methods".

Le premier objectifs des "Default Methods" est de permettre l'évolution des interfaces existantes en y ajoutant des méthodes avec un code par défaut qui sera utilisé uniquement dans le cas où la classe n'implémente pas la méthode.

Bref : on pourrait mettre du code dans une interface.

Code:

---

1 2 3 4 5 6 7 8

public interface Iterable<T> { public Iterator<T> iterator(); public boolean isEmpty() default { return !iterator().hasNext(); } }

---

Au niveau de la résolution c'est beaucoup plus simple car la moindre implémentation dans une classe de la hiérarchie prendra obligatoirement le pas sur la méthode par défaut de l'interface.

Le seul problème qui pourrait survenir serait celui de deux interfaces distinctes avec la même méthode disposant d'un code par défaut différent...



a++

Citation:

---

Envoyé par adiGuba

A noter que Java 8 apportera un nouveau concept [...] les "Default Methods" [...]

Le premier objectifs des "Default Methods" est de permettre l'évolution des interfaces existantes en y ajoutant des méthodes avec un code par défaut qui sera utilisé uniquement dans le cas où la classe n'implémente pas la méthode.

Bref : on pourrait mettre du code dans une interface.

Code:

---

1 2 3 4 5 6 7 8

public interface Iterable<T> { public Iterator<T> iterator(); public boolean isEmpty() default { return !iterator().hasNext(); } }

---

[...]

Le seul problème qui pourrait survenir serait celui de deux interfaces distinctes avec la même méthode disposant d'un code par défaut différent...

---

ou alors ils vont obliger à spécifier de quelle interface on hérite par défaut (un peu sur le modèle de C# qui peut spécifier à quelle interface est rattachée une méthode)

Citation:

---

Envoyé par koala01

Il faut avouer que ce n'est, effectivement pas du "compile once, run everywhere" mais il est tout à fait possible d'arriver à une compatibilité parfaite en s'astreignant à des règles de codage simplement "correctes".
Il ne faut pas oublier que tu n'arriveras de toutes manières pas non plus à faire tourner la version "windows" de la JVM dans un environnement *nux !!

---

Je voulais juste signaler qu'il n'est pas nécessaire de recompiler pour chaque système et que le principe de VM n'est pas si mauvais si au final vous avez des .so pour les différents *nux et des .dll pour les différents Windows. Car au final c'est bien cela qu'apporte la VM : du code binaire pour chaque plateforme cible.

Citation:

---

Envoyé par koala01

Je peux t'assurer que l'on compte les endroits où l'on a recours à la compilation conditionnelle (par exemple pour déterminer le système sur lequel on travaille) sur les doigts d'une main, et que cela n'a rien à voir avec l'utilisation de bibliothèque, mais plutot avec l'impossibilité de trouver une application particulière ( excel pour ne pas la citer) sur des machines *nux ;)

---

Je te fais largement confiance et je vais même tenter de te croire. Cependant pour que le source soit compatible, t'as bien du code binaire propre à chaque plateforme cible.

Citation:

---

Envoyé par koala01

j'ai presque envie de dire "mais pourquoi faire le travail à moitié :question:"

---

Ou à moitié ne pas le faire :aie:

Citation:

---

Envoyé par koala01

En C++ aussi on est adepte des bibliothèques (hé oui, la traduction de library, c'est... bibliothèque :D ) tierces ;)

---

Bien vu ;) En Java on en utilise à outrance (minimum une vingtaine pour un projet tout juste correct). C'est pareil en C++ ?

Citation:

---

Envoyé par koala01

Et ce n'est pas cela que l'on recompile à chaque fois ;)

---

Mea Culpa. Je pensais que le format de distribution standard c'était le source et non les .so/.dll. Histoire de ne pas proposer 5 000 format de distribution différent.

Citation:

---

Envoyé par koala01

Le fait est que, bien souvent, "l'héritage mal conçu" (comprend: ne respectant pas LSP ;) ) seraitdevrait être souvent bien avantageusement remplacé par une composition :aie:

---

:aie:

Citation:

---

Envoyé par koala01

Mais l'énorme avantage du NVI est qu'il permet de fournir des "points de variation" de manière particulièrement fine...

Cela permet de respecter d'avantage encore un conseil issu de l'XP: DRY (Don't repeat Yourself ;)) en évitant, justement, d'obliger la personne qui veut dériver une de nos classes à devoir... reprendre le code de la classe parente pour les parties de variant pas ;)

---

On est entièrement d'accord :)

Citation:

---

Envoyé par koala01

Si tu le reconnais toi même...

---

Cependant je peux tout de même le faire ;)

Citation:

---

Envoyé par koala01

Mais j'irais même plus loin: ca rend, pour moi, l'utilisation d'un bazooka obligatoire pour chasser une mouche :aie: Pas vrai :question:

---

Il faut avouer que c'est pas brillant ; mais ... autant que celui d'avoir une interface par comportement et de tout wrapper/bridger/adapter. On critique beaucoup Java pour cela mais finalement ce n'est pas spécifique à celui-ci.
Et il faut noter que cela fait partie du langage sous la forme de "Byte Code Engineering" ("retravaillé" le Byte Code quoi).

Le problème en fait des NVI, est-ce vraiment de l'héritage ou bien de la méta-programmation ?
J'aimerai bien savoir comment la méta-programmation est intégré dans les autres langages (y compris C++) !

(Soit dit en passant, la programmation par aspect n'a rien d'un bazooka et est en fait assez trivial).

Citation:

---

Envoyé par koala01

Pourquoi l'aurait il évoqué dans un cours de java, alors que tout dans java tend à minimiser l'importance de ce principe, alors que c'est (en réalité) le premier de tous :question:

---

J'ai eu tout de même des cours de COO, ca utilisait la syntaxe UML/Smalltalk/Eiffel pour la partie application ...

Citation:

---

Envoyé par koala01

Ou du moins que la marge de manoeuvre des sous-types concernant le contrat est fortement limitée:

1. Les préconditions ne peuvent pas être renforcées dans le sous type
2. Les postconditions ne peuvent pas être allégées dans le sous type
3. Les invariants du type de base doivent etre respectés dans le sous type.

Il y a des chances que ce soit à cause de cela, en effet :aie:

---

Bah autre les types de paramètres, de retour et d'exception, il n'y a pas de pré/post-conditions et invariants en Java. Il y a bien un mot clé "assert" mais c'est rattaché au corps des méthodes et non aux méthodes elles-mêmes ...
On doit donc le faire en "conception" (comprendre par organisation du code).

Citation:

---

Envoyé par koala01

Il y a des chances que ce soit à cause de cela, en effet :aie:

---

En fait, en essayant de repenser aux 10 dernières fois (environ) où j'ai dû faire ça, c'était effectivement pour corriger un bug dans une méthode :?

Citation:

---

Envoyé par koala01

Mais, à ta décharge, cela peut remonter vraiment haut, comme à l'obligation qui t'est faite d'hériter, en toutes circonstances, de la classe Object.

---

A la décharge de mes profs ... Cependant un peu de culture est un mal nécessaire. Quand je repense aux heures passées sur la "sécurité informatique" (au sens général : infrastructure, bâtiment, formation/sensibilisation du personnel, etc) et sur CMMi, dix minutes à évoquer la base ce n'est pas un grand mal.

Citation:

---

Envoyé par koala01

Pour ma part, je trouve quelque part presque dommage que la programmation par contrat ne soit pas plus mise en avant... Cela inciterait les gens à se poser les bonnes questions avant de décider qu'il est plus intéressant de recourir à l'héritage là où tout ce qui les intéresse, c'est de récupérer du code, sans être attentif à la "sémantique" de leur classe.

---

Je pense que ca enlèverai de la souplesse qui a fait que Java a été très adopté : assez simple à apprendre et utiliser.

Citation:

---

Envoyé par koala01

Est-ce une raison pour être obligé de les mettre dans une classe, quand on sait que toutes ces fonctions ont de grandes chances de devoir être statiques car pouvant potentiellement ne dépendre d'aucune instance de la classe :question (et tu sais tout le bien que je pense des fonctions statiques)

---

Disons que tout doit appartenir à un paquet (namespace, package ou autre), et qu'en Java ce sont les classes qui portent le code. Ca simplifie les choses et comme je l'ai dit, quelle différence entre Foo::Bar::faire() et foo.Bar.faire() ?

Citation:

---

Envoyé par koala01

Par contre, ce que j'ai beaucoup de mal à accepter, l'aspect systématique de la chose qui apparait en java: même si l'on se dit qu'une map va utiliser le type X comme clé et les types dérivant de Y comme valeur, on n'est jamais à l'abri de l'éventualité que quelqu'un, quelque part dans le code, n'ait pas saisi correctement l'utilisation qui est faite de la map et décide d'utiliser le type A comme clé et le type B commme valeur (A et B n'ayant définitivement rien à voir avec X et Y, tu l'auras compris ;)), surtout si "pour ne pas te casser la tête", tu as décidé (car tu as le droit de le faire :D ) d'accepter que la fonction qui s'occupera d'ajouter les élément à ta map prennent des références sur Object tant pour la clé que pour la valeur :aie:

---

La méthode d'ajout prend bien les types X et Y en paramètre ... Après si tu parles de comment sont implémentés les génériques en Java, je te renvoie à mes réponses précédentes.

Citation:

---

Envoyé par koala01

Tu peux te mettre à l'abri de ce genre d'erreur par programmation, de préférence en choisissant le type correct pour les arguments, au pire, en vérifiant le type réel des arguments que tu obtiens dans la fonction d'insertion, mais il est "dommage, dirons nous" qu'un langage qui se prétend facile et sécurisant permette qu'un mauvais choix d'un coté et une mauvaise compréhension de l'autre permette à des catastrophes de survenir :aie:

---

Il existe des collections qui font ça mais Java a fait (depuis un petit moment déjà) le choix de limiter les contrôles et de faire confiance aux développeurs d'utiliser/appliquer ou non les contrôles en fonction du degré de confiance qu'ils ont en leur propre code et de comment les données qu'ils transmettent vont être utilisés.

Citation:

---

Envoyé par koala01

Tu as, effectivement, du code binaire qui est généré pour chaque type spécialisant un template...
Mais c'est normal ;)
Après tout, quand on écrit en C++ une classe proche de

Code:

---

1 2 3 4 5

template <typename Type> c lass MaClass { };

---

et qu'on l'utilise avec les types A, B, et C (tous les trois étant différent ;)) c'est, au niveau du binaire généré comme si on avait écrit les trois classes (la répétition de code en moins)

Code:

---

1 2 3 4 5 6 7 8 9

class MaClassA // cas particulier utilisant le type A { }; class MaClassB // cas particulier utilisant le type B { }; class MaClasseC // cas particulier utilisant le type C { };

---

---

Disons que c'est bizarre de recompiler la classe "List" à chaque fois que tu en as besoin ... Et cela signifie qu'il te faut le code source ?
Par ailleurs si tu veux faire du code "générique" sur les listes (ex : un visiteur d'une liste), il te faut faire un template et créé autant de type.

Citation:

---

Envoyé par koala01

std::list <int> est substituable à std::list<int> ;)

---

Pour raviver ma mémoire, il faut bien faire des "typedef" ?

Citation:

---

Envoyé par koala01

Si le type d'entier (int Vs unsigned int, short Vs unsigned short), oui, bien sur :D

---

ok

Citation:

---

Envoyé par koala01

Non... C'est pour cela que les collections de la stl n'ont pas vocation à être dérivées ;)

---

On ne parle pas d'héritage mais de covariance/contravariance ...

Citation:

---

Envoyé par koala01

Par contre, tu peux effectivement créer une liste de pointeurs sur Base et insérer un pointeur sur Derivee si Derivee hérite effectivement de Base ;)

Mais attention, nous sommes là dans un paradigme qui n'a rien à voir avec le paradigme OO, nous abordons le troisième paradigme utilisé par C++ qui est le paradigme générique (celui ou l'on ne sait pas encore le type de valeurs que l'on va utiliser, mais ou l'on sait par contre comment on va comment on va les utiliser ;) )

---

Pour information, ca donne quoi en utilisant les génériques plutôt que les templates ?

Citation:

---

Envoyé par koala01

Justement pas!!!

Bien au contraire :D

Chaque fois que tu vas instancier une classe template avec un type particulier, le binaire correspondant va être généré (en fait, le code de ta classe va être compilé en considérant que l'on utilise le type envisagé).

Si tu instancie ta classe template avec dix types différent, les vérifications effectuées à la compilation seront effectuées... dix fois (une fois pour chaque type avec lequel ta classe template est instanciée) :aie:

---

Je signalais seulement, pour être générique, qu'en choississant un point commun dans la hierachie de classe (Object ou pas), tu te retrouves nécessairement avec des instances de type différent (ex: une collection) et que la vérification verifiera seulement si les types sont compatibles en terme de hierarchie. Rien de différent de Java.

Citation:

---

Envoyé par koala01

L'idée de concept est en fait différente (et a été écartée afin de permettre une sortie "relativement rapide" de la dernière norme en date, pour tout dire ;))
L'idée est de se dire "voilà, j'ai besoin d'un concept X" (mettons : le concept de "sérialisabilité" ;))

et de continuer "Pour qu'un classe respecte ce concept, il faut qu'elle expose certaines fonctions dont le nom et la signature sont clairement identifiés" ( les fonctions write et read, par exemple, pour le concept de sérialisabilité ;))

Pour terminer par "je vais donc vérifier (à la compilation :D) que tout objet qui me sera transmis ici dispose bel et bien des fonctions ad-hoc"

La notion de concept permet donc une vérification "orthogonale" de ton projet car il n'est pas du tout impossible que tu aies une classe SerializableX qui hérite de X ainsi qu'un autre SerializableY qui hérite de Y (mais sans qu'il n'y ait le moindre lien entre la classe X et la classe Y ;) :D ) dont le seul point commun est d'exposer un certain nombre de fonctions portant le même nom et acceptant un nombre de paramètres identique

---

Ok, donc c'est bien de la méta-programmation ... Finalement ca aurait dû prendre quelle forme ?

Citation:

---

Envoyé par koala01

Ben non, pourquoi :question:
Les DP bridge, Facade et consors, cela ne te dit rien :question:

---

Si bien sûr, d'ailleurs en Java on ne connaît que ça -_-' Cependant on critique justement souvent Java pour ça.

Citation:

---

Envoyé par koala01

Ce qu'il faut comprendre, c'est qu'aucun langage n'est foncièrement mauvais ni foncièrement bon!!!

---

D'un point de vue pure concept/syntaxe/idéologie, je préfère Ruby,C++,C# à Java (uniquement pour ceux que j'ai déjà taté). Cependant notre travail est surtout conditionné par le marché et nos expériences accumulées.
(Si quelqu'un veut me prendre à l'essai sur l'un des ces trois langages, n'hésitez pas :p).

Citation:

---

Envoyé par koala01

On peut éventuellement dire qu'un langage sera plus adapté à un secteur qu'à un autre, mais il faut vraiment voir les besoins pour parler de la sorte ;)

---

Le plus gros besoin en règle générale c'est la main d'oeuvre et le prix ...

Citation:

---

Envoyé par koala01

Et malgré tout le mal que j'ai pu dire de java sur mes dernières interventions, je peux te rassurer : je ne le trouve pas forcément pire qu'un autre (ni forcément meilleur d'ailleurs :D)

---

Tout pareil seulement tu critiquais les choix des concepteurs du langage et que tu ne semblais pas comprendre les raisons de ces choix :)

Citation:

---

Envoyé par koala01

Cependant, je me demande quelle est la proportion de projets (quel que soit le langage envisagé ;) ) pour lesquels le choix du langage est basé uniquement sur "ce que connait l'initiateur du projet", sur "l'effet de mode" ou sur le fait que c'est, définitivement, le langage le plus adapté aux besoins que l'on doit rencontrer (ou peut etre sur "la tchatche du commercial qui vend le projet :D) ...

---

5% peut-être.
Quoiqu'il arrive ~90% doivent être basé uniquement sur l'environnement existant (que ce soit le langage ou pas). Si j'ai déjà des serveurs Oracle, je continuerai à fonctionner sous Oracle. Idem pour l'OS et les logiciels.
Mon tout premier projet en entreprise (stage + CDD) consistait à migrer une application Cobol sous Windows d'une interface Console à une interface graphique fenêtrée. On a gardé Cobol et les fichiers séquentiels indexées. Alors le commercial/CP militait auprès du client pour remplacer les fichiers séquentiels indexés par une base de données (plus rapide, plus robuste, plus fiable, plus facile à manipuler pour les opérations de maintenance comme le backup, la restauration, la transformation, etc.). Cependant le client a toujours refusé.

Citation:

---

Envoyé par koala01

Je reste cependant convaincu que le choix d'un langage "de prédilection" reste une affaire de gout et de philosophie personnelle, mais qu'il est malgré tout quasiment indispensable de s'intéresser au moins un tout petit peu aux langages que l'on "apprécie moins", ne serait-ce que pour pouvoir se "dépatouiller avec" en cas de besoin ;)

---

Sans forcément regarder les langages ce sont plutôt les paradigmes. Car tant que tu restes dans l'objet/impératif t'arriveras à te dépatouiller en voyant ce qui existe, Internet et les autres membres de l'équipe. Bon sauf si tu dois lancer un nouveau projet mais dans ce cas c'est du suicide :aie:

Citation:

---

Envoyé par bountykiler

Oui et non. C'est vrai qu'en C++ le développeur se doit de réfléchir à la durée de vie de ses objets (même si les smarts pointeurs permettent de se simplifier la vie, il reste néanmoins à les utiliser correctement). Après ce n'est pas parce que je dois penser à cela que je ne pense pas au reste. Mais c'est vrai que c'est une charge supplémentaire.

---

Tout temps passé à faire une chose est un temps qui n'est pas passé à faire autre chose (sauf pour les femmes ^_-).

Citation:

---

Envoyé par bountykiler

Ce qui montre que l'on doit quand même y réfléchir un minimum même en java (et contrairement à ce que l'on pourrait croire de prime abord).

---

Sauf qu'en Java ca continue de fonctionner et tant que tu n'as pas atteint les limites de la machine (ou celles de la JVM), tu ressens aucune gêne.

Citation:

---

Envoyé par bountykiler

Existe-t-il en java un equivalent au destructeur en c++? Parce qu'en ce qui concerne la gestion des ressources (pas seulement de la mémoire mais aussi tout ce qui est accès à un fichier, connexion réseau, thread, ...) je trouve que c'est quelque chose de quasi indispensable.

---

Il n'y a pas d'instruction de destruction. Cependant on peut écrire une méthode "finalize()" qui est appelée quand le Garbage Collector est prêt à supprimer l'instance.
Comme l'a dit adiGuba, c'est surtout un garde-fou pour nettoyer les ressources que le programmeur aurait omis.

Citation:

---

Envoyé par bountykiler

Et plus on leur tapes dessus ensuite parce qu'ils ont fait n'importe quoi :aie:

---

Et parce qu'ils ont pas compris ce qu'on leur a pas expliqué :aie:

Citation:

---

Envoyé par bountykiler

Sauf que dans le contexte d'un programme donné, 2 objets peuvent avoir un lien ou ne pas en avoir.

---

C'est bien ce que je disais :koi:

Citation:

---

Envoyé par bountykiler

Si l'on reprend l'exemple des voitures, on peut très bien concevoir avoir une voiture, un camion ou un vélo dans une même liste. Par contre, je peux très bien considérer qu'un feux de signalisation n'a rien à y faire. Aussi je préfère que ce soit mon compilo qui m'envoie balader parce que je me suis trompé à un moment dans mon code plutot que de devoir tester mon appli puis chercher pendant des heures pour me rendre compte de mon erreur.
Après, je me trompe peut-être mais les generics en java doivent permettre d'arriver au même résultat non? (j'entends par là une erreur à la compilation).

---

Effectivement avec les génériques tu te feras jeter si tu veux ajouter un feu dans une liste de véhicules.

Citation:

---

Envoyé par bountykiler

Dans ce contexte, j'aurai même tendance à dire que le fait que tout object hérite de la classe object etait surtout une nécéssité à une époque ou les générics n'existaient pas encore.
Enfin, je dirai qu'il ne faut pas forcément que tout soit objet pour pouvoir avoir un code générique. Après tous, les conteneurs de la STL y arrivent très bien.

---

En Java, même avec les générics, cela reste une necessité pour avoir un code "générique". Car Java n'a pas le principe du template ou des concepts. Il faut un type pour travailler. Par exemple

• Tout conteneur Java doit pouvoir savoir si deux éléments quelsconque sont égaux (identité de valeur j'ai envie de dire).
• Toute clé d'une map par hashage (ou élément d'un set par hashage mais ca revient au même puisqu'un HashSet n'est ni plus, ni moins qu'un ensemble de clé d'une map de hashage), doit avoir une méthode de calcul de hashage (en plus de l'identité de valeur).

Uniquement pour les conteneurs. Si on parle des API de bindings (base de données, XML, interface graphique) c'est la même histoire.

Citation:

---

Envoyé par bountykiler

Quoi qu'il en soit, je considère perso que toute map, liste ou autre conteneur se doit d'être typés un maximum (via les générics en java et les templates en C++) et que les conteneurs contenant des objects sont à proscrire.

---

Outre les conteneurs, il arrive qu'un ensemble donné n'est pas forcément besoin d'un type particulier : certains caches, les bindings, etc.

Citation:

---

Envoyé par bountykiler

Pour ce qui est de void* (et non void ;)), son utilisation est à proscrire autant que possible.

---

Le type est bien void :) L'équivalent Java de void* serait plutôt Reference<Void>.

Citation:

---

Envoyé par bountykiler

Bof, perso quand je vois ce qu'il a écrit, j'ai quand même quelques doutes. En fait, j'ai un peu l'impression qu'il jette le bébé avec l'eau du bain. Tout n'est pas parfait en C++, mais quand on le compare avec le C, le C++ apporte quand même beaucoup de facilités je trouve. (le problème étant qu'il n'est pas toujours facile de toutes les maitriser).

---

Quand j'ai débuté le C++, je voyais les classes comme des struct avec des pointeurs de fonction :) Par ailleurs, il y a un article sur comment faire des classes en C en utilisant des struct et quelques bidouilles sur les pointeurs.

Citation:

---

Envoyé par bountykiler

Ben désolé mais moi j'en vois une!
Si je veux par exemple utiliser un id (donc un int) afin de stocker différents éléments dans ma map, j'apprécie que mon compilo vérifie ce fait et me prévienne si jamais à un moment donné j'essaie d'y mettre autre chose qu'un entier.
Après, il est possible que l'on veuille pouvoir utiliser n'importe quoi comme clé dans un cas précis, mais si je sais à l'avance que je n'y pettrai que des entiers, je préfère que mon compilo le vérifie.

---

Si c'est ce que tu veux, il le fera. Mais dans le même ordre d'idée, il n'ira pas vérifier que l'id existe ou à un sens ... Ou même correspond bien à l'objet auquel tu l'associes.

Citation:

---

Envoyé par adiGuba

D'après ce que je lit sur wikipedia, ces méthodes final sont non-virtuelle. Donc cela ne pose aucun problème même avec l'héritage multiple.

---

Ca ne change rien. Comment tu gères deux méthodes concrètes qui ont la même signature ?

Citation:

---

Envoyé par adiGuba

En C++ toute les méthodes sont non-virtuelle par défaut, et il faut explicitement les marquer comme tel pour qu'elle le deviennent. Cela limite bien les problèmes de l'héritage multiple, car si la méthode parente n'est pas virtuelle on peut utiliser le même nom de méthode sans que cela ne pose de conflit.

---

Dans le cadre de méthode non-virtuelle, c'est le type du pointeur qui permet de déterminer la méthode à exécuter ?

En Java, mis à part les méthodes private, toutes les méthodes d'instances sont virtuelles. En Java le mot clef final sert juste à interdire la redéfinition de la méthode (qui reste quand même virtuelle).
Donc en cas d'héritage multiple le risque de conflit est très élevé !

Citation:

---

Envoyé par adiGuba

A noter que Java 8 apportera un nouveau concept qui permettra de simuler l'héritage multiple (même si ce n'est pas son objectif initial), via les "Default Methods".

Le premier objectifs des "Default Methods" est de permettre l'évolution des interfaces existantes en y ajoutant des méthodes avec un code par défaut qui sera utilisé uniquement dans le cas où la classe n'implémente pas la méthode.

Bref : on pourrait mettre du code dans une interface.

Code:

---

1 2 3 4 5 6 7 8

public interface Iterable<T> { public Iterator<T> iterator(); public boolean isEmpty() default { return !iterator().hasNext(); } }

---

Au niveau de la résolution c'est beaucoup plus simple car la moindre implémentation dans une classe de la hiérarchie prendra obligatoirement le pas sur la méthode par défaut de l'interface.

---

Quelle différence avec l'héritage multiple ? On pourrait appeler le code par défaut si besoin ?

Citation:

---

Envoyé par Luc Hermitte

a- En interne, il y a 150 façons différentes de réaliser ces points de variations (dans le makefile (ou assimilé) au niveau du choix du .cpp compilé, par préprocesseur, ou autre, peu importe).
C'est en interne des libs tierces. Dans le code métier que nous développons nous, il n'y a rien de tout ça.
Il y a aujourd'hui extrêmement peu de raisons pour tester la plateforme dans les codes que l'on tape quotidiennement.

---

Comme je l'ai répondu, c'est surtout pour revenir sur la critique de Java a besoin d'une VM ... Comme tout le monde, il faut bien abstraire le plateforme.

Citation:

---

Envoyé par Luc Hermitte

b- les libs tierces on ne les compile qu'une (série de) fois par plateforme ... quand elles ne viennent pas déjà précompilées.
Où est le soucis ?

---

Dans le monde dans lequel je travaille, on part de ce qui est distribué. Ce qui revient à compiler assez souvent.
Ensuite je ne sais pas quelle part de bibliothèque dynamique ou statique représente les bibliothèques en C++, ou alors on peut conserver les .o ?
J'avoue que les chaînes et unité de compilation du C++ sont bien loin !

Citation:

---

Envoyé par Luc Hermitte

c- Le peu que j'ai vu de ruby, j'ai beaucoup aimé son approche quant à la séparation héritage orienté substituabilité et import de code.

Après Java supporte l'héritage multiple et virtuel (mais limité aux interfaces). D'où que n'étant pas capable d'étendre aux comportements, il ne permet pas de supporter la programmation par contrat de façon native avec des contournements façon pattern NVI. (il repose à la place sur une phase de précompilation)

---

En Java tu peux très bien remplacé les NVI par de la programmation par aspect. Ce qui est de la post-compilation. La post-compilation est bien prévue par Java mais pas nécessairement pour faire de la programmation par contrat ou NVI.

Citation:

---

Envoyé par Luc Hermitte

e- Le concept de fonction trigo ne représente rien. sin et cos ne présentent pas le grand intérêt à être interchangeables.
Pire instancier cos pour faire le calcul ? Mais voilà un bien étrange idée. Je vois bien le

Code:

---

1 2	Cos cos = new Cos(); double l = cos.compute(pi) * 42;

---

Franchement ? Non.

---

Dit comme ça oui, sauf que Cos est un singleton. Il n'en existe qu'une seule instance dans un monde donné (ou une instance d'un monde, si on émet l'hypothèse du multivers ^^).
Il est difficile de représenter les singletons sans méthode static mais cela reviendrait à créer une instance de Monde au début du programme et que Monde (ou l'une de ses propriétés) soit passé en paramètre à chaque objet construit.
Franchement, non ? :)

Citation:

---

Envoyé par Luc Hermitte

f- Dans bien des cas, cela va couter autant de binaire que si on avait fait la même chose à la main (typiquement avec chaines et vecteurs qui sont des surcouches très light au dessus des tableaux C).

---

Template ou générique, c'est codé une fois.

Citation:

---

Envoyé par Luc Hermitte

g- mais mes listes sont toujours spécifiques.
Tu ne me verras jamais avoir des listes de carottes et voitures. (même si std::list<boost::any> me le permettrait)
Et pour les légumes, j'ai des std::list<legumes*> (/boost::ptr_list<legume>/std::list<std::unique_ptr<legume>>/...).
Et si j'ai besoin de faire des recherches ben ... je n'ai aucun downcasting à réaliser depuis le type Object car le légume exposera le critère sur lequel je réalise ma recherche.
Si on oublie l'héritage du C relativement aux types primitifs et void*, le typage du C++ induit par les templates est supérieur à celui du Java (pre Generics) -- fichu C!

---

Dans ta liste de voiture, tu peux avoir des 4x4, des picks-up, des berlines, des citadines, idem pour les légumes.
Donc tu as tout de même supposé avoir un minimum. Si je suppose que mon minimum c'est Object parce que je n'ai pas de point commun en terme de relation structurelle, où est le problème ?
Si tu prends le cas, si je veux faire n'importe quoi, je peux faire n'importe quoi et il arrive n'importe quoi ; je peux pas te contredire, c'est bien vrai. Mais je pense que pourrais faire encore plus n'importe quoi en C++.

Citation:

---

Envoyé par Luc Hermitte

h- Parce que ce n'est pas trivial et qu'il y avait eu des soucis à mélanger tous les ajouts du langages concepts, lambda, etc.

---

Je parlais du void* ou superobject.

Citation:

---

Envoyé par Luc Hermitte

i- Certainement pas. Je me retrouve avec des templates et un typage très précis sans la moindre racine mémorielle commune (void*).
Regarde le C (et peut-être même java). Il n'y a pas besoin de void* pour ajouter un int à un double. Ben les templates, c'est pareil.

---

int et double ne sont pas des classes.
Et je parlais de mélanger deux objets de frameworks différents qui n'auraient pas eu l'idée d'utiliser un type commun mêmes si les signatures sont sensables.
Après comme vous l'évoquiez, on peut wrapper/adapter/bridger. Mais je me vois mal annoncer à mon client : "bon il vous en coûtera 25% de plus parce qu'on veut que conceptuellement ce soit bien fait".
Surtout qu'à l'heure d'aujourd'hui la facturation tend à être forfaitisé sur un catalogue de service.

Citation:

---

Envoyé par Nemek

Ca ne change rien. Comment tu gères deux méthodes concrètes qui ont la même signature ?

---

Si les méthodes ne sont pas virtuelles, alors il n'y a pas de redéfinition de méthode même si elles ont le même nom et la même signature. Le compilateur se contente de générer un appel de méthode "statique" selon le type déclarée de la variable à la compilation.

Citation:

---

Envoyé par Nemek

Dans le cadre de méthode non-virtuelle, c'est le type du pointeur qui permet de déterminer la méthode à exécuter ?

---

Dans tous les cas, la méthode à appeler sera déterminé à la compilation selon le type déclaré de la variable.

La différence vient ensuite selon le type de méthode :

• Pour une méthode non-virtuelle, cela génèrera un appel de méthode statique, c'est à dire que ce sera cette même méthode qui sera exécuté quel que soit le type réel de l'instance.
• Pour une méthode virtuelle, cela génèrera un appel de méthode dynamique, c'est à dire qu'on recherchera la méthode a exécuté selon le type réel de l'instance à l'exécution.

Exemple (si mon C++ n'est pas trop rouillé) :

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

class Parent { public: void method() { std::cout << "Parent::method()\n"; }   virtual void virtualMethod() { std::cout << "Parent::virtualMethod()\n"; } }     class Child : public Parent { public: void method() { std::cout << "Child::method()\n"; }   virtual void virtualMethod() { std::cout << "Child::virtualMethod()\n"; } }       Parent parent = new Parent(); parent.method(); // Parent::method() parent.virtualMethod(); // Parent::virtualMethod()   Child child = new Child(); child.method(); // Child::method() child.virtualMethod(); // Child::virtualMethod()   Parent cp = new Child(); cp.method(); // Parent::method() cp.virtualMethod(); // Child::virtualMethod()

---

Donc les méthodes non-virtuelles ne posent aucun soucis avec l'héritage multiple puisqu'elles sont vues comme des méthodes différentes même si elles ont le même nom/signature.


Comme en C++ les méthodes sont non-virtuelles par défaut cela limite la casse avec l'héritage multiple.
En Java vu que tout est virtuelle par défaut tu serait rapidement plus embêté par cela.

Citation:

---

Envoyé par Nemek

Quelle différence avec l'héritage multiple ? On pourrait appeler le code par défaut si besoin ?

---

La différence vient des règles de résolution de méthode, avec des redéfinitions de méthodes simplifiés. :arrow: Ces "Default Methods" ne peuvent pas prendre le pas sur une méthode définie dans une classe parent.

A partir du moment où il existe une vrai implémentation de la méthode (dans le code de la classe ou d'une de ses classes parentes), cette implémentation est prioritaire sur n'importe quels "default methods" de n'importe quelle interface...


En clair on ne se tourne vers les "default methods" uniquement lorsque la méthode n'est pas implémentées dans la hierarchie de la classe. En gros si la méthode n'est JAMAIS implémenté par la classe ni aucune de ses classes parentes.


Tu ne peux donc avoir un conflit QUE pour une méthode avec deux "default methods" provenant de deux interfaces distinctes que tu implémentes. Et dans ce cas là on t'oblige à implémenter la méthode définie dans l'interface (ce que tu dois obligatoirement faire actuellement).



Tu peux faire quelque chose d'assez proche de l'héritage multiple, tout en conservant une hiérarchie "propre".


a++

Citation:

---

Envoyé par Luc Hermitte

e- Le concept de fonction trigo ne représente rien. sin et cos ne présentent pas le grand intérêt à être interchangeables.
Pire instancier cos pour faire le calcul ? Mais voilà un bien étrange idée. Je vois bien le

Code:

---

1 2	Cos cos = new Cos(); double l = cos.compute(pi) * 42;

---

Franchement ? Non.

---

Plus simple:

Code:

---

1 2	double l = Cos.instance.compute(pi) * 42

---

Des fonctions dans des objets ça s'appelle des foncteurs, et ça a son utilité.

Citation:

---

Envoyé par adiGuba

...

---

Merci pour les précisions ;)
Faudrait que écrives un article sur Java7 :roll: Et éventuellement Java8, s'ils ont figé la JSR mais je crois pas ?

J'avais un peu zappé cette histoire de virtuel/non-virtuel et je voulais coller les NVI à Java :) C'est impossible même avec les default methods :/
Ce qui serait bien c'est d'avoir les deux : héritage multiple avec des méthodes uniquement final et/ou abstraites ou les default methods.

Sinon autorisé l'héritage multiple mais générer une erreur de compilation en cas de conflit, et comme pour les default methods, obliger à rédéfinir la méthode. Mais c'est ce que fait C++ :aie: (non ?)

Question purement syntaxe C++, new génère un pointeur ou une valeur ?

Citation:

---

Envoyé par Nemek

Faudrait que écrives un article sur Java7 :roll:

---

C'est en cours mais je manque de temps :(

Citation:

---

Envoyé par Nemek

Sinon autorisé l'héritage multiple mais générer une erreur de compilation en cas de conflit, et comme pour les default methods, obliger à rédéfinir la méthode. Mais c'est ce que fait C++ :aie: (non ?)

---

C'est possible mais cela pourrait engendrer beaucoup plus de cas de conflit qu'en C++ du fait que toutes les méthodes sont virtuelles. C'est ce choix du tout virtuel qui a du faire pencher la balance sur l'interdiction de l'héritage multiple.


De toute manière l'objectif des "default methods" ce n'est pas vraiment l'héritage multiple. Son objectif principal est de permettre l'évolution des interfaces en y ajoutant des méthodes sans "tout casser"...


a++

Citation:

---

Envoyé par Nemek

Question purement syntaxe C++, new génère un pointeur ou une valeur ?

---

un pointeur

Sujet :<<C++ vs Java>>

--> C/C++

le Langage C/C++ est facile a utiliser ,plus comprehensible et vraiment efficace.Il est un langage de base et de haut niveau pour les reseaux,la securite et le developpement .De plus, lorsqu'on regarde par exemple le Framework Qt x.xx x <=10 du C++, on voit les capacites du C++ encor plus clair avec l'impact dans tous les domaines satellites, mobiles, reseaux, jeux 3D,2D et Web , beaucoup d'autres choses interessantes.

--> Java (EE,FX,etc...)
Celui-ci est plus portable, evolue et efficace dans le developpement d'applications mobile, satellite, commande des voitures , serveurs ,GPS, bref logiciels de haut niveau . De plus , tres bon dans la programmation reseau et Web.
Bref le Java reste toujours le plus utilise pour des projets de haut niveau , Hi-TECH

Excusez moi pour la redaction orthographique mal faite (pb de mon ordinateur)

Merci :ccool:

EtherOS, personnellement, je ne suis pas d'accord, je trouve que le langage C++ est vraiment un langage drastiquement complexe à apprendre notamment à toutes les possibilités qu'on lui à découvert en détournant d'autres de ces possibilités. Ceci dit, je ne critique pas ce qu'il est possible de faire avec C++.

-1 pour "C/C++".
Le C++ est déjà assez compliqué à lui tout seul, quand on l'utilise en mode "C with classes", c'est une catastrophe à maintenir. C et C++ sont deux langages à part entière, chacun avec ses bonnes pratiques (la faute aux exceptions). Et ça, c'est le sujet d'un autre troll planqué dans le forum C ou celui C++, je ne sais plus.

Citation:

---

Envoyé par EtherOS

Sujet :<<C++ vs Java>>

--> Java (EE,FX,etc...)
Celui-ci est plus portable

Merci :ccool:

---

Dans la limite ou un jvm existe sur la plateforme pour laquelle tu souhaite faire ton soft....
Ce qui nécessite souvent un compilateur C pour que la jvm puissent déjà y etre portée elle même.

J'avoue méconnaitre le C++, a peu près 10 ans de C et 10 ans de Java, je n'ai jamais réussi a me faire au C++, déjà dès son arrivée et encore moins après m'être essayé a Java, Python ... Je trouve que le C++ est le pire langage que l'on puisse imaginer pour faire comprendre l'objet car il ne va pas "a l'essentiel".

Maintenant, selon le domaine d'application, on a guère le choix on prendra ou le C++, ou Java (ou un autre langage encore ...), faire du "système" en Java serait une hérésie comme faire du web en C++ du temps perdu, par contre la question peut se poser entre les deux où ils pourraient être "en compétition".

Toutefois, même si la technologie ne vaut que parce que l'on en fait, il est une sorte de "philosophie" d'un langage qui va influer sur les habitudes que l'on prend en l'utilisant. De son origine, destiné a permettre le contrôle d'une multitude d'équipements, la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre. Dans une relation client/fournisseur entre deux modules de code, Java pousse a s'intéresser a ce dont le client a besoin, pas tout ce que le fournisseur peut fournir.

On parle de portabilité et non plus de compatibilité (s'amuser a comparer l'approche de Sun de l'époque avec celle de Microsoft :-)) Je n'ai pas a "porter" un programme Java puisqu'il est conçu d'origine pour l'être et invite le développeur a le généraliser dans son architecture.

Citation:

---

Envoyé par rimram31

la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre. Dans une relation client/fournisseur entre deux modules de code, Java pousse a s'intéresser a ce dont le client a besoin, pas tout ce que le fournisseur peut fournir.

---

Euh... pardon ?
Quand tu passes en C++ tu débranches une partie de cerveau ?
En quoi JAVA pousserait plus à l'utilisation d'interface que C++ ?