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 :)