Quand on connait et qu'on a des bases en C++
est-il difficile d'apprendre le Java?
Version imprimable
Quand on connait et qu'on a des bases en C++
est-il difficile d'apprendre le Java?
Je dirais que non. C'est surtout l'inverse qui est compliqué.
quant au principe de programmation, de la syntaxe,
du langage objet, est-ce similaire?
en fait, je pose cette question parce que j'ai dit que je savais programmé en Java pdt un entretien, et c'est faux
Alors j'ai deux semaines pour apprendre les bases du java
est-ce possible.
Lol bien sur, c'est tres simple de passer de C++ a Java.
En 2 semaines tu devrais avoir le temps de revoire toutes les bases + faire le tour
des bibliotheques equivalentes a la STL et bien plus.
Ce que tu peux difficilement apprendre en 2 semaines c'est le langage + le framework utilise. Que vas-tu faire ? du devellopement web, serveur, graphique, ....
Java est un vaste langage. Ce n'est pas le langage qui est dur a apprendre. Ce sont les milliers d'environements et frameworks differents.
en ce qui concerne les framework j'en sais absolument rien.
je veux deja apprendre les bases de Java, la syntaxe quoi.
Ensuite, je crois que dans les offres d'emplois, c'est le truc JSEE ou JS2EE qui est souvent demandé.
Java est très demandé sur le marché effectivement.
Aller de C++ à Java est bien moins dur effectivement que de passer de Java à C++.
Toutefois, cela dépend du niveau que tu as en C++. Si tu connais à peine les classes, tu n'auras pas beaucoup d'avance sur l'apprentissage de Java. Si tu maitrises la POO en C++, ça ira sans trop d'encombres.
Mais dans tous les cas, faudra bosser, pratiquer beaucoup, comme d'habitude.
Salut,
De mon avis personnel, on a surement plus facile à passer de C++ à java que l'inverse... De là à dire que cela se fait sans embûches ni cris, il y a surement énormément de marge ;)
S'agissant de deux langages utilisant le même vocable de "Langage Orienté Objet", il est surement très facile de faire une liste des points communs que l'on rencontre, parmi lesquels une approche séquentielle de la programmation et donc un approche similaire en ce qui concerne les structures de contrôle (tests vrai/faux ou à choix multiples, boucles en tous genres, récursivité,...) et, malgré tout, une certaine concordance au sujet de ce qu'est un langage orienté objet, avec un système permettant de "séparer" un groupe d'objet (namespace en C++, packetages en Java, même si, de mémoire, ce n'est pas tout à fait équivalent...), de faire cohabiter des fonctions et des variables au sein d'un objet, la possibilité de déclarer (définir) des variables et des fonctions de classes (statiques) ou des variables et des fonctions d'instances, etc...
Mais, pour notre malheur, il y a au moins autant de différences entre le C++ et Java qu'il n'y a de similitudes (je serais presque tenté qu'il y en a même plus)...
Par exemple, il faut savoir que, même si tu n'indique rien explicitement, toute classe en java sera considérée comme descendant de ... la classe Object, qu'il n'autorise pas l'héritage multiple, et qu'il fait une distinction entre ce qui est hérité et ce qui vient d'une interface.
Nous pourrions aussi nous attarder sur le fait que C++ est un langage a priori compilé alors que Java est plutôt (même si ce n'est pas tout à fait vrai) un langage interprété, ou du moins en partie, sur le fait que lorsque le programmeur décide de prendre la responsabilité de gérer lui-même l'allocation de la mémoire en C++, il reste responsable de la libération de la ressource, alors que Java dispose de son "ramasse miettes" ou qu'un javaiste ne s'étonnerait qu'à moitié de trouver un code proche de
ce qui pourrait surprendre un codeur en C++...Code:zippe(crypte(read("Fichier.txt")));
Et je suis trop fatigué aujourd'hui pour créer une liste exhaustive des différences :P
Au final...
Je crois qu'avec une bonne connaissance de la conception, tu devrais avoir facile à passer de l'un à l'autre.
Comme je l'ai dit, j'estime qu'il est surement plus facile de passer de C++ à Java que l'inverse, mais, mon avis personnel est que, si tu n'a pas pris l'habitude de réfléchir 30 secondes à la logique ou à la conception de tes besoins, le seul fait de connaitre le C++ ne te permettra ni de faire quelque chose de correct en C++ ni d'apprendre à faire quelque chose de correcte en java ;)
+++Citation:
Envoyé par koala01
Le noeud du problème est là : java, C++, C# ou n'importe quel autre langage, la première maîtrise vient d'une aisance en conception logicielle et d'une bonne compréhension des concepts qui sous-tendent l'approche objet. Ensuite, ce n'est que s'adapter à un langage particulier avec ses plus et ses limites.
Je ne suis pas d'accord avec vous.
C'est très difficile de passer de C++ à Java, c'est très frustrant :).
Tes bases (solides ?) en C++
+
un bon bouquin parcouru dans les grandes lignes et/ou la FAQ de dvp (dépend de si tu as déjà quelques notion de Java)
= un niveau théorique suffisant en peu de temps
S'il te reste du temps tu pourras approfondir sur les BD/applets/JavaMe/... selon le profil recherché.
Après reste le problème qu' avoir juste un bon niveau théorique n'a jamais fait un bon programmeur. Mais ton expérience et ta logique en C++ peut palier temporairement à ça.
Bonne chance
Ps: pour ton entretien je vois bien le genre de question A quoi sert le mot clé final ?
C'est effectivement une très mauvaise décision :aie:Citation:
Envoyé par white_tentacle
Par contre, j'ai eu plusieurs retours de javaistes qui se sont mis au C++, et beaucoup de choses les gênaient. Il en ressort qu'en C++ on est "trop libres", que ce soit de faire des bêtises (notamment en gestion de mémoire) ou de réaliser des choses fantastiques.
Personnellement, ayant fait du VB .net pendant mon BTS et du C++ je n'ai pas eu de réelle difficulté à me mettre à Java pour le master.
Ce qui peut surprendre au début ce sont les différences d'habitudes entre les 2 langages. Par exemple, le prof utilisait les casts à tire-larigo. La copie est lente en Java, alors les paramètres se passent par référence, il y a peu de constructeurs par copie dans la bibliothèque de base, pour copier des objets il faut recourir explicitement au clonage (interface Clonable). Les interfaces sont très utilisées en conception. Il y a le garbage collector pour gérer la mémoire. Comme tout est objet, il n'y a pas de fonctions globales, pour pallier à ça on crée des classes pour servir de boîte à outil avec des fonctions static : par exemple, si vous avez une classe Graph, vous aurez peut-être une classe Graphes avec des fonctions static pour manipuler les Graph.
Et tout ça sans compter les différences de technologie et d'emploi de ce langage.
Et j'en passe et des meilleures...
J'en sais rien en fait. Je maitrise pas les templates, je maitrise un peu les classes et les objets, les struct, les typedef struct. les libraries boost et wxwidgets.Citation:
Tes bases (solides ?) en C++
Mais je me sers du C++ surtout pour la rapidité de calcul et donc ca demande pas vraiment de faire de la conception objet
pas très grave vu que ça n'existe pas en JavaCitation:
Envoyé par deubelte
Plus embêtant puisque tout est Objet. Mais ce sont des concepts relativement naturel et donc facile à appréhender (encore plus en Java : pas d'héritage multiples, notion d'interface, ...)Citation:
Envoyé par deubelte
merci
existe il un IDE gratuit de microsoft comme Visual C++ expres qui permet de faire du java?
Crosoft a sa propre version de Java, J#, qui fait partie des langages .net, disponible dans visual studio. Il n'y a par contre pas d'EDI dédié dans les version express (il faudrait voir si ce n'est pas disponible par exemple dans visual C# express ou vb express, je ne suis sur de rien).
Pour Java, les outils traditionels, disponibles sous windows, sont eclipse et netbeans (consulter leurs sites respectifs).
Netbeans et Eclipse sont les deux qui sont les plus en vogue dans le monde Java.
Mais pour des questions purement Java, je te conseille de te rendre sur le forum Java de Developpez, tu auras plus de réponses et des plus pertinentes ;)
Nope. int n'est pas un objet.Citation:
Envoyé par befalimpertinent
Sauf qu'en C++ tu fais pas d'allocations que tu libères ensuite quand tu veux. Tu utilises le RAII.Citation:
lorsque le programmeur décide de prendre la responsabilité de gérer lui-même l'allocation de la mémoire en C++, il reste responsable de la libération de la ressource
C'est quoi le problème avec ce code en C++ ?Citation:
zippe(crypte(read("Fichier.txt")));
C'est pas pire en C++ qu'en Java. En C++ il serait intelligent de faire des expressions templates, mais en Java tu dois pouvoir faire un truc plus ou moins équivalent, bien que moins efficace.
Sinon a priori, passer de C++ à Java, ça prend une journée à tout casser. Le plus compliqué étant de comprendre les restrictions débiles des génériques.
C++ et Java n'ont pas les mêmes objectifs. En C++ on a une liberté qui est inégalée de mon point de vue. En Java, c'est plus restreint. Les générique sont surtout pour les containers et diminuer la duplication de code. On ne peut pas travailler sur la génération de code & compagnie.Citation:
Envoyé par loufoque
Et quelques heures à tout casser pour le langage lui-même. Pour sa bibliothèque standard et les bibliothèques importantes ça prend plus de temps :aie:
Il y a Eclipse, qui est pas mal comme EDI pour le java ;)
Tu devrais aussi t'intéresser à la partie java du site, qui est une section très développée également;)
En Java, tu ne peux pas faire new List<Integer>[42], par exemple.
Pourquoi ? Parce que restriction débile.
En particulier j'aime bien toutes les petites options de refactoring, comme la possibilité d'extraire d'une classe une interface ou une classe abstraite, la completion de code qui est généralement très efficace, la reconnaissance des erreurs à la volée ; par exemple vous pouvez séelectionner une variable, Eclipse va la reconnaître à travers tout le code et vous pouvez changer son nom, ce sera reporté partout. C'est dommage d'avoir assez peu d'options similaires en C++.Citation:
Envoyé par koala01
D'un autre côté, je suppose que c'est possible en Java parce-que c'est un environnement relativement structuré (d'autres diraient restreint, ce ne serait pas faux) ; en C++ il y a beaucoup de choses qui se gèrent en textuel avant même la compilation du code, avec des includes en cascade on pourrait répartir la description d'une classe sur une quinzaine de fichiers, ce doit être plus dur d'analyser en permanence un projet de la sorte. Il me semble avoir lu qu'un type disait que les fonctionnalités comme la completion de code ou l'Intellisence (crosoft tm) pour le C++ demandent quasiment le travail d'un petit compilateur.
Tu veux dire quoi par "apprendre le Java" ?Citation:
Envoyé par deubelte
Car il y a le langage Java qui est relativement simple (surtout si l'on vient du monde C++) et la bibliothèque standard Java qui est très très grosse...
Quel que soit le langage pour lequel tu souhaite mettre au point un système de complétion automatique, tu devra mettre au point un système d'analyse syntaxique du code ;)Citation:
Envoyé par Noxen
Il ne faut pas confondre les possibilités offertes par les différents outils et celles offertes par un langage en particulier.
N'oublie pas que "l'intelligence" d'une application (qu'il s'agisse d'un simple éditeur de texte ou d'un EDI ou d'un RAD complet) n'est que celle que ses concepteurs ont pu / su / voulu lui donner.
En effet, si le système d'auto complétion de Eclipse est sympa, c'est, d'abord et avant tout grâce aux personnes qui l'ont mis au point ;)
N'oublie jamais qu'il est tout à fait possible de décider de coder en java (tout comme il est possible de décider de le faire en C, en C++ ou en n'importe quel autre langage) avec des outils aussi simples que le bloc note (ms), vi, vim ou autres ;)
La difficulté pour fournir des extensions de type refactoring est effectivement liée au langage et aux outils disponibles qui sont capables de le comprendre. Hormis les monstres comme VC/Visual Assist, et Eclipse/CDT qui a tout recodé, tous les autres tendent à s'appuyer sur ctags qui a une compréhension bien partielle du C++ (il n'est même pas fichu de nous donner le contexte (espace(s) de noms + nom(s) de classe(s)) où sont déclarés les divers symboles extraits)
(Et même pour Vim il est possible d'offrir des fonctionnalités simples de refactoring pour le C++ désolé pour la pub)
Sinon, il y a effectivement des différences de langages (les plus visibles étant liées aux techniques de restitution déterministe de ressources, à l'absence de sémantique de valeur, des différences dans la gestion de la généricité (et tous les hacks du java autour de equals pour compenser).
Mais je pense que l'essentiel sera du côté des bibliothèques et des frameworks que tout le monde utilise.
Ce que je voulais dire c'est que la structure qui entoure le langage Java (par exemple que tout est objet, que toute classe dérive au minimum de Object, etc...) et qui restreint les options des développeurs doit peut-être permettre d'un autre côté de créer certains outils plus facilement. Le C++ à contrario est un joyeux bordel de ce point de vue (mais alors, oui, on peut faire ce qu'on veut avec, le pire comme le meilleur), un .cpp peut inclure à partir d'un fichier une quinzaine d'autres ; mon dernier exploit en date c'est d'avoir fait planter VC sur des templates.
Je me demande si pour le C++ cette "structure" assez bordelique ne peut pas poser des problèmes, notamment de performance. Des collègues lors d'un stage m'ont parlé de compilations qui peut durer des heures (tu la lance le soir en quittant le boulot et tu reviens le lendement en priant qu'il n'y ait pas eu de problème pendant la nuit). En admettant qu'un projet puisse prendre même simplement quelques minutes à compiler, un outil de refactoring ne va-t-il pas atteindre rapidement ses limites en terme de performance (personne n'attendra 45 secondes pour qu'une autocompletion se fasse) ?
Hum, ça ferait un excellent titre de livreCitation:
Envoyé par loufoque
"Passer de C++ à Java en 21 heures"
voici déjà la note de l'auteur:
Cher lecteur. Sachez qu'après la lecture de ce livre, vous ne pourrez vous contenter que de 3 heures de sommeil... après quoi vous aurez congratulé votre journée d'apprentissage.
Il y a aussi des différences de conception entre les deux. Par exemple, on trouvera fréquemment des classes qui ont des sous-classes dérivant d'Executor, un pattern assez rare en C++, mais qui se trouve partout en Java.
Vu que le système de type est turing complet, tu peux faire un code valide qui mette un temps infini à compiler. Mais tu n'as pas besoin de compiler pour de la complétion de code, il te suffit de l'analyse syntaxique + sémantique.Citation:
Des collègues lors d'un stage m'ont parlé de compilations qui peut durer des heures (tu la lance le soir en quittant le boulot et tu reviens le lendement en priant qu'il n'y ait pas eu de problème pendant la nuit)
Honnêtement, entre VC++ et kdevelop, je suis au final plus satisfait de la complétion offerte par kdevelop. Celle de visual c++ ne m'a vraiment jamais convaincu. Le gros problème, en C++, c'est aussi le préprocesseur (détecter dans quels #if tu es, etc...).Citation:
La difficulté pour fournir des extensions de type refactoring est effectivement liée au langage et aux outils disponibles qui sont capables de le comprendre. Hormis les monstres comme VC/Visual Assist, et Eclipse/CDT qui a tout recodé, tous les autres tendent à s'appuyer sur ctags qui a une compréhension bien partielle du C++
La seule bonne complétion automatique que je connaisse est celle de Visual C# (très peu à y redire). Il utilise le compilateur pour générer les informations contextuelles. C'est à mon avis la seule bonne manière de faire (ça impose aussi d'avoir un compilateur plus modulaire que gcc, et un langage plus simple que C++ aide).
Il y a plusieurs choses à dire à ce sujet.
Apprendre un langage impératif orienté-objet en connaissant déjà l'impératif et l'orienté-objet n'a rien de compliqué, tout le monde te le dira. Ça se fait en une grosse soirée de lecture de tutoriels et quelques jours de pratique histoire d'ancrer ça dans ses habitudes. Néanmoins quand tu dis connaitre le C++ de façon superficielle j'ai un doute, surtout si tu ne connais pas d'autre langage orienté objet. N'en déplaise à beaucoup, on utilise bien peu d'orienté object en C++. Et quand on le fait "comme dans le cours du prof", on le fait généralement mal. Autant on peut être un très bon programmeur C++ en ne faisant jamais d'orienté object, autant c'est indispensable en Java. Alors même si tu crois maitriser, suis quand même quelques cours dédiés à la conception OO une fois les bases du Java acquises (quoique de mon point de vue, le mieux pour apprendre l'OO c'est encore les langages à objets par prototypes - Javascript powaa!).
Qui plus est, il faut savoir un peu lire entre les lignes. Le Java n'est pas un langage complexe, mais ce n'est pas qu'un langage non plus. Le SDK contient une bibliothèque standard de taille conséquente. Ainssi quand un employeur demande si tu sais coder en Java, cela implique également une certaine connaissance de cette bibliothèque standard.
Pour rappel:
Java SE (J2SE) : partie cliente du JDK, en gros ça consiste à faire des interfaces graphiques
Java EE (J2EE) : partie serveur, principalement de la création de sites webs, de la gestion de bases de données, et l'implémentation de couches de services
Si ton employeur avait fait allusion à l'un de ces deux termes dans son annonce, va falloir t'y mettre, et ça ça prends du temps tu peux me croire ;)
Sinon, pour les petits détails, il y a deux principaux IDE Java gratuits: Eclipse et Netbeans. Chacun a son favoris. Pour faire court Eclipse est plus ancien et surtout a été beaucoup plus populaire par le passé, ce qui a pour conséquence qu'il existe énormément des plugins pour cet IDE. Netbeans est fait par Sun et il possède moins de plugins fais par des tiers. Néanmoins, de base, il contient plus de fonctionnalités liées au JDK et aux technologies "officielles" du Java. A toi de voir, moi je recommanderais plus Netbeans pour commencer.
iiirk ! L'objet par prototypes, c'est encore autre chose. Certains aiment, moi, j'ai vraiment du mal (comme avec tout ce qui est faiblement typé en général).Citation:
Alors même si tu crois maitriser, suis quand même quelques cours dédiés à la conception OO une fois les bases du Java acquises (quoique de mon point de vue, le mieux pour apprendre l'OO c'est encore les langages à objets par prototypes - Javascript powaa!)
Pour apprendre la poo correctement, il y a la bible (en français, pour ne rien gâcher) : http://www.editions-vm.com/Livre/978...rientees-objet
En C++, on fait de l'objet quand c'est nécessaire. En csharp ou java, on fait de l'objet tout le temps. Mais il y a un nombre d'erreurs de conception assez important dans les bibliothèques standard java et csharp (elles sont conséquentes et ont été développées rapidement, c'était inévitable), qui semble dire qu'on ne le fait pas mieux.Citation:
N'en déplaise à beaucoup, on utilise bien peu d'orienté object en C++. Et quand on le fait "comme dans le cours du prof", on le fait généralement mal.
C'est vrai mais, hey!, fallait bien un point de départ :P Le problème provient plus de l'obsession de Sun de ne pas casser la rétro-compatibilité (une rumeur dit que certains trucs deprecated depuis des lustres seraient virés dans la version 7).Citation:
Envoyé par white_tentacle
Il faut passer vers java de la manière suivante, detecter dès le depart les differences entre c++ et java :
Exemple :
Par contre java, c'st un peu plus compliqué :Code:
2
3
C'est pas compliqué comme main, j'ai pas réussi a trouver la bonne.Code:
2
3
4
5
6
Tu y étais presque :
:DCode:
2
Sachant bien sûr que ce main sera déclaré comme une méthode de classe, et non comme une fonction globale comme en C++ ou en C (on a bien dit qu'en Java tout est objet, non ? ;) ).
Je ne vois pas vraiment le rapport entre de l'orienté objet et des attributs/méthodes statiques. Je pense que ce concept avait été établi (peut-être par le C++) pour gérer plus facilement les droits d'accessibilité (public, private,...) entre des classes, des variables globables et des fonctions.
Pour moi la raison pour laquelle on ne peut déclarer des fonctions que sous la forme de méthodes statiques en Java est liée au fonctionnement strict des packages. C'est raison n'est pas seulement conceptuelle, c'est aussi justifiable d'un point de vue technique.
En Java, chaque classe est compilée en un fichier .class. Imaginons que nous ayons un fichier .class contenant une méthode main() avec plein d'autres .class à coté, mais aucun n'est utilisé directement ou indirectement par la classe contenant le main (on va dire qu'il se contente d'afficher un hello world). Si on lance le programme, seule la classe contenant le .main sera chargée par la machine virtuelle Java, celle-ci ne touchera à aucune autre classe contenue dans l'archive.
Pourquoi? Parceque le système de chargement de la description des classes utilise un principe de lazy-init. Il ne charge un fichier .class que quand il sait qu'il en aura besoin, à n'importe quel moment durant l'exécution. Or, avec un tel fonctionnement, non seulement on ne peut pas maintenir une map globale des définitions de classes (comme le ferait un compilateur C++ par exemple) mais en plus le fichier contenant la description d'une classe doit pouvoir être localisé en temps constant. C'est là que la rigueur des packages prend tout son sens puisque à partir du nom complet d'une classe (exemple: java.util.Vector) on peut déduire immédiatement le fichier contenant sa définition dans une archive zip ou dans le file system (exemple: java/util/Vector.class).
Comme un compilateur peut aisément déduire le nom complet d'une classe en regardant dans un seul fichier, je suppose que ça contribue aussi à simplifier la compilation (et, par voie de conséquence, l'auto-completion, le refactoring, etc...).
Au sujet de la digression sur l'intellisense, voici un petit point au sujet de celle de VC10: http://blogs.msdn.com/vcblog/archive...beginning.aspx
:? Tout ce que je disais c'est qu'en C/C++ le main est une fonction globale, et qu'en Java les fonctions globales n'existent pas, donc le main est une fonction public et static dans une classe ; je ne cherchais pas plus loin que ça.
@Luc intéressant cet article, merci :)