Discussion :

[koala01]

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

[loufoque]

En Java, tu ne peux pas faire new List<Integer>[42], par exemple.
Pourquoi ? Parce que restriction débile.

[Noxen]

Il y a Eclipse, qui est pas mal comme EDI pour le java

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.

[millie]

Quand on connait et qu'on a des bases en C++
est-il difficile d'apprendre le Java?

Tu veux dire quoi par "apprendre le Java" ?
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...

[koala01]

<snip>
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

[Luc Hermitte]

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.

[Noxen]

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

[maxim_um]

Sinon a priori, passer de C++ à Java, ça prend une journée à tout casser.

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.

[Matthieu Brucher]

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.

[white_tentacle]

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)

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.

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++

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

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

[zais_ethael]

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.

[white_tentacle]

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

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

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

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.

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.

[zais_ethael]

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.

C'est vrai mais, hey!, fallait bien un point de départ 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).

[buggen25]

Il faut passer vers java de la manière suivante, detecter dès le depart les differences entre c++ et java :
Exemple :

Code :

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

1
2
3
 
/*C'est la plus utilisé, pour passer des argulents*/
int main(int argc, char* argv[])

Par contre java, c'st un peu plus compliqué :

Code :

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

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[]) { }

C'est pas compliqué comme main, j'ai pas réussi a trouver la bonne.

[Niark13]

Tu y étais presque :

Code :

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

1
2
 
public static void main(String[] args)

[Noxen]

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 ? ).

[zais_ethael]

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

[Luc Hermitte]

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

[Noxen]

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