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;)
Version imprimable
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++.
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.
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 ;)
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 livre
"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.
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:
1
2
3 /*C'est la plus utilisé, pour passer des argulents*/ int main(int argc, char* argv[])
C'est pas compliqu� comme main, j'ai pas r�ussi a trouver la bonne.Code:
1
2
3
4
5
6 public static int main(String[] args) { } static void main(String[] args) { } public static void main(String args) { } final public static void main(String[] arguments) { } static public void main(String args[]) { }
Tu y �tais presque :
:DCode:
1
2 public static void main(String[] args)
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 :)