En résumé, C# ayant dû faire des concessions à C++ ne protège pas correctement les accès mémoires.
On notera un petit dérapage sur Emacs avec mise au point de Richard Stallman égratignant au passage la prétendue moralité SUN lorsqu'ils se font les chantres de l'open source pour se ramasser de la main d'oeuvre venue du monde du libre.
Note du modérateur : Merci à G78 pour le lien sur la page personnelle de James Gosling
Aller plus loin
- L'interview sur CNET (86 clics)
- La correction forte à propos de R. Stallman (22 clics)
- Une traduction «light» sur ZDnet (75 clics)
- Page personnelle de Gosling (22 clics)
# Yep
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
La précision de RMS est la bienvenue ...
Ceci dit, gosling défend son bébé et troll pas mal, mais je crois qu'il est grosso modo dans le vrai; je trouve Java plus "propre" que C# (et pourtant, j'aime pas java :-P )
Le passage sur la coopération avec IBM est bizarre aussi, genre "nous on était pas au courant, on attendait qu'ils viennent nous demander" ... quelqu'un a suivit ça d'un peu plus près ?
[^] # kikiné le papa à Emacs ?
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
«Or peu d'outils adaptés sont à leur disposition, hormis Emacs. J'ai conçu la première version d'Emacs il y a 23 ans et je constate avec effroi que cet outil est toujours utilisé aujourd'hui tel qu'il était à l'origine. Est-ce là tout ce que l'on peut offrir de mieux à ces développeurs? Je ne crois pas.»
et l'originale :
«And if you look for tools that are oriented toward (those) people, you basically find nothing. The No. 1 tool (in that area) is Emacs, and I was kind of the guy responsible for the original Emacs, 23 years ago. One of the things I find frightening is it's still around, and in many ways it hasn't really changed. Is that the best you can do for a (low-end) developer? I don't think so.»
enfin, la réponse de RMS :
«In your interview with James Gosling, he says that he was "responsible for the original Emacs, 23 years ago." Actually, I wrote the first Emacs editor, in 1975 at the MIT Artificial Intelligence Lab. (I received the ACM Grace Hopper Award in 1991 for this work.)»
Gosling a bien écrit un Emacs pour Unix ceci dit, il n'a peut être pas tord quand à son rôle dans le succès d'Emacs (en partie); RMS ayant écrit GNU Emacs en 84.
de toute façon, Vim rulez ;-)) (voir http://vim.sf.net(...))
# Bof, pas d'accord avec lui.
Posté par reno . Évalué à 9.
C'est juste que C# t'offre en plus la possibilite de gerer toi-meme la memoire pour des raisons de performances ou quand tu as a faire des manipulations de bas niveau et a ce moment la le code est marque "unsafe".
Donc je ne vois pas trop ce que l'on peut reprocher a C#.
Mais bon, mon coup d'oeil a C# fut tres bref..
[^] # Re: Bof, pas d'accord avec lui.
Posté par daniel . Évalué à 7.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Nelis (site web personnel) . Évalué à 10.
[^] # Re: Bof, pas d'accord avec lui.
Posté par darkleon (site web personnel) . Évalué à 10.
C'est un inconvénient et un avantage, mais je pense que les avantages sont plus nombreux dans 95% des cas.
De toute manière quitte à faire de la manipulation mémoire bas-niveau autant utiliser du C pur et dur, au moins tu décide exactement quel sera le comportement de ton application sans avoir des mécanismes new du C++ qui ne font pas toujours ce que tu pense (enfin quand tu n'as pas de malloc ou de free mal placés ou si ton programme ne fait pas autant de malloc que de free).
Autrement je ne vois pas trop l'interêt d'une machine virtuelle si c'est pour coder comme un crade comme sur une vrai machine, tu te retrouves avec les emmerdes de gestions mémoire moins la performance.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
Si un 'new' C++ ne fait pas ce que tu penses, c'est soit un bug dans ton code, soit que tu ne devrais pas coder en C++ (soit les deux :-).
[^] # Re: Bof, pas d'accord avec lui.
Posté par darkleon (site web personnel) . Évalué à 9.
Donc effectivement, il peut y avoir un bug dans le code et je ne code pas en c++, c'est déjà suffisament long de debugger une application car tu n'avais pas prévu un comportement de l'application (je sais théoriquement, ton code doit prévoir tous les cas de figure) pour ne pas t'emmerder à rajouter la recherche des fuites de mémoires parce que ton prédecesseur ou toi-même a oublié une paire new-delete.
Java permet de coder de manière largement plus crade car c'est le "garbage collector" qui s'occupe de ce problème pour toi et ça simplifie tout un ensemble d'erreurs au débuggage.
Pour moi C++ doit être vu comme du C avec l'avantage de faire un découpage plus propre de l'application, car tu es obligé d'être plus propre dans ta conception (chaque objet(structure) à toutes les fonctions pour le manipuler dans un fichier) contrairement au C pur ou tes fonctions peuvent se balader n'importe où.
L'héritage a plusieurs niveaux et multiple du C++, ça existe, mais c'est la première source d'emmerde garantie.
Le problème est le même en Java, j'ai retravaillé une application existante ou les héritages étaient sur-multipliés, alors quand tu devais connaître le comportement d'une fonction ou du constructeur, tu devais parcourir toutes les classes du fils à l'ancêtre, car selon les niveaux, la fonction était surchargée ou pas.
Dans ce cas là, je ne trouve pas que l'objet simplifie la programmation, je dirais plutôt au contraire
C'est un joli modéle en théorie, mais trop en abuser nuit bcp plus à la lisibilité du programme qu'un simple langage procédural.
C'est comme tout, le mieux est l'ennemi du bien.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
Ah ok, je vois ce que tu veux dire. Oui, c'est un pb, mais tu ne peux pas vraiment comparer ça avec un simple malloc() C, c'est pas vraiment la même chose.
Java permet de coder de manière largement plus crade car c'est le "garbage collector" qui s'occupe de ce problème pour toi
C'est pas crade, bien au contraire c'est beaucoup plus pratique et élégant.
Pour moi C++ doit être vu comme du C avec l'avantage de faire un découpage plus propre de l'application, car tu es obligé d'être plus propre dans ta conception
Non, tu n'es pas "obligé", tu peux être plus propre. Être aussi propre en C réclame une discipline quasi-impossible à soutenir, parce que tu vas faire le boulot du compilateur. En C++, tu peux plus facilement être propre parce que le compilateur t'apporte les outils pour ça.
L'héritage a plusieurs niveaux et multiple du C++, ça existe, mais c'est la première source d'emmerde garantie.
Oui, mais l'héritage n'est pas une chose anodine, c'est un outil qu'il faut utiliser à bon escient.
Dans ce cas là, je ne trouve pas que l'objet simplifie la programmation, je dirais plutôt au contraire
Tu confonds la programmation objet et l'héritage. Ça n'a rien à voir. L'héritage est juste l'un des outils qui aident à faire de l'objet, il y en a pleins d'autres. Je te conseille de lire le chapitre d'introduction du Design Patterns.
[^] # Re: Bof, pas d'accord avec lui.
Posté par VACHOR (site web personnel) . Évalué à 10.
Et de plus, pour rappel, l'héritage multiple n'existe pas en Java, sauf pour les interfaces.
Alors comment faire une application "ou les héritages étaient sur-multipliés" ? ;-)
[^] # Re: Bof, pas d'accord avec lui.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Miracle. Mais descend plus bas, y a un autre thread ou on est pas d'accord. :-)
Et de plus, pour rappel, l'héritage multiple n'existe pas en Java, sauf pour les interfaces. Alors comment faire une application "ou les héritages étaient sur-multipliés" ?
Il parlait bien sur d'héritage successif, pas multiple. A qui dérive de B qui dérive de C qui dérive de... etc...
Pour info, dans Rosegarden (rosegarden.sf.net) on a bientot 60kloc, des templates, de l'héritage multiple, mais l'arbre d'héritage n'est pas très profond, 3 ou 4 niveaux maximum je pense, et 90% des classes ne sont pas dérivées, seules certaines classes de base le sont.
[^] # Re: Bof, pas d'accord avec lui.
Posté par darkleon (site web personnel) . Évalué à 8.
Moi aussi d'ailleurs je lui ai mis +1 :-)
Et de plus, pour rappel, l'héritage multiple n'existe pas en Java, sauf pour les interfaces.
Je parlais de C++
Alors comment faire une application "ou les héritages étaient sur-multipliés" ? ;-)
Ben justement, c'était un programme Java ou des classes avaient jusqu'à 5 générations d'ancêtres pour pas grand chose d'ailleurs, car ce n'était pas un arbre équilibré, ça ressemblait plus à une double liste chainée, et les fonctionalités du fils pouvaient ne plus réellement s'appuyer sur l'ancêtre, et en plus il y avait aussi des extensions d'interface (pseudo héritage multiple).
En gros c'était le modéle, alors on a 3 types de base (minéraux|animal|végetaux), alors on a besoin de manipuler des caniches nains et berger allemand
ben je vais définir
une classe animal qui utilise l'interface organique,
puis une classe mamifére qui utilise l'interface terrestre,
puis une classe chien,
puis une classe caniche qui utilisera l'interface nain
et une classe berger qui utilisera l'interface allemand.
Bon je schématise mais tout le programme était conçu comme ça, alors qu'on pouvait partir directement de la classe chien pour dériver les caniches et les bergers.
En soit l'idée n'est pas mauvaise, mais on sentait bien une application directe du cours de conception objet théorique ou tout les ressources mémoires et processeurs sont infinies, et avec des programmeurs qui sont des créatures avec un cerveau pouvant raisonner en 12 dimensions :-)
Quand on prend de la bouteille et qu'on a un cerveau qui ne pense plus qu'en 3 dimensions voire moins, on se simplifie la vie en codant selon la "vrai vie" et plus en théorie :-)
[^] # Re: Bof, pas d'accord avec lui.
Posté par darkleon (site web personnel) . Évalué à 10.
C'est pas crade, bien au contraire c'est beaucoup plus pratique et élégant.
Oui je suis tout à fait d'accord avec toi, moi aussi j'aime bien a ne pas m'occuper de la mémoire.
Je voulais dire par là que tu vas plus facilement te "lacher" en créant pleins d'objets dans tous les sens sans te demander s'il n'y a pas de manières plus optimales pour arriver au même résultat.
C'était juste un point de vue "puriste" que j'apprécie en théorie mais que je mets jamais en application en pratique :-) sauf en C ou je n'ai pas le choix (enfin si j'ai le choix d'avoir une application buggée :-)
Être aussi propre en C réclame une discipline quasi-impossible à soutenir, parce que tu vas faire le boulot du compilateur. En C++, tu peux plus facilement être propre parce que le compilateur t'apporte les outils pour ça.
C'est ce que je voulais dire, C++ t'apporte des mécanismes qui force ta conception et du coup rend les choses plus propres (sauf si on met du pur code C bien dégueulasse à l'intérieur évidemment car C est laxiste).
Oui, mais l'héritage n'est pas une chose anodine, c'est un outil qu'il faut utiliser à bon escient.
Tu confonds la programmation objet et l'héritage.
Moi non, mais le problème c'est que dans certains programmes que j'ai repris, apparement cette idée n'avait pas été assimilée.
Je fais des héritages uniquement sous l'effet de la torture, quand raisonnablement ça apporte un réel plus.
<apparté>
Je travaille en SSII, je parle de code programmé par des débutants (qui étaient trés loin d'être mauvais d'ailleurs) en milieu professionnel.
Ils manquaient juste un peu d'expérience pour savoir quand est ce qu'il fallait appliquer le "manuel du parfait petit programmeur objet qui fait plein d'héritage car les héritages c'est jolis, les héritages c'est bon, mangez en" et quand est ce qu'il fallait dire "STOP". :-)
</apparté>
Mais je suis le premier à écouter un étudiant tout frais moulu quand il propose des idées, car il n'a pas d'idée préconçue ce qui permet d'avoir un autre point de vue, et d'éviter d'avoir une vision monobloc de la solution à un problème car je peux aussi faire des erreurs.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
C'est vrai, tant que tu ne te soucies pas des perfs :-). Mais ça n'est pas la seule raison. Si tu fais du C++, tu dois régulièrement de faire chier avec des problèmes d'appartenance (quel objet doit effacer tel autre, etc...), qui exigent un maximum de rigueur pour être résolus. Contrairement à ce qu'on dit souvent, il n'y a pas de manière systématique de les gérer en C++, et un GC aide énormément pour ça. Je préfère dire que ça te permet de gagner du temps sur des problèmes souvent très complexes, plutôt que "ça te permet de te lacher".
C'est ce que je voulais dire, C++ t'apporte des mécanismes qui force ta conception
C'est juste le mot "force" sur lequel je ne suis pas d'accord. C++ ne force rien, il t'offre une possibilité. Java te force à faire de l'OO, pas C++.
Ils manquaient juste un peu d'expérience pour savoir quand est ce qu'il fallait appliquer le "manuel du parfait petit programmeur objet qui fait plein d'héritage car les héritages c'est jolis, les héritages c'est bon, mangez en" et quand est ce qu'il fallait dire "STOP". :-)
Alors nous sommes tout à fait d'accord.
Mais je suis le premier à écouter un étudiant tout frais moulu quand il propose des idées, car il n'a pas d'idée préconçue
On doit pas connaitre les mêmes étudiants :-). Enfin, je suis un peu contaminé par ce que je lis sur DLFP :-).
[^] # Re: Bof, pas d'accord avec lui.
Posté par darkleon (site web personnel) . Évalué à 2.
C'est cool, tu traduis en termes plus exacts mes pensées incohérentes, j'ai encore des efforts à faire pour être plus compréhensible.
C'est exactement les problèmes auquels je pensais.
Je préfère dire que ça te permet de gagner du temps sur des problèmes souvent très complexes, plutôt que "ça te permet de te lacher".
C'est pour cela qu'on peut se lacher sur les allocations sans sortir un diagramme sur la gestion de la cohérence de la mémoire :-)
<séance typique de débuggage>
Alors là j'ai fait un new, bon dans ce cas là il faut faire un free, ah oui mais si la variable touintouin est vrai, alors non, ok, ah merde mais l'objet tada va en avoir besoin après si jamais, bon je crois que c'est bon là, make, toto.exe, coredump, ah merde j'ai oublié le cas ou on rentrait dans cette boucle que j'ai rajouté il y a 2h et que merde, ça casse tout, bon reprenons ....to be continued
</séance typique de débuggage>
C++ ne force rien, il t'offre une possibilité.
C'est vrai, mais si c'est pour faire du C en C++, autant faire du C, c'est un "forçage" moral pas technique.
L'inverse est encore plus vrai, déjà vu du code OO en C, bonjour l'angoisse pour le débuggage avec des pointeurs à rallonge pour simuler les classes sur des "struct" de fonctions.
-1 car squat de file
[^] # la solution était
Posté par darkleon (site web personnel) . Évalué à 1.
Si même dans mes exemples je me plante.
-oo car squat de mon squat
[^] # Re: Bof, pas d'accord avec lui.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Il faut faire un delete, malheureux ! :-)
C'est vrai, mais si c'est pour faire du C en C++, autant faire du C
Oui bien sur, mais il y a aussi des fois ou tu as vraiment besoin d'une simple fonction stand-alone, etc... C'est bien de pouvoir "débrayer" certaines choses.
L'inverse est encore plus vrai, déjà vu du code OO en C [...]
A qui le dis-tu (j'ai bossé 3 ans sur Gtk-- :-). Plus jamais ça.
[^] # Etudiants frais moulu
Posté par darkleon (site web personnel) . Évalué à 0.
On doit pas connaitre les mêmes étudiants :-). Enfin, je suis un peu contaminé par ce que je lis sur DLFP :-).
Je ne suis pas clair aujourd'hui, enfin si il a ses idées préconçues qui ne sont pas les miennes :-)
Mais il n'aura pas de réelle idée FORGEE sur la manière de traiter un problème auquel il n'aura pas été confronté même s'il a des idées préconçue fortes sur la manière optimale de traiter le problème.
Car seul un jeunes mec intelligent, face aux vieux cons qui ne comprennent rien à rien à l'informatique, peut le résoudre :-)
Du coup, c'est vrai que c'est plutôt le vieux con qui gagne à la fin, mais ça ne lui empéchera pas d'intégrer les éventuelles bonnes idée du jeune mec intelligent si elles sont réellement intelligentes. Et le jeune intelligent prendra de l'expérience s'il est assez intelligent pour écouter le vieux con. :-)
L'avantage du jeune intelligent, c'est qu'il aura des idées plus fraiches sur les nouvelles techniques de conception et de programmation, tandis que le vieux con, lui aura le retour d'expérience pour tempérer les ardeurs du jeune et relativiser le gain réel de telle ou telle technique.
-1
[^] # Re: Etudiants frais moulu
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Dans le cas de l'étudiant Linuxien, c'est pire, parce qu'il est le plus souvent shooté à l'idéalisme made in RMS, et il arrive non pas avec des nouvelles technos à la mode, mais avec des traditions et une idéologie. Y a qu'a voir les réactions sur la news récente à propos de Miguel et .Net, c'est un exemple parmi plein d'autres. Si tu leur dit "cet outil là marche mieux", il va immanquablement te répondre "oui mais sous Unix/Linux on fait comme ça depuis des années et ça marche".
Et autant faire bouger quelqu'un qui suit une mode est relativement facile, autant sortir quelqu'un de ses traditions est quasi impossible.
- Tu veux pas utiliser un IDE ?
- Nan, j'ai pas besoin, xterm+vi+make ça marche
- Et le temps que tu perds à chercher les fichiers dans l'arborescence, à faire des find | xargs grep pour trouver les definitions de fonctions ?
- M'en fous j'vais m'faire mes scripts et puis ctags roulaize.
J'en parle d'autant mieux que j'ai été comme ça (enfin, pas loin). Et j'utilise toujours pas d'IDE au bureau, mais c'est parce qu'il n'y en a pas qui tienne vraiment bien la route sous Linux :-).
Après c'est vrai, ils peuvent apporter des idées nouvelles, et les vieux cons aussi ont leurs habitudes bien ancrées dont il est bon de les faire bouger. Donc globablement, je dirais que les étudiants c'est bien, mais faut y aller avec des pincettes.
Enfin, on est d'accord là dessus je crois :-).
[^] # Re: Bof, pas d'accord avec lui.
Posté par Vincent Creusillet . Évalué à 3.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Thomas Cataldo (site web personnel) . Évalué à 10.
genre
public void unsafe monGrosLeak() {
int monPoiteur = malloc(10);
}
Avec java tu écrirait:
public void native monGrosLeak();
puis tu passes ta classe dans javah, qui va générer des entêtes (.h) avec la signature C équivalente de ta méthode. Puis c'est à toi d'implementer la méthode C séparément et d'en faire une librairie.
C# permet donc d'utiliser rapidement du code natif, mais ca fait un mélange pas très heureux. Avec java, c'est plus long et fastidieux à écrire, mais tu a une séparation complête entre le code natif et le code java.
A mon avis, il faut se lever tôt pour arriver à gagner en performance en gérant sa mémoire soi même (dans du java et du C#).
En tout cas, pour mettre au même niveau C++, C# et vb, il ont du bien crader le C++... Avec un rapide coup d'oeuil sur msdn, on trouve des signatures C++ qui ressemblent à ca:
void __gc __delegate MaClasse::maMethode();
Ils ont peut être déposé C# dans les règles, mais le C++ en a pris un coup.
[^] # Re: Bof, pas d'accord avec lui.
Posté par PAtrice Manac'h . Évalué à 8.
Ensuite, vu la séparation entre le code managed et le code unmanaged, ce genre de problème est peut probable. En effet, le mot clé ne s'applique qu'à des classes et méthodes et non à des variables. Dès que la CLR détecte ce mot clé, elle place l'assembly (la librairie en quelque sorte) dans un espace dédié. Si le code fait des choses incorrectes, cela n'impacte pas l'application ou la librairie appelante.
Si j'étais vache, je dirais que tout appel JNI représente le même danger pour une JVM : aucun si la JVM est bien codée :)
[^] # Re: Bof, pas d'accord avec lui.
Posté par VACHOR (site web personnel) . Évalué à 5.
Un ordi reste un ordi...
[^] # Re: Bof, pas d'accord avec lui.
Posté par VACHOR (site web personnel) . Évalué à 10.
Exemple : "They had this problem in their design rules that they had to support C and C++, which means you have to have a memory model where you can access everything at all times" : Cela signifie que, comme d'habitude, on aura droit à de bon gros bug qui font planter le système... rehaussé par "they added gratuitous things and other things that are outright stupid. That's amusing"
Citez moi un truc intéressant qu'un langage fait et qu'on peut pas faire en Java :-)
A propos du "unsafe", le système de sécurité de Java permet d'accord des permissions de façon fine : accès réseau, mémoire, disque, etc. La c'est juste marqué "unsafe", super !
C# reste décidémment une tentative de plus de M$ pour contrer SUN sur le terrain Java. Ils ont déjà essayé avec ActiveX, DCOM, etc, où les représentants officiels de M$ ont admis que s'ils avaient pu, ils auraient pris les mécanismes mis en place dans les beans... Mais bon c'est du M$, et ça marche pas ;-)
"Imitation is the sincerest form of flattery--thank you very much". Evidemment, c'est bien d'imiter, mais quand c'est M$ qui le fait je suis pas convaincu.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Tu en as en Java aussi. Une JVM peut parfaitement planter, ton code peut jeter une exception et ne pas la traiter. Et tu n'es pas "obligé" d'utiliser "unsafe".
Citez moi un truc intéressant qu'un langage fait et qu'on peut pas faire en Java :-)
L'operator overloading. D'ailleurs Gosling avait fait une proposition pour l'ajouter à Java :
http://java.sun.com/people/jag/FP.html#overloading(...)
Enfin, il y a des "extensions" non-officielles de Java qui supportent ça je crois, mais bon, c'est quand même mieux quand c'est en standard dans le langage.
[^] # Re: Bof, pas d'accord avec lui.
Posté par VACHOR (site web personnel) . Évalué à 5.
Alors ça je m'en passe sans regret !
Et de préférence je n'en veut pas ! (voir les bouquins qui causent de codage propre, ils jettent tous cette technique moyenageuse du C++).
[^] # Re: Bof, pas d'accord avec lui.
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
Je présume que tu as lu les raisons que Gosling donne pour vouloir l'ajouter à Java, et qu'elles t'ont semblées complètement stupides.
Et comme tu dis que "tu" t'en passe sans regret, il est clair que ça doit être le cas pour absolument tous les autres programmeurs de la planète.
voir les bouquins qui causent de codage propre, ils jettent tous cette technique moyenageuse du C++
Lesquels ? Et, sachant que des bouquins fondamentaux de C++ (Stroustrup, Austern, Koenig) citent l'operator overloading comme une technique importante, permettant de clarifier le code, devons-nous conclure que ces auteurs sont, comme Gosling, des imbéciles ?
[^] # Re: Bof, pas d'accord avec lui.
Posté par Cédric Foll . Évalué à 7.
Imaginons une bibliothèque C++ permétant la manip de nombres entiers en multipécision.
Sans surcharge c'est une horreur, avec ça devient très facilement utilisable. On peut même passer de la prog en entier classique vers celle en multiprécision en ne changeant que la ligne relative à la déclaration des variables.
En plus le << c'est très utile.
D'ailleur le merveilleux langage objet qu'est Ruby l'implémente avec bonheur et c'est ce qui le rend si compact par rapport à du Python.
[^] # Surcharge d'opérateur
Posté par darkleon (site web personnel) . Évalué à 7.
De toute manière, c'est dans ce sens là que ça a été pensé.
Autant il est plus logique d'avoir
MatriceCarre(3x3) A,B,C,D; C = A + B; D =A * B;
Maintenant si on a
Matrice(7x5) E; A=B+E;
on est dans la merde :-)
Dés qu'on s'éloigne des types atomiques (int, float, char) on se retrouve avec pleins de "cast" à programmer, et l'opérateur sera bcp trop surchargé.
Par exemple si je veux multiplier une matrice par un scalaire et multiplier 2 matrices entre elles j'aurais 2 surcharge de "*".
C'est un peu comme l'héritage :-) il ne faut pas en abuser, si on voit qu'on commence à avoir toutes les fonctions d'une classe qui sont des surcharges d'ipérateur, il est bcp plus clair pour la reprise de code ultérieure de les nomer clairement mul2matrices, mulscalmatrice, etc..
Autant une ligne de
cout toto << " " << titi << " " << tata;
est moins lisible | agréable à relire
à mon sens que
printf("%s %f.02 %c",toto,titi,tata); ou System.our.println(toto+" "+titi.toString()+" "+tata.toString());
Comme d'habitude, c'est plus une discussion sur les gouts et les couleurs qu'un réel avantage d'un type de programmation de l'un sur l'autre. :-)
Le plus important quand on programme c'est d'avoir un code consistant et de faire tout son application selon ses propres régles de programmation (si on est seul) mais de s'y tenir printf xor cout par ex, surcharger xor pas, fromage xor dessert :-)
D'ailleurs c'est marrant dans les gros projets, on peut savoir qui avait tappé tel ou tel bout de code selon son style :-)
[^] # Re: Surcharge d'opérateur
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
Et pour une classe string ou array par ex ? Avoir le '[]' ça t'aide pas ? Ou les "+" et "+=" pour concatener des strings ?
cout toto << " " << titi << " " << tata;
est moins lisible | agréable à relire
à mon sens que
printf("%s %f.02 %c",toto,titi,tata); ou System.our.println(toto+" "+titi.toString()+" "+tata.toString());
Oui mais note que le printf() est moin safe, parce qu'il n'y a pas de vérification sur le nombre ou le types des arguments passés après le string de controle (gcc -Wall aide un peu, mais en général non). Et le 2eme exemple que tu donnes utilise l'operateur overloading aussi, dans un certain sens :-).
[^] # Re: Surcharge d'opérateur
Posté par darkleon (site web personnel) . Évalué à 1.
Avoir le '[]' ça t'aide pas ? Ou les "+" et "+=" pour concatener des strings ?
Ben voilà y a plein de choses belles en théorie que je fais pas en pratique et vice-versa. :-)
le printf() est moin safe
Jamais dit le contraire, je parlais d'esthétisme de code a caractère purement subjectif :-)
En fait je programme perso en C et en Java au boulot, c'est pour cela que je n'utilise pas bcp le "cout", mais si j'utilise du C++ j'évite de faire du C like et utilise iostream au lieu de stdio.
tu donnes utilise l'operateur overloading aussi, dans un certain sens :-)
On chipotte là :-)
-1 car devient HS
[^] # Re: Surcharge d'opérateur
Posté par Pierre Tramo (site web personnel) . Évalué à 3.
Et oui, en java, on ne peut pas faire de l'operator overloading, SAUF pour les strings (et on aurait du mal à s'en passer). perso j'aime pas trop les langages conçus avec des "sauf".
System.our.println(toto+" "+titi.toString()+" "+tata.toString());
Avec l'opérateur "+", pas besoin de mettre des "toString()" partout justement (d'ailleurs quand tu veux passer un entier à une méthode qui veut une String, tu peux mettre ""+2, mais bon c'est plus pratique que joli), avec l'exemple, on obtient :
<code>System.out.println(toto+" "+titi+" "+tata);<code>
et à part mettre les variables directement dans la string à la shellscript, on peut difficilement faire plus clair.
[^] # Re: Surcharge d'opérateur
Posté par darkleon (site web personnel) . Évalué à 1.
<code>System.out.println(toto+" "+titi+" "+tata);<code>
Tout a fait d'accord, j'ai "forcé" le toString() pour simuler la syntaxe pour l'affichage d'un objet Complexe genre Matrice, liste chainée, affichage ascii d'un framebuffer QuakeIII pour jouer sur VT100 .... :-)
[^] # Re: Surcharge d'opérateur
Posté par reno . Évalué à 3.
<anecdote personelle> je me souviens d'un framework qui avait surchargé un opérateur et il y avait un bug dans la surcharge.. J'ai mis un temps dingue avant de comprendre pourquoi une partie du code tout ce qu'il y a de banal sortait n'importe quoi...</anecdote personelle>
Mais sinon cout vs printf, a mon avis la c'est plus une question d'habitude qu'autre chose..
Moi aussi je prefere le printf, mais je pense que c'est + lié au fait que j'ai plus l'habitude du C que du C++ qu'autre chose.
La plupart du temps dans printf on ne fait pas de format spécial alors cout marche tres bien et est plus court.
C'est le formatage d'argument avec cout qui est vraiment pas terrible..
De toute maniére je préfére le code ruby:
print "ca c'est une maniere elegante d'inclure une ${variable} dans une chaine\n";
[^] # Re: Surcharge d'opérateur
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
C'est le moins que l'on puisse dire. D'un coté c'est pratique pour les trucs simples (genre string + entier + string) parce que tu n'as pas à te soucier du typage, tu enfiles juste les '<<'. Mais dès que tu veux parametrer un peu l'affichage (genre des entiers en hexa ou une certaine précision sur les floats), ça devient très très moche.
De toute maniére je préfére le code ruby
Ah, toi aussi ? C'est définitivement le meilleur langage de script que je connaisse :-).
[^] # Re: Surcharge d'opérateur
Posté par Cédric Foll . Évalué à 1.
et
Ah, toi aussi ? C'est définitivement le meilleur langage de script que je connaisse :-).
C'est dingue, toutes les personnes qui connaissent Ruby disent ça !!!
Et pourtant c'est vraiment pas très répendu comme langage.
Il faudrait en parler plus sur tous les sites genre linuxfr. Je crois que je vais faire un peu chier les mongueurs avec Ruby dans un future proche ;-)
[^] # Re: Surcharge d'opérateur
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Non, c'est normal : Ruby est le meilleur langage de script actuellement. :-) Toutes les personnes à qui je l'ai montré le trouvent bien aussi.
Et pourtant c'est vraiment pas très répendu comme langage.
C'est en train de prendre de l'ampleur.
Il faudrait en parler plus sur tous les sites genre linuxfr.
Ou ré-écrire daCode en Ruby.
[^] # Re: Bof, pas d'accord avec lui.
Posté par darkleon (site web personnel) . Évalué à 10.
Ben justement la manipulation directe de la mémoire dans le code java sans passer par une librairie extérieure :-)
Tu peux pas te la jouer gros haxor en java en développant le driver de la dernière carte gfx à la mode qui tue de la mort 2 fois :-)
Evidemment, coder des drivers ce n'est pas forcement le truc interessant à faire pour tout le monde :-)
Reste que Java n'est pas du tout fait pour attaquer une machine physique sans API HAL (couche d'abstraction matérielle).***
Java peut tout faire sauf ce domaine trés restreint de la programmation bas niveau du matériel.
Maintenant ce n'est pas forcement ce qu'on lui demande non plus et il n'est pas fait pour ça, il y a le C et l'ASM qui sont bcp plus indiqués pour gagner quelques précieux cycles processeurs.
*** Evidemment je parles de la JVM standard de la JDK 1.3, par exemple dans le cas des puces hardware java qui traduisent à la volée en code ARM des instructions bytecode, je ne sais pas s'il est possible de manipuler directement les adresses mémoires physique (pas de JVM dans ce cas là).
[^] # Re: Bof, pas d'accord avec lui.
Posté par PAtrice Manac'h . Évalué à 3.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Johann Deneux . Évalué à 1.
A condition de passer par l'API de microsoft. Mais si on autorise les pointeurs, on peut écrire ce que l'on veut où l'on veut dans l'espace mémoire d'un processus. On peut donc également éxécuter ce que l'on veut. Les pointeurs sont vraiment trop dangereux pour être autorisés par les langages haut-niveau.
La seule façon d'éviter ça, c'est d'avoir un espace d'adressage par morceau de code. Ou d'utiliser un processus par morceau de code.
[^] # Re: Bof, pas d'accord avec lui.
Posté par Johann Deneux . Évalué à -2.
Voila qui m'apprendra à ne pas lire tous les commentaires avant de poster...
[^] # C# ne protège pas correctement les accès mémoires
Posté par Benoit Rousseau . Évalué à 1.
Si un programme fait des conneries avec la memoire qui lui est alloue ca ne pose pas trop de problemes...
[^] # Re: C# ne protège pas correctement les accès mémoires
Posté par Cédric Foll . Évalué à 8.
# moralité de SUN
Posté par Guillaume Lefevre . Évalué à 3.
et que leur java n'est pas libre. mais SUN c'est
aussi open office et ce n'est pas négligeable.
pis RMS il est gentil mais il a fait GNU emacs, effectivement le gosling il a fait la premiere
version d'emacs... (est-elle encore utilisée?)
pour ce qui est Gosling ca me viendrait pas a l'idée
de lui demander un autographe :-)
[^] # Re: moralité de SUN
Posté par Nicolas Roard (site web personnel) . Évalué à 8.
[^] # Re: moralité de SUN
Posté par Guillaume Lefevre . Évalué à 1.
ca
:-)
# java
Posté par Conrad . Évalué à -10.
Tout le monde parle tout le temps de java, les commentaires ici sont toujours abondant et pourtant j'aimerais bien savoir ou je peux en voir du java, parce que depuis les applets d'il y a 5 ans ou les applets de webcam et irc je voit rien !?
-1 pour engager le mouvement
[^] # Qques exemples ...
Posté par Nelis (site web personnel) . Évalué à 9.
JBuilder, IntelliJ, Forte, ...
Editeurs :
Jext, Jedit, ...
File sharing :
LimeWire
Jeux :
Roboforge, les 10000 applets (parfois bonnes, parfois moins)
....
Fais une petite recherche sur google, tu serais étonné de voir tout ce qui existe en Java
[^] # Re: Qques exemples ...
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
http://bea.com/products/index.shtml(...)
http://www.ilog.com/products/jviews/(...)
http://industry.java.sun.com/(...)
Bref, Conrad, sors un peu :-).
[^] # Re: Qques exemples ...
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: Qques exemples ...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Qques exemples ...
Posté par Nelis (site web personnel) . Évalué à 4.
[^] # Re: java -> exemple d'Oracle !?
Posté par kasi . Évalué à 1.
L'interêt d'Oracle : Ils ont fait un installeur universel, avec interface graphique, qui est succeptible d'installer leur produit sur les OS supportant JAVA.
M'enfin, c'est un peu chiant d'installer JAVA juste pour ça (quand on arrive a se dépetrer des versions etc...), une install a base de shell script m'aurait convenu ... ou bien apt-get install oracle-serveur ;-)
voilaaaa
c'était un exemple
[^] # Re: java -> exemple d'Oracle !?
Posté par PLuG . Évalué à 0.
a partir de la 8i Oracle devait intégrer java et la bdd. L'idee etait par exemple de stocker directement des morceaux de code java dans la bdd...
j'avoue m'etre arrete a la 8.0.5., mais si les plans pour le futur (8i et apres) on été respecté, installer oracle sans java c'est une hérésie non ?
[^] # Re: java -> exemple d'Oracle !?
Posté par kasi . Évalué à 2.
J'installe Oracle 8i client sur une Linux box, tout ça dans /oracle (mettons), OK.
j'installe une nouvelle box sans Java. Je transvase mon /oracle de ma machine 1 a ma machine 2. Je bidouille 2 lignes dans /etc/ld.so.conf (me rappel plus exactement). J'ajoute les variables d'environnements ORACLE_HOME, NLS_LANG, ... et /oracle/bin ds mon path et hop !
ça marche ! Oracle sans un goutte de Java !
[^] # Re: java -> exemple d'Oracle !?
Posté par darkleon (site web personnel) . Évalué à 3.
Par contre tous les outils annexes comme l'installeur, les terminaux de requête SQL, les outils d'administration, la création des formulaires graphiques Forms etc.. vont être migrés peut à peu en Java, pour Oracle, c'est l'utilisation de la maxime Write Once, Run Everywhere, ça leur évite de redevelopper ces outils en natif alors qu'ils n'ont pas besoin d'être super performant.
Avoir un temps de réaction de 2s au lieu d'1s sur l'affichage d'une requête sql à la "mano" tappée dans un terminal sql pour un developpement n'est pas trop grave.
Par contre gérer 10000 requête simultanées au lieu de 5000 est super important pour le moteur de la base de donnée (les chiffres sont débiles et pris au hasard).
[^] # Re: java
Posté par vrm (site web personnel) . Évalué à 2.
arkanae.tuxfamily.org
RPG 3D tout en java & opengl ...
[^] # Re: java
Posté par darkleon (site web personnel) . Évalué à 0.
Arkane, joli, mais 4-6 fps sur l'ordi ou je l'avais testé, mais c'est vrai qu'il n'était pas équipé d'une super carte gfx.
Néanmoins, je pense q'un équivalent (C|ASM)+(Opengl|DirectX) aurait pu tourner dans les 20~30 fps sur la même config.
Y a pas a chier, pour les jeux (C|ASM) rulez, même si ça n'enléve rien aux qualités d'Arkanaé, j'y jourais dans 4~5 ans quand j'aurais un 6ghz avec 2go :-)
</demi-troll>
[^] # Re: java
Posté par vrm (site web personnel) . Évalué à -3.
marche tres bien quand on configure ca carte 3D (moderne correctement ...
</neuneu>
[^] # Re: java
Posté par Jylam / jylam.lnxsce (site web personnel) . Évalué à -4.
Scuzez moi de foutre ma merde : (lu sur le site de arkanae)
Développé en Java, multiplateforme Linux et Windows
La je voie 2 plateformes. ca fait aps bcp pour du multiplateforme.
Develloper ca en C aurait ete aussi simple a porter, et aurait gagné 50fps.
Le java c'est bien pour ce faire un CV, mais c'est tout...
[^] # Re: java
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Vas-y, fais-moi voir un programme en C avec une GUI, tournant sur Unix et Windows, et dont le code soit "aussi simple" que du Java.
[^] # Re: java
Posté par Jylam / jylam.lnxsce (site web personnel) . Évalué à -1.
Et desolé, mais je trouve le C bien plus simple que le Java. Chacun son truc.
D'un autre coté, si tu prend tes yeux et que tu les posent sur mon post, tu verra ecrit "aussi simple a porter". A porter je lis moi. pas a ecrire.
[^] # Re: java
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Qt c'est du C++ (oui, y a les bindings C, mais pour utiliser ça directement faut vraiment être maso). Plus précisément, c'est une toolkit C++, donc un produit "en plus", et c'est eux qui se sont frappé pour toi tous les problèmes de portabilité.
D'un autre coté, si tu prend tes yeux et que tu les posent sur mon post, tu verra ecrit "aussi simple a porter". A porter je lis moi. pas a ecrire.
Ah. Parce que tu arrives à porter du code sans écrire du code supplémentaire, ni modifier le code existant. T'es 'achement doué toi :-).
[^] # Re: java
Posté par Versavel Jerome . Évalué à 3.
En java il est donc possible de "porter" une appli pratiquement sans réécrire de code.
[^] # Re: java
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
[^] # Re: java
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
[^] # Re: java
Posté par Versavel Jerome . Évalué à 2.
File toto = new File(getPath(),"titi\toto");
return toto.getName();
ne retourne pas la meme chose que
File toto = new File(getPath(),"titi/toto");
return toto.getName();
[^] # Re: java
Posté par vrm (site web personnel) . Évalué à 3.
et y a pas de code specifique...
[^] # D'autres exemples .... et bien plus ...
Posté par Jean-Baptiste Bugeaud . Évalué à 9.
Freenet : Un des projets les plus interessants de ces dernieres années ... http://freenet.sourceforge.net/(...)
JDiskReport : un outil d'analyse de disque vraiment pratique et trés ergonomique (compatible JNLP)
FreeNews : permet de disposer d'un forum NNTP entierement anonyme car utilisant Freenet (compatible JNLP)
Tejina : apprendre à écrire des idéogrames facilement (compatible JNLP)
JAP : un proxy pour anonymizer/tuneller ses connexions (compatible JNLP)
... plein d'autres applications JNLP / JavaWebStart sont disponible il suffit d'appeler google à l'aide...
Ou alors d'aller sur le *super-mega* site : http://www.up2go.net(...) ou sont listés -ô mirrracle - les meilleures applications JNLP disponibles ;-)
Sinon, recement c'est le marché de l'*embarqué* qui a pas mal bougé autour de J2ME surtout pour les telephones portables: http://www.microjava.com(...) Motorola, Siemens sont en europe les premiers à sortir des telephones déja dispo (accompli 008, s45/s45i, ...), plutot pratique de developper ces appli (les midlets) sous Netbeans ou JBuilder et de les voir fonctionner en live !
Et pour finir ze truc sympas :
SavaJe XE ( http://www.savaje.com(...) ), Un OS a recement fait bondir le Java One car ils ont reussit à faire tenir une plateforme J2SE (Swing, Corba, RMI, ... et meme compatible JNLP!!) sur un iPaq traditionel !!!
Ok, on pouvait mettre pocketlinux et la VM J2SE de blackdown mais pas sur 12M et avec de telles perfs quasi-supérieures au win CE ;-)
Dans ce cas c'est encore plus impressionant que J2ME puisque n'importe quelle appli J2SE (sous reserve de la place disponible) peut fonctionner dessus sans changement notoire (verifier juste que par defaut les palettes d'outils ne prennent pas tout l'ecran par exemple ...).
Bref, Java à bien changé depuis ses debuts et même si je pense qu'il n'est pas parfait les possibilités offertes aujourd'hui sont souvent sous-estimés car beaucoup se sont arrétés à l'apprentissage du langage sans entrevoir les capacités et la puissance de la plateforme.
De plus, il existe en Java deux approches qui cohexistent *paisiblement* : les logiciels libres et les logiciels comerciaux ...
Il est domage de ne pas voir plus de personnes sur linux s'investir également dans Java et par exemple contribuer à l'amélioration des VM blackdown ...
--
Allez hop, -1 pour l'auto-promo du site :o)
# Quel environnement de développement pour Java?
Posté par Cambien Cyril . Évalué à 4.
>> Cette interview est assez interessante aussi pour son point de vue sur les environnements de développement.
Question : Sur quels projets travaillez-vous actuellement pour Sun?
Gosling: Cela fait maintenant 10 ans que j'ai inventé le Java, c'est pourquoi j'ai décidé qu'il était temps de faire autre chose. Je suis donc retourné au laboratoire de recherche de Sun, où j'ai dernièrement travaillé sur un projet d'outil de développement. Aujourd'hui, presque plus personne ne crée d'environnements de développement intégré (IDE), d'autant qu'ils sont généralement destinés à des développeurs novices. Or peu d'outils adaptés sont à leur disposition, hormis Emacs. J'ai conçu la première version d'Emacs il y a 23 ans et je constate avec effroi que cet outil est toujours utilisé aujourd'hui tel qu'il était à l'origine. Est-ce là tout ce que l'on peut offrir de mieux à ces développeurs? Je ne crois pas.
>> Effectivement, en voulant "aider" trop les développeurs, les IDE classiques (comme Visual Age, JBuilder et autres) séduisent les novices, mais brident rapidement les développeurs au sein d'un carcan. A terme, les développeurs confirmés optent pour une collection d'outils modulaires, chacun les meilleurs dans leur catégorie, et les invoquent depuis un éditeur de texte. Le plus populaire est effectivement Emacs (c'est ce que j'utilise). Emacs est extensible et permet, avec JDE (Java Development Environment for Emacs, http://jdee.sunsite.dk/(...)) d'aider les programmeurs Java . En développement Java, Les outils intégrables dans Emacs les plus populaires sont ANT (automate de construction d'application, http://jakarta.apache.org/ant/(...)), JUnit (Tests Unitaires, http://junit.org/(...)), CVS (Gestion de sources, http://www.cvshome.org/(...)), Cruise Control (integration continue, http://cruisecontrol.sourceforge.net/(...)), XDocLet (Génération automatique de composants, http://sourceforge.net/projects/xdoclet/(...)). Toutefois le développeur reste libre d'étendre son environnement en fonction de ses besoins.
>> Il est assez amusant de constater que Gosling, l'inventeur de Java, est aussi l'inventeur de l'Emacs moderne, développé en C (dont il dispute la paternité avec Richard M. Stallmann, le chantre du logiciel libre, cf. http://www.jwz.org/doc/emacs-timeline.html(...)).
Gosling: Sun a fait l'acquisition d'un outil de développement appelé NetBeans, créé à la base pour servir de structure de conception. Il s'agit d'un système souple dont nous avons publié les codes source il y a un an et demi. Je travaille actuellement à la création d'un plug-in pour NetBeans.
>> Netbeans (www.netbeans.org) est un IDE moderne en ce sens qu'il est complètement extensible. Chacun peut faire évoluer NetBeans en développant des plug-ins. L'environnement commercial de Sun (Forte for Java) est basé sur NetBeans. Si quelqu'un comme Gosling travaille sur NetBeans, ça va être assez intéressant de surveiller ça...
Question : IBM a créé son propre projet open source, appelé Eclipse, afin d'intégrer des outils de développement Java. Les développeurs pourront ainsi choisir des outils provenant de différents éditeurs de logiciels, les assembler et les faire fonctionner ensemble. La plupart des concepteurs d'outils se sont joints au projet Eclipse, mais pas Sun, ce qu'a déploré IBM. Que se passe-t-il?
Gosling: NetBeans présente de nombreux points communs avec Eclipse. IBM pense que nous avons eu tort de ne pas nous joindre à son projet. Or on ne nous l'a même pas demandé. Nous n'en avons entendu parler que lorsqu'il a été annoncé. Eclipse ressemble à un produit dérivé, créé simplement pour faire la même chose que les autres. Sans parler de la campagne marketing, qui est vraiment étrange.
>> Eclipse, http://www.eclipse.org/,(...) reprend les mêmes principes que NetBeans. Pas étonnant que IBM na pas demandé à Sun de l'aider. Eclipse est intéressant et IBM tente d'en tirer le meilleur parti en terme de notoriété, mais il me semble un peu en retard sur NetBeans. La principale question est : quel est l'avenir à terme chez IBM des IDE vieux modèle comme Visual Age et Visual Studio face à Eclipse ? IBM s'auto-concurrence et ses clients peuvent être inquiet pour la pérennité de Visual Age...
Question : À terme, envisagez-vous une fusion entre ces deux projets open source?
Gosling: Ce n'est pas exclu. Certaines personnes y réfléchissent sans doute. C'est difficile de dire ce qu'il adviendra. L'essentiel est de définir un set commun d'API (interfaces de programmation d'applications), ce sur quoi nous travaillons depuis un an et demi. Nous aurions apprécié qu'IBM participe au projet open source que nous avons initié depuis longtemps déjà.
>> On peut regretter que IBM n'ai pas rejoint le projet NetBeans plutôt que de développer son propre truc, mais on peut comprendre que IBM n'ai pas envie d'aider SUN à faire son marketing...
>> Conclusion : Les IDE foisonnent chez les novices mais Emacs reste l'environnement fétiche des développeurs confirmés, même si c'est un outil ancien. Des IDE extensibles et ouverts, comme Emacs, mais plus modernes, restent à inventer. NetBeans et Eclipse sont d'intéressantes tentatives, mais doivent mûrir pour obtenir la reconnaissance dont Emacs jouit aujourd'hui...
Conclusion de la conclusion: Emacs Rulez! (ou VIM à la rigueur...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.