Naissance d'un géant : Java

Posté par  (site web personnel) . Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
64
8
juil.
2011
Java

Java est un des langages de programmation les plus auréolés de succès de ces quatre dernières décennies. Une grande partie des offres de postes de développeurs en France concerne Java.

D'après le « TIOBE Programming Community Index » Java est toujours leader avec 18,58 % des parts de marché en juin 2011. Il était bien plus haut en 2000, avoisinant les 30 %.

Mais comment Java en est arrivé là ? Cet article effectue un retour sur la période 1991–2000.

Sommaire

1 Un projet de Recherche et Développement pour l'embarqué

1.1 Conception du langage

C++ est un langage de programmation né en 1980. Au départ, il était conçu comme une amélioration du langage procédural C, dont il reprend les définitions. D'où son nom. C++ dispose de mécanismes de programmation orienté objet. Ce langage s'est énormément complexifié avec le temps, ajoutant régulièrement de nouvelles fonctionnalités, qui en font un langage très complexe, et complet (sa spécification fait 500 pages). Un des gros avantage de C++ est de proposer une orientation objet certes pauvre, mais très rapide comparé aux autres langages. Cet avantage était déterminant dans les années 1980 où la plupart des PC avaient la puissance d'une calculatrice scientifique d'aujourd'hui.

Java est né au sein des laboratoires de la société SUN Microsystems entre 1990 et 1995.

En 1990, Bill Joy, cofondateur de SUN, lance le projet Stealth, dont l'objectif est de développer un ensemble d'outils pour piloter des périphériques électroniques couramment utilisés par les consommateurs. Cette prise de conscience est parfaitement compréhensible à cette époque : les capacités technologique des fondeurs de microprocesseurs, et la baisse concomitante du prix des puces informatiques, permettaient d'envisager très sérieusement la possibilité de faire fonctionner un ordinateur certes très simple, mais efficace sur une carte électronique de 4 cm sur 4, avec des coûts de l'ordre de la dizaine d'euros.

Remplacer une carte électronique par un micro-ordinateur présente aussi l'avantage que seul le programme doit être réécrit si l'on veut changer le comportement de l'appareil électronique, au lieu de devoir re-dessiner le circuit. La première solution n'implique que peu de coûts dans la chaîne de production, tandis que la seconde est très lourde à gérer (modification du process de production, du support, etc.).

L'équipe du projet, bientôt rebaptisée lorsqu'elle est fut complété par James Gosling, Mike Sheradin, Patrick Naughton, se rend vite compte que le langage C++, qui devenait alors un standard dans l'industrie, est source de nombreux problèmes. Les lacunes de ce langage en terme de sécurité, de parallélisme, de gestion de la mémoire, et prise en compte de l'hétérogénéité des plates-formes électroniques devenaient très rapidement rédhibitoires. James Gosling, en charge de s'occuper de l'aspect langage du projet, commence à modifier C++ pour le rendre utilisable pour ses besoins. Le langage sera longtemps nommé "Oak" en raison de la présence d'un chêne en face de la fenêtre de James Gosling. Il fut changé quelques temps après lorsque ceux-ci découvrirent que le nom était déjà pris par une autre équipe quelques bureaux plus loin (il y avait de nombreux chênes autour des bureaux de SUN…). Après un passage dans le coffee shop jouxtant leur bureau, Java (argotique américain pour café) fut retenu après plusieurs heures de discussions.

Ceci illustre l'absence relative de réflexion marketing dans le choix du nom d'un futur succès planétaire.

L'obligation d'utiliser un langage de programmation produisant un code s'exécutant dans une machine virtuelle, s'est rapidement révélée nécessaire. En effet, on ne sait pas encore, et on savait encore moins à l'époque, compiler en code machine un programme en étant sûr de son fonctionnement correct. L'utilisation d'une machine virtuelle permet de limiter la casse. J. Gosling décida de supprimer de C++ toutes les constructions qui impliquent potentiellement des problèmes.

Une fois de plus, comme c'est le cas dans la conception de tous les langages à quelques rares exceptions près, Java a été conçu selon les désirs personnels de son concepteur, qui est avant tout un développeur qui veut se faire plaisir en programmant.

Au bout d'un an et demi, en août 1992, l'équipe présente leur premier prototype à l'équipe dirigeante de SUN (qui sont à la base des informaticiens de très haut niveau parfaitement à l'aise avec la technique).

Une télécommande universelle, aussi capable de contrôler l'ensemble des téléphones du bureau est présentée. Patrick Naughton déclara qu'en 18 mois, leur équipe de 6 personnes avaient réalisé un système d'exploitation, un langage, une interface utilisateur, une nouvelle plate-forme matérielle, ce qui aurait requis 75 personnes à une organisation utilisant les standards industriels de l'époque. Parallèlement à ce projet, une équipe de Sun, constituée par Ole Agesen et Craig Chambers conçoivent et implémentent le premier langage objet à prototype, Self. Self pose des problème de compilations et d'exécution assez ardus, le langage de programmation est très puissant mais difficile à exécuter avec des performances acceptables, le rendant inutilisable dans l'industrie. Self implique néanmoins énormément de recherche sur les machines virtuelles et leur efficacité. Java reprend très vite les travaux de Self sur cette machine virtuelle, sans pousser celle-ci dans ses derniers retranchements, Java étant un langage beaucoup plus frustre que Self.

1.2 Des débuts difficiles

En novembre 1992, Sun commence à marqueter son produit afin de le vendre à des entreprises souhaitant développer des équipements électroniques sophistiqués.

Durant 3 ans, Sun essuiera divers échecs en tentant par exemple de vendre son produit à Time-Warner pour un projet console de TV à la demande, ou d'une console multimédia pour 3DO. Devant ces revers, Sun décide de dissoudre l'équipe du projet.

1.3 Le web sauve le langage

Les divers membres de l'ancienne équipe, encore hantés par leur jouet technologique, tentent encore de trouver une application à leur projet. Patrick Naughton, s'« amusant » lors d'un week-end à programmer un navigateur web, a l'idée d'y incorporer le langage Java et son infrastructure. Le World Wide Web, par nature, a des exigences telles que la fiabilité, la sécurité et l'indépendance d'architecture qui correspondaient grandement avec les principes de conception de Java et son infrastructure. En effet, se connecter sur Internet revient à ouvrir ses portes et ses fenêtres. Les utilisateurs de Windows le subissent encore, avec de récurrents problèmes de virus..

En Septembre 1994, Naughton et Jonathan Payne (un ingénieur de Sun) commencent à écrire « WebRunner », un navigateur web basé sur Java qui a été rebaptisé « HotJava ». En octobre 1994, HotJava est stable et est présenté aux dirigeants de Sun. Cette fois-ci, le potentiel de Java, est reconnu dans le cadre du World Wide Web et le projet est soutenu.

Bien qu'il soit conçu avec un objectif différent, Java a trouvé une niche parfaite avec le World Wide Web. Sun a officiellement annoncé Java et HotJava à la conférence SunWorld 1995. Peu de temps après, Netscape Inc. a annoncé qu'il allait intégrer la gestion de Java dans le navigateur. Java est d'un grand intérêt car il est sécurisé, contrairement à C++ : Java isole les programmes les uns des autres afin qu'il n'y ait aucune interférence possible.

Le World Wide Web est alors le nouveau sujet d'enthousiasme des fans de technologies aux États-Unis. Il trouve en outre un franc soutien du vice-président Al Gore pour lequel Internet était une priorité depuis de nombreuses années.

2 La conquête

2.1 1993-2000, un environnement en pleine mutation

2.1.1 Internet s'installe dans le paysage

En 1995, la plupart des gens ont utilisé Internet pour partager des documents statiques comme des documents word, des pages HTML, etc.

Les serveurs Web balbutiant étaient la plupart du temps un bricolage fait de bric et de broc, les serveurs professionnels comme Apache ou Nginx n'étaient pas encore disponibles.
Pour la plupart, les sites web étaient construit avec des scripts CGI écrits en Perl. On utilisait un script bash pour lancer le script à chaque connexion au serveur (le script bash utilisait xinetd pour écouter le port 80). De cette façon, le serveur passait très mal à l'échelle.

Pour l'informatique d'entreprise, l'Internet avait la réputation d'un jouet, limité en dehors des milieux scientifiques et universitaires.

Dans le grand public, Microsoft a longtemps snobé l'Internet, mais beaucoup d'esprits les plus brillants ont cherché des moyens de combiner les forces des acteurs autres que Microsoft, tout en affaiblissant la menace dominante qui imposait chaque jour un peu plus son monopole. Les leaders du marché s'efforçaient toujours de protéger leurs bases installées par le biais de produits exclusifs et de cadriciels.

IBM, qui avait construit un empire sur des modèles exclusifs incluant matériel, logiciel et services, a tout à coup dû faire volte-face pour éviter une mort certaine suite à la prise de pouvoir rapide de Microsoft. IBM est ainsi passé d'un modèle ultra propriétaire à une stratégie englobant toutes les normes et standards qu'il pouvait trouver. IBM a ainsi assis sa survie sur la progression de ce réseau des réseau très prometteurs et sur sa nouvelle offre de service autour de l'Internet, visant à expliquer puis mettre en place la communication des systèmes d'informations des entreprises entre eux, qui étaient alors souvent cloisonnés par site de production.

Netscape Inc s'est en même temps fait connaître avec un navigateur web devenu rapidement populaire, la mode des sites web s'étant propagée dès le début des années 1990 dans les milieux scientifique qui s'en emparèrent très vite.

Ce que l'on appelle aujourd'hui le web 2.0 – permettant de bénéficier d'interfaces utilisateur riches et dynamiques sur nos navigateurs – n'était même pas encore dans les cartons. Le navigateur était formidable pour voyager sur le réseau, mais l'interface encore très frustre, car à la base conçue pour présenter des documents statiques contenant seulement du texte, quelques images et des liens vers d'autres pages.

Pour des utilisateurs habitués à des interfaces plus riches, il n'y avait aucune solution possible. En intégrant Java dans le navigateur, la possibilité s'offrait de créer des applications plus complexes, s'exécutant sur l'ordinateur de l'utilisateur, et lui offrant une interface riche comme il en avait l'habitude. Tout cela, en restant dans le cadre d'un Internet sécurisé.

En outre, le langage Java ayant été conçu pour les périphériques « embarqués », de nombreux téléphones nouvellement numériques étaient pilotables grâce au langage Java. Cette possibilité a été une porte d'entrée formidable pour le langage dans un contexte ou de vastes centres d'appels téléphonique se créaient. Grâce à la possibilité d'utiliser Java sur le téléphone et le navigateur, l'opératrice pouvait avoir automatiquement des informations sur un client dès que celui-ci appelait.

2.1.2 La programmation orienté objet s'impose dans le monde du développement de logiciels

La POO a le potentiel d'être beaucoup moins complexe que la programmation procédurale, car plus proche de l'expérience humaine qui manipule des objets dans sa vie quotidienne, mais cette approche nécessite du temps pour former les compétences nécessaires à son utilisation. Par conséquent, il a fallu quelques années à l'industrie pour mettre en place les structures permettant de former des développeurs compétents en la matière. En outre, il a fallu au moins une décennie afin que les ingénieurs soient suffisamment experts dans le domaine pour être capable d'être une voie de recours en cas de problème.

Microsoft a de fait imposé la programmation objet pour son environnement Microsoft Windows, rendant nécessaire l'utilisation du langage C++. C++ avait de gros défauts : différentes versions du compilateur produisaient des binaires incompatibles, ce qui posait énormément de problèmes aux développeurs qui découvraient que leur application rentrait en conflit sur certains postes clients, du fait d'un ensemble de DLL différentes sur chaque poste. On appelait cela le « DLL Hell ». Le système des DLL de Microsoft ne possédait aucun système de gestion de dépendances, comme on en a sur les systèmes GNU/Linux, il en devenait hasardeux qu'un programme fonctionne. Ne parlons même pas des programmes qui installaient une version des DLL, écrasant une version présente et rendant incompatibles certains logiciels existants.

C++ est tout sauf un langage orthogonal. Peut être un peu si on se restreint aux Templating, mais on peut vite faire n'importe quoi avec ce langage.

2.1.3 Java s'impose face à C++

Java s'était justement construit pour contourner cette complexité inhérente au C++. En reprenant de très près la syntaxe de son prédécesseur, tout en corrigeant nombre de ses défauts, Java a très vite plu à de nombreux développeurs qui maîtrisaient C++ tout en supportant difficilement les difficultés inhérentes au vieux langage.

Son intégration dans le navigateur a été déterminante : en effet, les fans de technologies se sont bien évidemment jetés sur Internet, qui était modique aux États-Unis du fait de la gratuité des appels téléphoniques locaux (Internet à ses début fonctionnait avec un modem qui appelait un numéro de téléphone local).

En outre, Java apporte une grande sécurité de fonctionnement : son architecture à base de Sandbox permet d'isoler les processus, contrairement à C++ où un débordement de pile est courant (le fait que Microsoft Windows soit programmé en C++ est la principale cause de sa porosité aux virus informatiques).

Un ordinateur connecté à Internet doit être protégé, ce sont des données potentiellement stratégiques de l'entreprise qui sont en jeu. À l'heure d'Internet, C++ faisait très peur aux DSI pour cette raison précise. En matraquant sur le thème de la sécurité, Sun a séduit nombre de décideurs à faire migrer leur application sur un navigateur.

2.1.4 Le Serveur d'Application, la nouvelle coqueluche des entreprises

Internet ayant bénéficié d'un engouement médiatique sans précédent entre 1997 et 2000, en particulier aux États-Unis, les entreprises se tournent de plus en plus vers le réseau.

La baisse drastique du coût du matériel de communication entre ordinateur, l'investissement massif pour la mise en place d'infrastructures réseaux à très haut débit pousse les entreprises américaines à mettre en réseau leur système d'information. De même, avec la bulle des dot com, les sites de commerces électroniques se multiplient comme des petits pains, il leur faut des serveurs web, capables de supporter le trafic généré.

Le modèle du « client lourd » non connecté au réseau a vécu.

Les DSI des entreprises veulent des applications connectées entre elles, afin de pouvoir améliorer leur connaissance du fonctionnement de l'entreprise, d'identifier des éventuels centres de coûts à améliorer, etc.

Ce sera donc le modèle du Serveur d'Application qui s'impose peu à peu de 1998 à 2002 : on installe sur un serveur l'application métier, ce serveur (ou un autre auquel il est étroitement connecté) héberge les données de l'entreprise issus des informations saisies par les employés. Par définition, ces informations sont sensibles, il est plus sûr qu'elles restent sur le serveur et ne se promène pas sur les postes clients.

Sur le PC, Personal Computer ou Poste Client, on utilise une application qui se connecte au serveur. C'est là que le navigateur entre en jeu. En effet le navigateur, Netscape à l'époque, fonctionne sur diverses plates-formes, est peu sensible aux différentes version de Windows, et ne souffre en particulier pas du problème du « DLL Hell » de ce système.

On écrit donc une application afin qu'elle tourne sur Netscape. Pour bénéficier d'application un tant soit peu proche de ce que les utilisateurs ont l'habitude de manipuler sur leur PC, on y adjoint quelques morceaux de logiciel en Java.

Java s'impose donc en entreprise par le navigateur.

2.1.5 Sun abat ses cartes

C'est alors que Sun saisit l'opportunité qui se pointe à l'horizon. Sun vend des serveurs d'entreprise, l'entreprise est même largement dominante sur ce secteur, surpassant IBM décidément bien mal en point.

Sun va donc vendre le logiciel qui animera ces serveurs, et il sera basé sur Java.

Rapidement, Sun développe un cadriciel qui sera un des premiers serveurs d'applications réellement fonctionnel, « Java Enterprise Edition ». C'est un serveur Web, conçu pour développer des application d'entreprise selon un cadre très structuré. En face, C++ ne possédait aucun cadriciel capable de rivaliser, et de loin.

JEE permet d'offrir à ses utilisateurs une grande sécurité pour les données qui transitent par le réseau. JEE offrait de plus tout un ensemble de bibliothèques (appelées API pour Application Programming Interface) prévues pour permettre à l'utilisateur de ne se concentrer que sur la logique métier du logiciel en construction.

Pour concevoir, réaliser et mettre en cohérence ces bibliothèques, Sun a réalisé une étude profonde des logiciels client/serveur de l'époque afin de proposer un ensemble de services qui devaient être réécrits à chaque fois dans les logiciels réalisés à l'époque.

JEE basé sur les EJB - Enterprise Java Bean - dont la presse ne cesse de proclamer qu'il s'agit du futur du développement : les EJB sont des « composants », des objets, permettant de décrire des objets importants pour une entreprise : Client, prospect, employé, facture, chaque concept que l'entreprise manipule a son EJB.

Par nature, cet EJB est censé être réutilisable ad vitam æternam. Mais il faudra dix ans à l'industrie du logiciel pour se rendre compte que c'était une chimère.

La presse spécialisé ne parle que de ça : j'ai réalisé une étude sur les 45 articles consacrés aux développements (au sens large) dans l'hebdomadaire 01Informatique pour l'année 2000. 01Informatique est le magazine de référence pour les décideurs en informatique, il est davantage orienté business que technique. 20 articles sont consacrés à Java, et 9 aux EJB. De même, 15 articles traitent des Serveurs d'Applications. Les autres articles parlent de divers sujets, sans uniformité particulière. On observe donc un engouement autour de Java et de ses technologies associées.

La presse a grandement aidé à faire penser aux décideurs que Java/JEE était l'avenir et le futur leader.

2.2 Conclusion

Java a bénéficié d'un ensemble de circonstance sans précédent, menant à sa domination effective depuis 10 ans, même si celle-ci s'effrite peu à peu.

En cinq ans, Java s'est imposé à presque 30% de part de marché, qui restera dans l'histoire une progression unique.

Le succès de Java entre 1995 et 2000 est le croisement de facteurs environnementaux et intrinsèques au langage et aux choix stratégiques de Sun.

Facteurs environnementaux :

  • progression forte de l'audience du navigateur internet, car grande facilité de mise en place d'architectures « serveur -> ordinateur personnel » (aussi appelée « client-serveur ») via ce média ;
  • doute quant à la pertinence de l'utilisation de C++ comme langage dominant, intérêt pour un langage qui reprend les avantages de C++ en éliminant ses inconvénients (cohérence, sécurité) ;
  • un langage qui a simplifié la programmation orientée objet, perçue comme trop complexe, tout en gardant une syntaxe ne nécessitant quasiment aucune adaptation pour le développeur C++.

Sun a aussi su habilement surfer sur la popularité soudaine de son langage… et comprendre très rapidement l'importance de le soutenir. Par exemple en usant de son image d'entreprise de Haute technologie fournissant du matériel de très grande qualité. Sun était en cette période un leader des serveurs d'entreprise.

Ainsi Sun a dans cette période fourni plusieurs efforts :

  • soutien marketing sans faille à l'engouement autour d'Internet, des Serveurs d'Applications et des EJB. Les Entreprise Java Bean ont été présenté comme LA solution à l'industrie logicielle, qui souffrait de devoir réécrire sa logique métier dans chaque implémentation. Les EJB étaient censées être réutilisables un peu partout dans le Système d'Information de l'entreprise ;
  • intégration de Java au navigateur, présenté (à raison) comme la seule technologie permettant de réaliser les prémisses de ce que l'on attend aujourd'hui du « Web 2.0 ». Sun a su maintenir un partenariat étroit avec Netscape Inc qui produisait le navigateur ultra-majoritaire du même nom ;
  • soutien juridique acharné et sans faille dans un environnement où Microsoft était prêt à tout pour empêcher qu'un langage non maîtrisé par lui-même puisse s'imposer sur son système Windows ;
  • un travail profond d'analyse des besoins du marché, avec la définition de la spécification Java Enterprise Edition. Cette analyse était remarquable dans le sens où Sun a su analyser les besoins des entreprises dans les cinq années suivantes.

Le succès du langage Java est donc la concomitance de grands changements environnementaux, de qualité intrinsèque du langage lui permettant de séduire une frange non négligeable de développeurs et de la pertinence des analyses et actions de l'entreprise Sun entre 1995 et 2002.

Malgré une baisse régulière de son influence, Java a un poids extrêmement important sur le marché de l'emploi : en France environ la moitié des offres de travail en développement concerne Java.

Aller plus loin

  • # Oracle éclipse le travail de Sun

    Posté par  (site web personnel) . Évalué à 10.

    Vivement la suite!

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re:

      Posté par  . Évalué à 10.

      Le problème, c'est qu'il est tellement aisé de coder salement en Java que manifestement la majorité des développeurs le font.

      • [^] # Re:

        Posté par  . Évalué à -5.

        Java c'est quand même plus propre que Python ...

        • [^] # Re:

          Posté par  . Évalué à 5.

          prouve-le!

          • [^] # Re:

            Posté par  . Évalué à 5.

            Même pour un vendredi c'était trop gros ...
            J'aurai essayé

            • [^] # Re:

              Posté par  (site web personnel) . Évalué à 4.

              Ra ben non, abandonner à la première contrariété, c'est pas digne d'un vendredi.

              1. d'autres continuent ici
              2. trop gros ça n'existe pas un vendredi ;-)

              • [^] # Re:

                Posté par  . Évalué à 2.

                nan, faut pas abuser, une seule réponse d'une ligne c'est mort. des trol java/Python y'en aura d'autre.

                Quand ca prend pas faut savoir rester humble, j'aurai du développer un peu plus peu être.
                Pour les experts en troll il faudrait faire un wiki pour savoir comment lancer un bon troll. moi apparemment j'ai pas trouvé le truc.

                • [^] # Du lancer de trolls

                  Posté par  . Évalué à 10. Dernière modification le 15 juillet 2011 à 04:38.

                  Déjà, un commentaire, tu joues dans la catégorie amateur
                  Et en une seule ligne, tu ne te donnes pas toutes les chances.

                  Maintenant, les pros ne font même plus des journaux, mais carrément des dépêches.

                  Bien entendu, il faut faire un article très fouillé pour faire sérieux.

                  Par exemple une dépêche sur l’histoire passionnante du meilleur langage du monde, où tu choisis bien sûr le plus controversé :

                  - déjà les langages de programmation, c’est un sujet de passion ;
                  - il y a plein de gens qui détestent Java et les langages qu’ils aiment sont souvent détestés par les programmeurs Java ;
                  - ça peut aussi dévier sur les performances : des gens qui vont te citer des benchmarks ou Java explose tout et d’autres des logiciels en Java qui sont de vrais usines à gaz ;
                  - tu as aussi une chance que ça parte sur « Java ça pue, c’est pas libre », d’ailleurs, tu aurais dû lancer ce sous-troll-là, il a généralement du succès ;
                  - et puis Java a été racheté par Oracle (Oh désespoir !).

                  C’est un fort beau choix de sujet et qui a atteint en peu de temps un assez joli (162 commentaires au moment où je commence à écrire), mais pour l’instant seul l’aspect langage a pris, ce qui est un peu décevant.

                  Sinon, le plus talentueux d’entre-nous a placé la barre encore beaucoup plus haut : plutôt que d’écrire un simple article, interroger le développeur le plus controversé du monde Linux ! C’est carrément grandiose !
                  Au score pur, je ne sais pas si le troll Java a des chances de le rattraper, mais pour la note artistique, patrick_g fixe un nouveau pallier, loin devant tous les autres.

                  Cependant, le choix risqué de la date (mardi pour que ça n'ait pas l’air d’un troll) ne paye peut-être pas autant que de rester classique en jouant le vendredi.

                  Mais là, nous pauvres amateurs, nous ne pouvons plus nous aligner. Pour les compétitions, il va falloir différencier la catégorie amateur de la catégorie pro.

                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                  • [^] # orthographefr.org

                    Posté par  . Évalué à 1.

                    J’aurais dû me relire une fois de plus :

                    C’est un fort beau choix de sujet et qui a atteint en peu de temps un assez joli score

                    (mardi pour que ça n’est aie pas l’air d’un troll)

                    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                    • [^] # Re: orthographefr.org

                      Posté par  . Évalué à 1.

                      Je vais pas y arriver !

                      (mardi pour que ça n’est aie ait pas l’air d’un troll)

                      Il était temps que les vacances arrivent...

                      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                  • [^] # Re: Du lancer de trolls

                    Posté par  . Évalué à 7.

                    Au score pur, je ne sais pas si le troll Java a des chances de le rattraper, mais pour la note artistique, patrick_g fixe un nouveau palier, loin devant tous les autres.

                    Les depeches de Patrick sont generalement bien relues et ne contiennent pas de grosses conneries, alors que la...

                    Meme si on ignore les quelques endroits ou c'est de l'opinion pour troller, il y a plein de trucs soit completement faux, soit qui reecrivent l'histoire. Ayant deja lu plusieurs journaux de l'auteur, je me rappelle pas avoir vu autant de conneries, ca restait technique et pas trop trollesque. C'est donc visiblement fait expres.

                    Le plus inquietant:
                    - c'est qu'un torchon comme ca passe la moderation (avec des grosses betises techniques), juste parce que c'est long et que ca a l'ai bien renseigne
                    - que l'auteur soit totalement absent des commentaires (trop fatigue par la longue redaction ou bien il est parti en weekend?), on voit qu'il assume a fond. Quel courage!

                    • [^] # Re: Du lancer de trolls

                      Posté par  . Évalué à 7.

                      Les depeches de Patrick sont generalement bien relues et ne contiennent pas de grosses conneries, alors que la...

                      Tout-à-fait, même dans son troll, Patrick G. n’a dit aucune connerie : c’est Lennart Poettering qui l’a fait !

                      C’est là le génie. En plus, l’intérêt de l’article reste indéniable, puisque les opinions — même trollesques — de quelqu’un qui a de l’importance dans l’évolution des distributions Linux sont intéressantes à connaître. De l’art !

                      À côté, ce troll sur Java est franchement grossier...

                      Le plus inquietant:
                      - c'est qu'un torchon comme ca passe la moderation (avec des grosses betises techniques), juste parce que c'est long et que ca a l'ai bien renseigne

                      Patrick G. (c’est lui qui l’a modéré) a sûrement voulu être fair play avec son adversaire.

                      La solution, c’est d’assumer en renommant le site trollfr.org.

                      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

              • [^] # Re:

                Posté par  (site web personnel) . Évalué à 10.

                trop gros ça n'existe pas un vendredi ;-)

                C'est pas ce qu'elle me disait hier…

    • [^] # porosité aux virus

      Posté par  . Évalué à 6.

      Oui, j'aimerais bien comprendre ce point.
      L'auteur parle beaucoup de la plus grande sécurité (au sens large) de Java face a C++, mais c'est la première fois que j'en entends parler. Je ne developpe ni dans l'un, ni dans l'autre.
      Pour moi, les avantages de Java sur C++ sont, en gros, une syntaxe plus facile, et une VM qui se charge des fuites mémoires et facilite la portabilité. C'est quoi cette histoire de sécurité ?

      • [^] # Re: porosité aux virus

        Posté par  . Évalué à 7.

        Déjà en Java (sauf quelques cas très peu problable), les buffers overflow ne sont pas possible par exemple.

        • [^] # Re: porosité aux virus

          Posté par  (site web personnel) . Évalué à 6. Dernière modification le 08 juillet 2011 à 23:23.

          en revanche, le garbage collector qui se déclenche pour soudainement libérer 300 Mo voire plus, c'est sympa pour freezer temporairement une application web (j'ai un exemple en tête corrigé depuis heureusement, pas très bien développée et omettant de libérer des connexions à la base de données par exemple, alors qu'il aurait été si simple d'avoir un pool de connexion bien géré dès le début...).

          • [^] # Re: porosité aux virus

            Posté par  (site web personnel) . Évalué à 3.

            C'est dans ses moments-là, ou il est marrant de constater que diminuer la mémoire dédiés par la VM peut augmenter les performances en rapprochant le déclenchement du GC.

            "La première sécurité est la liberté"

            • [^] # Re: porosité aux virus

              Posté par  . Évalué à 5.

              Dans ces moments là tu peux aussi découvrir qu'un GC ça se configure très finement en fonction de ce que fait l'application ;) Par exemple -XX:CMSInitiatingOccupancyFraction=X peut t'aider parmi d'autres.

              Tu peux regarder là pour un exemple sur un projet de comment configurer son GC et développer en essayant de minimiser le boulot du GC: http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/

              Après ça reste un GC, donc même en utilisant G1 ça reste difficile d'avoir des temps de réponse constant, voir les problèmes et le boulot des gens d'OpenDS.

      • [^] # Re: porosité aux virus

        Posté par  (site web personnel) . Évalué à 8.

        C'est en effet une partie bien trollesque que j'avais repéré aussi.
        Java est certainement plus sûr, parce qu'il faut le vouloir pour laisser un buffer overflow dedans. Mais il introduit de nouvelles possibilités de failles propres à java, tout en prenant compte que la VM et les libs sont elles aussi ecrites en C++.

        Ce qui a fait de windows un OS mal sécurisé, ce sont surtout des problèmes de design et d'implémentation, datant d'un temps où la sécurité ne comptait pas autant qu'aujourd'hui pour la conception d'un OS, pas le langage en lui-même.

        • [^] # Re: porosité aux virus

          Posté par  . Évalué à 6.

          pour windows 95, c'est sur

          pour la génération NT, c'est surtout les utilisateurs qui utilisaient tous le compte administrateur, et le manque d'un minimum de comportement suspect par rapport à l'extérieur (et que je t'execute n'importe quel application), qui est la principale cause de propagation des virus. L'OS n'est pas moins protégé (biensur, il y a toujours les trou de sécurité dans certains composant, internet explorer, outlook, etc, qui ont été exploité, mais c'est aussi le cas de beaucoup d'autre logiciel.

          • [^] # Re: porosité aux virus

            Posté par  . Évalué à 6.

            pour la génération NT, c'est surtout les utilisateurs qui utilisaient tous le compte administrateur,

            On peut aussi dire que par défaut Windows te plaçait sous un compte administrateur (c'était le premier compte) et c'est en créant un nouveau compte que tu avait la possibilité d'avoir un utilisateur "simple" (qui dans le même coup n'avait pas le droit de lancer des application mal écrites). Bref c'est le serpent qui se mord la queue, mais on remarque que c'est en changeant la conception coté OS qu'ils ont résolue ce problème (plutôt que de continuer dans leur lancé en affirmant que les utilisateurs et les développeurs sont des blaireaux).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: porosité aux virus

              Posté par  (site web personnel) . Évalué à 0.

              Il n'y a pas que cela comme erreur dans Windows :

              • programmation en variable globale -> base de registre

              • base de registre tout mélangé (paramètre de configuration, autres paramètres)

              A noter que les approches modernes de GNU/Linux ne me plaisent pas toujours. Menu global, DBUS de partout, propagation instantanée de la configuration, onglet dans les applications...

              Le concept de programme père fils avec des variables d'environnement héritable ne fait pas tout mais on prends en ce moment la direction carrément opposé. Qui sais par exemple comment utiliser la commande newgroup dans ce genre d'environnement ?

        • [^] # Re: porosité aux virus

          Posté par  (site web personnel) . Évalué à 1.

          Ce qui a fait de windows un OS mal sécurisé, ce sont surtout des problèmes de design et d'implémentation, datant d'un temps où la sécurité ne comptait pas autant qu'aujourd'hui pour la conception d'un OS, pas le langage en lui-même.

          Une partie des stratégies de sécurité est supportée par le processeur, notamment la distinction des modes noyau et utilisateur qui empêche un processus utilisateur de planter la machine ou de prendre son controôle. Dans le monde intel et PCs, cette distinction est arrivée en 1985 avec le 80386 mais existait déjà dans la micro-informatique personnelle avec les Motorola 68000 (produit depuis 1979) équipant les Amiga. Ce qui a fait de Windows un OS mal sécurisé c'est à mon avis plutôt l'héritage monothread de MS-Dos et probablement une absence de compétence en la matière dans la boîte, le choix de garder pendant longtemps un système FAT, etc.

          • [^] # Re: porosité aux virus

            Posté par  . Évalué à 6.

            Hum....le 68000 n'a jamais eu de gestionnaire de mémoire paginée...il a a fallut attendre le 68020 auquel il fallait ajouter un 68851 ou attendre le 68030 pour que cela soit intègre au boitier, donc la même génération que le 80386....quand a comparer le noyau NT comme un héritage de ms-dos, c'est méconnaitre l'histoire....

            • [^] # Re: porosité aux virus

              Posté par  . Évalué à 2.

              Peut etre qu'il pensait aux modes superviseur/user du 68000 ? Mais on reste éloigné de la sécurité apporté par une MMU

              • [^] # Re: porosité aux virus

                Posté par  (site web personnel) . Évalué à 2.

                Peut etre qu'il pensait aux modes superviseur/user du 68000 ?

                Oui:

                notamment la distinction des modes noyau et utilisateur

                mais c'est vrai que je ne me suis pas très bien exprimé.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 10.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: porosité aux virus

          Posté par  . Évalué à 3.

          alors que ce seraient des buses sans nom des qu'ils passeraient au C.

          alors qu'ils passeraient un temps fou dans Valgrind dès qu'il passeraient au C.

          • [^] # Re: porosité aux virus

            Posté par  . Évalué à 3.

            Quelque soit son plumage, une buse reste une buse.

            Blague à part, quelqu'un de sensibilisé à la gestion de la mémoire s'en sortira mieux qu'une personne ne l'étant pas. Ce n'est donc qu'une histoire d'éducation.

            Merci de m'avoir lu, vous pouvez reprendre le troll :-)

      • [^] # Re: porosité aux virus

        Posté par  (site web personnel) . Évalué à 4.

        Comme indiqué précédemment, un des élément rendant un programme Java moins "dangereux" est la gestion automatique de la mémoire : pas de débordement de tampon possible. Evidemment rien n'empêche un bug dans la JVM, mais les bugs dans le programme de Geek@SSII23 est beaucoup plus probable ;)

        Mais il y a bien d'autres aspects, un bon article sur la sécurité dans les JVM/.NET :
        http://www.dotnetguru.org/articles/securite/Partie1/Securite.html

      • [^] # Re: porosité aux virus

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        C'est quoi cette histoire de sécurité ?

        Sa lenteur intrinsèque fait qu'il est beaucoup plus résistant aux DDOS.

        Oui, bon, je sais : -> []

  • # Franchement...

    Posté par  (site web personnel) . Évalué à 1.

    Avant 2005-2007 je ne conseillais pas d'utiliser java. Implémentation non cohérente, bug à la pelle, pas très performante sur certains traitements, JVMs non-compatible,... J'aime toujours pas java mais maintenant je reconnais qu'aujourd'hui c'est une bonne solution pérenne dans le temps.

  • # Ahem...

    Posté par  (Mastodon) . Évalué à 9.

    Une grande partie des offres de postes de développeurs en France concerne Java.

    Un petit doigt (qui souhaite rester anonyme) m'a dit que c'était juste la conséquence d'un turnover de furieux. Aucun être humain ne pourrait suivre la furie des gros projets Java plus de quelques mois. Au delà de six mille classes, le cerveau ne peut plus suivre. la pression de la hiérarchie s'accentue, le projet prend du retard, même le serveur de test est à la ramasse, mais tout va bien. Java est portable, Java est à la pointe : c'est évident, regardez tout ce buzz recrutement pour des dèvz Java. Tout va bien.

    D'un autre coté, pour une entreprise en difficulté, le meilleur moyen d'impressionner, de sembler pertinente, c'est juste de faire semblant de recruter. C'est facile, c'est pas cher, mais ça rapporte quand même. Un peu, de moins en moins...

    Et pendant ce temps-là, à Fukuschima...

    • [^] # Re: Ahem...

      Posté par  . Évalué à 6.

      Au delà de six mille classes, le cerveau ne peut plus suivre. la pression de la hiérarchie s'accentue, le projet prend du retard, même le serveur de test est à la ramasse, mais tout va bien.

      C'est pas spécifique à Java, c'est tout les gros projets en entreprise.

      Dès que tu as une organisation de papa dinosaure derrière, c'est foutu, non ?

  • # Chacun son style

    Posté par  . Évalué à 9.

    La compétence du dev fait toujours la différence, qu'il code en Java ou en C++. La différence c'est qu'en Java on peut faire quelque chose "qui marche" sans risquer d'aller écrire dans la zone mémoire du voisin, même en codant (trop) salement. Donc ça rassure ceux qui emploient des stagiaires, dont je suis encore, de savoir que même si ils codent salement, ce qui est souvent le cas, avec Java il y a peu de risque qu'ils flinguent les serveurs du client.
    C++ demande une formation solide et une bonne compréhension pour arriver à l'utiliser correctement, avec Java une formation de quelques semaines suffit.
    L'avenir du langage va se décider avec le Cloud, et là Java a du boulot et des concurrents sérieux : il faut gérer le parallélisme massif (plusieurs centaines, voir millier) de threads de en quelques lignes de code. La concurrence est rude sur ce point. Scala (qui repose sur une JVM) est très intéressant pour cela, Go aussi. J'ai entendu parler de certaines choses dans Ruby aussi. Côté C#/.NET, que je connais peu, je n'entend rien arriver.
    Après il y a quelques framework, comme Akka, qui apportent leurs fonctionnalités à des langages existants.
    Ce qui est certain, c'est que là où Internet a propulsé Java, le Cloud propulsera le(s) langage(s) de demain...
    Et Java m'a tout l'air d'être davantage sur la pente descendante qu'autre chose (une analyse des raisons de ce déclin progressif serait d'ailleurs pertinente aussi).

    • [^] # Re: Chacun son style

      Posté par  (site web personnel) . Évalué à 10.

      C++ demande une formation solide et une bonne compréhension pour arriver à l'utiliser correctement, avec Java une formation de quelques semaines suffit.

      Oui, quelques semaines suffisent à inculquer à un programmeur toutes les mauvaises habitudes de programmation possible et imaginables. Pas besoin de libérer des ressources allouées, y'a le garbage collector pour ça, on peut coder par essai et erreur (c'est quoi le français pour "trial and error" ?), etc.

      Apprendre à programmer par le langage le plus déresponsabilisant qui soit, c'est vraiment pas la meilleurs solution.

      • [^] # Re: Chacun son style

        Posté par  . Évalué à 2.

        Apprendre à programmer par le langage le plus déresponsabilisant qui soit, c'est vraiment pas la meilleurs solution.

        Je trouve que certains langages de script sont bien pire, quand même... TCL te permet de redéfinir les mots clef par exemple ! :-D

        on peut coder par essai et erreur (c'est quoi le français pour "trial and error" ?), etc.

        Que reproche tu au fait de tester son code et de l'adapter si ça marche pas ? Ça me parait tout à fait naturel...
        Et puis qui peut se targuer d'avoir un code qui marche du premier coup ?

        C'est bizarre comme reproche.

        • [^] # Re: Chacun son style

          Posté par  (site web personnel) . Évalué à 4.

          Que reproche tu au fait de tester son code et de l'adapter si ça marche pas ? Ça me parait tout à fait naturel...

          En Java tu as plein de garde-fous qui te protègent de certaines erreurs, comme l'accès à un mauvais indice de tableau. Ton programme Java va immédiatement te dire que ton accès est mauvais, alors qu'en C ou C++, dans le pire cas personne ne te dit quoi que ce soit et tu as l'impression que ça marche. On est donc obligés de faire attention à pas mal de choses, comme la validité des indices de tableaux, la validité d'un pointeur, etc.

          C'est cette obligation d'attention lors de l'écriture qui va manquer aux développeurs Java qui diront ensuite "C ou C++ sai nul, on peut faire trop de conneries avec".

          • [^] # Re: Chacun son style

            Posté par  . Évalué à 10.

            N'importe quoi.

            Java/C#:
            Tu as une OutOfBoundException, ton programme plante, tu le vois et tu vérifie l'indice parce que tu avais oublié de le faire.

            C++:
            Ton programme peut planter, ou pas. En tout cas il ne fait pas ce que tu veux, et tu comprends pas forcément pourquoi. Tu lance gdb ou valgrind, tu vois l'erreur, tu corrige.

            Dans les deux cas tu as une erreur, tu le repère et tu corrige. C'est plus ou moins facile mais bon...
            Le reste c'est du bullshit. C'est pas parce que le C++ demande une attention de tous les instants, un regard d'acier et une intelligence d'or que le dev C++ aura effectivement ces qualités du début à la fin de la journée.

            Dans discipline personnelle, y'a personnelle. ;-)

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 2.

              C++:
              Ton programme peut planter, ou pas. En tout cas il ne fait pas ce que tu veux, et tu comprends pas forcément pourquoi. Tu lance gdb ou valgrind, tu vois l'erreur, tu corrige.

              C'est bien ce que je dis, si tu fais n'importe quoi ça ne se voit pas forcément tout de suite. Et si tu utilises un tableau alloué dans la pile valgrind peut ne rien voir du tout.

              gdb ne dit rien sur les dépassements de tableaux. tu ne l'utiliseras qu'en cas de plantage, et pas si le programme a l'air de marcher.

              En tout cas les programmeurs Java ont pris le pli du workflow "compiler, exécuter, vérifier", parce que dans beaucoup de cas c'est à l'exécution qu'on voit les erreurs. Dans d'autres langages plus bas niveau la vérification doit commencer dès l'écriture du code.

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 10.

                OK. Donc le C++ c'est mieux parce que c'est indébogable.

                Original comme argument je retiens.

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 3.

                  Ce n'est pas ce qu'il a dit. Il dit que c'est mieux parce que ça oblige à faire attention à son code.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 6.

                    C'est assez débile. Les autres langages obligent aussi à faire attention à son code, si l'on veut limiter les bugs. Simplement, ils libèrent de toute une catégorie de problèmes à la noix, ce qui est toujours une bonne chose.

                    Enfin, j'imagine qu'on trouve des conducteurs qui ne veulent pas de ceinture de sécurité parce qu'ils ont peur que ça les déresponsabilise (sic).

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 7.

                  C'est un peu le même argument pour la supériorité de Slackware:
                  qui doit réfléchir, toi ou la machine ?

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à -1.

                  En faite, ce qu’il dit c’est : « La java c’est mieux, ça lisse les compétences vers le bas. » et c’est ce que cherche les entreprises.

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 3.

                    C'est clair en entreprise ils ne veulent personnes de compétents, moins ils leur CA est grand mieux ils se portent.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel, Mastodon) . Évalué à 6.

                      Ce n'est pas la question. Les technologies Java permettent de d'embaucher des armées de développeurs moyens, tout en assurant une qualité correcte des logiciels qui sont issus de ces armées. Alors qu'avec le C++, il faut plus de compétence et de bouteille pour parvenir à un résultat de qualité équivalente. Évidement, il y a une différence de coût.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 3.

                        euh ouais, alors la "qualité correcte" est très moyenne sur pas mal de points, mesurables, et pour dépasser ce stade de "qualité passable" il faudra quelques développeurs Java un peu expérimentés avec des compétences et de la bouteille (et pas seulement techniques, mais aussi orientées projet, communication et suivi de bonnes pratiques...) qui font qu'au niveau des coûts on s'y retrouve (rajouter de la RAM puis des serveurs, ça a aussi des coûts)

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 7.

                En tout cas les programmeurs Java ont pris le pli du workflow "compiler, exécuter, vérifier", parce que dans beaucoup de cas c'est à l'exécution qu'on voit les erreurs. Dans d'autres langages plus bas niveau la vérification doit commencer dès l'écriture du code.

                L’analyse statique de code c'est quelque chose qui se répand aussi bien chez les javaistes qu'ailleurs.

                Le monde Java a aussi bien plus l'habitude que le monde C++ de faire des tests unitaires.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 6.

                  Le monde Java a aussi bien plus l'habitude que le monde C++ de faire des tests unitaires

                  Forcément, ils laissent tellement plus de bugs…

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 3.

                dans beaucoup de cas c'est à l'exécution qu'on voit les erreurs.

                Vu qu'on parlait des débordements de tableaux, forcément !
                Les cas où cela peut être détecté à la compilation sont extrêmement rares...

                • [^] # Re: Chacun son style

                  Posté par  (site web personnel) . Évalué à 2.

                  je voulais dire qu'il y a bien plus de détection automatique d'erreur à l'exécution en Java qu'avec d'autres langages, et que ça tend à valider une certaine façon de travailler, qui consiste à compiler, puis à exécuter pour voir si ça marche. En C/C++, c'est une mauvaise habitude, on ne peut pas travailler comme ça.

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 4.

              Là c'est plutôt toi le n'importe quoi :)
              > En tout cas il ne fait pas ce que tu veux
              > Dans les deux cas tu as une erreur, tu le repère et tu corrige.
              Justement, le problème est là : le programme ne plante pas, en apparence il fait ce que veux, et donc tu ne corriges pas. Parfois il n'y a même pas de débordement pendant la phase dev/qualif : les données en entrée font que tu ne sors jamais des limites du tableau, jusqu'au passage en prod et l'arrivée de données non-anticipées (typiquement une attaque) sur ce bug caché :

              • Java, paf, explosion.
              • C++ : faille potentielle...

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 3.

              En même temps si tu utilises C++, autant utiliser std::vector et dans ce cas, il te prévient quand tu déborde!
              Ici on compare C et Java.

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 6.

                Il te prévient pas si tu utilises l'opérateur [].

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 0.

                  C'est un choix sur les performances de ne pas tester la validité de l'indice.
                  Si le développeur décide que cet aspect est négligeable, rien ne l’empêche de définir sa propre classe héritant de std::vector (par exemple MyNamespace::vector) qui surcharge l'opérateur [] en incluant la dite vérification.
                  Le C++ à au moins l'avantage de ne rien imposer au développeur, c'est à lui de poser ses propres gardes-fou.

                  • [^] # Re: Chacun son style

                    Posté par  (site web personnel, Mastodon) . Évalué à 1.

                    Par design, std:vector<> n'est pas dérivable. Tu ne peux que composer avec std::vector<>.

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à -1.

                      Dans ce cas là, cela ne poserait pas trop de problèmes, mais il est vrai que dans l'absolu c'est mal venu, et que l'on préfèrerait dans ce cas passer par une fonction libre inlinée qui réalisera le check par assertion d'abord plus éventuellement exception si on veut coder défensif -- pour le défensif toujours, il y a at(). Fonction dont l'utilisation peut être rendue obligatoire par des règles de développement pour le projet.
                      Maintenant, je l'ai déjà signalé, les STL checkées sont déjà là pour répondre à ce besoin.

                    • [^] # works for me

                      Posté par  . Évalué à 2.

                      $ cat vector_inherits.cpp

                      #include <vector>
#include <iostream>
#include <exception>

template <class T, class A = std::allocator<T> >
class MyVector : public std::vector<T,A>
{
public:
   const T & operator[](typename std::vector<T,A>::size_type i) const {
      if (i >= std::vector<T,A>::size()) throw std::exception();
      return std::vector<T,A>::operator[](i);
   }
};

int main()
{
   MyVector<int> v;
   v.push_back(5);
   try {
      std::cout << v[1] << std::endl;
   } catch (const std::exception & e) {
      std::cout << "received exception" << std::endl;
      return 1;
   }
   return 0;
}

                      $ g++ -o vector_inherits -Wall vector_inherits.cpp
                      $ ./vector_inherits
                      received exception
                      $

                      • [^] # Re: works for me

                        Posté par  (site web personnel) . Évalué à 0.

                        On va se payer des conversions dès que l'on va devoir récupérer des vecteurs depuis des bibliothèques déjà établies.
                        BTW, autant retourner at() qui fait mieux le boulot, ou obliger à l'utiliser si c'est pour faire du défensif plutôt que pour assurer de la prog par contrat... (où assert eut été une bien meilleure solution qu'une exception)

                      • [^] # Re: works for me

                        Posté par  (site web personnel, Mastodon) . Évalué à 2.

                        Je te conseille la lecture des bouquins de Meyers, qui te permettraient de comprendre que ce que tu viens d'écrire, c'est de la merde.

                        int main()
{
   std::vector<int> *pv = new MyVector<int>;
   pv->push_back(5);
   try {
      std::cout << (*pv)[1] << std::endl;
   } catch (const std::exception & e) {
      std::cout << "received exception" << std::endl;
      return 1; // undefined behaviour
   }

   delete pv ; // explosion en vol
   return 0;
}

                        La norme, tu sais, le document qui décrit peu ou prou le langage C++ (comprenant la STL), spécifie clairement que les conteneurs standards ne sont pas dérivables publiquement. Tu es tombé dans le piège à débutant. Welldone.

                        Ici, le soucis est évidement que les conteneurs standards ne définissent pas de destructeur virtuel, ce qui fait que la classe template n'est pas conçue pour être dérivée.

                        Au pire, tu aurais pu composer avec l'héritage privé, s'eut été acceptable, mais ta classe dérivée n'aurait plus été un std::vector.

                        • [^] # Re: works for me

                          Posté par  (site web personnel) . Évalué à 1.

                          Si les développeurs commencent à faire des new sur des vecteurs même pas hérités, la dérivation publique de std::vector<> sera le moindre des problèmes.
                          Dans l'absolu tu as raison, mais en sortant du contexte académique, cela passe...

                          ...presque. Le hic probable qui va planter les dév qui savent qu'on ne doit jamais faire de new sur un conteneur de la STL (et cf mon message précédent), est le suivant

                          std::vector<int> /*&&*/ cots::f();
void cots::g(std::vector<int> v); // copy-elision volontaire
...
MyVector<int> v = cots::f(); // copy-conversion
// certes, on va plutôt jouer avec [] et pas avec le C++ avec un type pareil...
v.erase(
    std::remove_if(
        v.begin(),v.end(),
        [&](int i){i>42)}),
    v.end());
g(v); // et re: copie-conversion

                          • [^] # Re: works for me

                            Posté par  (site web personnel, Mastodon) . Évalué à 1.

                            Pourquoi allouer dynamiquement un conteneur standard c'est mal ?
                            Est-ce qu'allouer dynamiquement un type composé avec des conteneurs standards est mal ?

                            Je suis preneur de n'importe quelle source (papier, web). Et ne parle pas de performances (un le contenu géré par le vector est alloué sur le tas) ou le problème de la gestion de la désallocation (std::auto_ptr est mon premier ami).

                            Est-ce que tu essayais d'illustrer le slicing problem avec ton exemple ? Je ne vois pas le rapport avec le taboo de l'allocation de conteneurs (et c'est quoi cots ?).

                            • [^] # Re: works for me

                              Posté par  (site web personnel) . Évalué à 1.

                              Mal, parce que les conteneurs sont déjà RAIIens. Du coup les allouer comme ça, cela brise les bonus de l'objet. Tu connais auto_ptr, c'est bien (car tu vois donc où je voulais en venir -- accessoirement, deux smart-ptr en paramètres sont un problème, cf XC++/GOTW/ou artima je ne sais plus -> Law Of the Big Two). Avec la prochaine norme, on y gagnera le déplacement (et donc encore moins de raisons valables d'allouer des conteneurs via new).

                              Oui, pour le slicing. Le rapport, c'est que le "taboo" est lié à un cas d'utilisation mal venu. Les conteneurs sont prévus pour être manipulés par valeur.
                              Le slicing est réel. Après l'autre exemple de non supplantation de [] est aussi très pertinent (du ridicule de la surcharge).

                              Mais ... pourquoi s'échine-t-on à parler des mauvaises solutions ? Au lieu de l'extension par fonction libre, ou des STL checkées ?

                              COTS:component off-the shelves ; en gros un truc externe payant (lib, programme, etc), mais régulièrement étendu à "truc externe" au projet.

                              • [^] # Re: works for me

                                Posté par  (site web personnel, Mastodon) . Évalué à 1.

                                En fait, depuis tout à l'heure, je cherchais un endroit où je pourrais imaginer utiliser un new sur un std::vector… ben j'ai pas trouvé :o) Je crois qu'en fait, je n'ai jamais instancier de vector dyamiquement parce que ça n'a pas de sens. Mais bon, mon but était de pointer le fait que les conteneurs ne sont pas conçus pour être dérivés.

                                Quel est le problème de passer deux smart_ptr en paramètres d'une fonction ?

                                • [^] # Re: works for me

                                  Posté par  . Évalué à 1.

                                  Eeuuuhhh... il y a plein de tres bonnes raisons d'instancier des vecteurs dynamiquement, j'ai du mal a croire que tu n'en aie jamais vu...

                                  • [^] # Re: works for me

                                    Posté par  (site web personnel) . Évalué à 0.

                                    Plein ? Pas vraiment.
                                    Je ne vois que :
                                    * faciliter des déplacements en l'absence de rvalue-reference quand on n'a pas accès au (N)RVO, que l'on ne veut pas du COW (copy-on-write), ou que l'on veuille voyager entre scopes de façon pas si triviale (mais là cela sens l'abstraction moisie si vous me permettez)
                                    * les TLS, quand on ne dispose pas d'abstractions de haut-niveau.

                                    Un vecteur est déjà une allocation dynamique, qui par dessus le marché est RAII. Vouloir rajouter une seconde couche de dynamique et faire sauter le RAII de surcroit ? Oui mais non. Ce n'est pas fréquent que cette approche soit la bienvenue. Au contraire, c'est un pur code-smell en ce qui me concerne.

                                    • [^] # Re: works for me

                                      Posté par  . Évalué à 0.

                                      Exemple typique : une structure de vecteur a la base c'est dans les 20 bytes si mes souvenirs sont bons, quand t'ecris du code qui a besoin d'avoir une empreinte memoire faible, tu preferes souvent avoir un pointeur qui ne prend que 8 bytes, et si/quand t'as besoin du vecteur tu l'alloues.
                                      On peut parler des perfs niveau cycles CPU aussi, car NRVO a ses limites, etc... Si tu ecris ton code de maniere 'academique' sans te soucier des perfs c'est sur que t'en as pas autant besoin, mais pour des softs ayant des contraintes ca change.

                                      • [^] # Re: works for me

                                        Posté par  (site web personnel) . Évalué à 1.

                                        OK, disons que 16 bytes sont économisés dans le cas où il est vide. Dans le cas contraire on a un surcout de 8 bytes.
                                        Franchement, ce n'est rien. A moins d'avoir un millier de vecteurs vides en même temps -- mais là cela sent le problème de design ou de choix de structures (typiquement c'est pas le plus adapté aux matrices creuses) -- ce n'est pas un surcout pertinent je trouve. Sans parler que mes vecteurs sont plus souvent pleins que vides, donc je serais en situation de surcout permanent avec un tel choix.

                                        De plus, on perd en perf
                                        * tests de non-nullité systématiques avant utilisation
                                        * new + delete de plus
                                        * potentielles indirections supplémentaires sur accès

                                        Pour le NRVO, il y a toujours le passage par référence si on a peur de l’inapplicabilité du principe avec notre compilo -- le vieux sun CC m'avait d'ailleurs surpris à ce sujet sur des vecteurs et un code pas du tout torturé pour gagner l'optimisation. Et cela dégradera moins les perfs que des allocations dynamiques de vecteurs. (NB: maintenant, cet argument ne va plus tenir ; mais je me répète)

                                        • [^] # Re: works for me

                                          Posté par  . Évalué à 0.

                                          Ben tout depend des structures a gerer, quand la vitesse n'est pas l'element le plus important mais l'espace memoire l'est, faut faire des choix. Tu passes de 20 bytes a 8, t'as 60% de gain, c'est consequent. en plus ca peut permettre de faire rentrer ta structure dans une ligne de cache, etc... qui amenera des gains non negigeables en vitesse.
                                          Maintenant est-ce que ces vecteurs seront le plus souvent utilises ou pas ? De nouveau ca depend du probleme, dans certains cas oui dans d'autres non. Evidemment que si ils sont le plus souvent plein alors c'est pas rentable.

                                          Le test de non-nullite supplementaire c'est 1 cycle, c'est genre 0 comme cout. Quand au new+delete en plus, tu peux toujours avoir un systeme de cache de vecteurs dispo si tu veux qui t'evite ce cout la(si t'en as besoin, de nouveau c'est selon les besoins).

                                      • [^] # Re: works for me

                                        Posté par  . Évalué à 1.

                                        La question portait sur l'allocation dynamique d'un std::vector<T> et la manipulation de pointeurs sur std::vector<T> ensuite, et dans ton exemple tu parles d'un tableau T[], ce n'est pas le meme besoin.

                                        Maintenant, pour l'occupation memoire, le tableau de base, c'est au moins un pointeur, mais tu as aussi besoin de sa capacité (taille allouée), et du nombre d'éléménts présents (taille utilisée). Au final, c'est la même empreinte mémoire, sauf si la capacité et la longueur sont fixes. Mais dans ce cas, pourquoi ne pas utiliser std::array<T> ?

                                        Bref, ca ne sert a rien d'allouer dynamiquement un std::vector<T>.

                                        • [^] # Re: works for me

                                          Posté par  . Évalué à -3.

                                          Je parles d'un tableau ? Non je parles d'un vecteur qui est conceptuellement membre d'une structure largement utilisee.

                                          public struct bob { vector<int> *MonVecteur; plein de bordel supplementaire}

                                          • [^] # Re: works for me

                                            Posté par  . Évalué à 3.

                                            Ah, oui, je comprends mieux. Donc pour gagner en performance, tu rajoute une indirection supplémentaire, et tu parsème ton code de tests if (MonVecteur != 0), c'est bien ça ?

                                            • [^] # Re: works for me

                                              Posté par  . Évalué à -1.

                                              En ayant un pointeur :

                                              a) J'evites le cout du constructeur / destructeur si le vecteur n'est pas utilise
                                              b) J'economises 12 bytes sur la taille de la structure qui peuvent faire une sacree difference selon l'utilisation et qui notamment:
                                              - peuvent faire la difference entre entrer dans une ligne de cache ou pas par exemple qui a un impact plutot gros selon les cas
                                              - ca peut aussi te permettre d'economiser pas mal de RAM si tu passes ta structure d'une taille d'un peu plus de 64 bytes a moins de 64 bytes par exemple du fait du fonctionnement de l'allocateur standard (il prendra l'allocation sur la liste des blocs de 64 bytes plutot que 96 ou 128)

                                              Dans les cas ou le vecteur n'est utilise que dans certains cas, ca peut avoir une valeur absolument significative

                                              • [^] # Re: works for me

                                                Posté par  . Évalué à 1.

                                                a) J'evites le cout du constructeur / destructeur si le vecteur n'est pas utilise

                                                Quel est le cout d'un constructeur / destructeur pour un vecteur vide ? Si le cycle de vie de la structure est un probleme de performance, ca ne viendrait pas plutot de l'allocateur ?

                                                En ce qui concerne la taille de la structure et les performances d'un allocateur "standard" par bloc, cela n'est pertinent que si tu alloue tes structures unitairement avec cet allocateur (un gros tableau de structures n'est pas concerné).Si tu as vraiment des problèmes de performance liées a ton allocateur, pourquoi ne pas en prendre un autre, puisque le langage le permet facilement ?

                                                • [^] # Re: works for me

                                                  Posté par  . Évalué à -1.

                                                  Quel est le cout d'un constructeur / destructeur pour un vecteur vide ? Si le cycle de vie de la structure est un probleme de performance, ca ne viendrait pas plutot de l'allocateur ?

                                                  Ca depend du cas comme pour tout, si par defaut ton vecteur a une taille allouee de 10 objets (parce que dans le cas usuel ou le vecteur contient quelque chose il en a 10), ton constructeur va faire une allocation a chaque fois par exemple.
                                                  Si ton vecteur est cree uniquement lorsque un objet va etre ajoute, ben tu sauves cette allocation pour tous les cas ou aucun objet n'est ajoute.

                                                  En ce qui concerne la taille de la structure et les performances d'un allocateur "standard" par bloc, cela n'est pertinent que si tu alloue tes structures unitairement avec cet allocateur (un gros tableau de structures n'est pas concerné).Si tu as vraiment des problèmes de performance liées a ton allocateur, pourquoi ne pas en prendre un autre, puisque le langage le permet facilement ?

                                                  Je vais te donner un tres bon exemple de pourquoi: L'allocateur standard dans Windows a tout un tas de features pour eviter qu'un buffer overflow dans la heap ne se transforme en vulnerabilite (c'est pas une garantie a 100% mais il rend la chose vraiment compliquee pour le hacker), je ne connais a peu pres aucun allocateur 'custom' qui a ces features.

                                                  • [^] # Re: works for me

                                                    Posté par  . Évalué à 2.

                                                    Ca depend du cas comme pour tout, si par defaut ton vecteur a une taille allouee de 10 objets (parce que dans le cas usuel ou le vecteur contient quelque chose il en a 10), ton constructeur va faire une allocation a chaque fois par exemple.

                                                    Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
                                                    Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.

                                                    L'allocateur standard dans Windows a tout un tas de features pour eviter qu'un buffer overflow dans la heap ne se transforme en vulnerabilite (...), je ne connais a peu pres aucun allocateur 'custom' qui a ces features.

                                                    Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.

                                                    • [^] # Re: works for me

                                                      Posté par  . Évalué à -3.

                                                      Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
                                                      Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.

                                                      Si tu dois de toute facon avoir du code avant la 1ere insertion, pourquoi alors te taper ces 12 bytes additionels tout le temps ?

                                                      Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.

                                                      Et il a quelle taille ton pool ? Tu alloues un gros bloc bien enorme qui mange la RAM et qui a l'effet oppose(je te rappelles que l'objectif est minimiser l'utilisation memoire hein) ou tu alloues plusieurs blocs a la demande auquel cas il te faut gerer les allocations/deallocations des blocs complets avec tracking, etc... ?

                                                      • [^] # Re: works for me

                                                        Posté par  . Évalué à 1.

                                                        Et il a quelle taille ton pool ?

                                                        Un pool à multiples blocs, typé et réutilisable, c'est grosso-modo 20 lignes de code, sans aucun impact sur le reste si on surcharge new/delete dans la structure bob. Ou est le problème ?

                                                        J'ai un peu de mal à cerner le genre de programme auquel tu fais référence : on a besoin d'un maximum de performances (on descend jusqu'au lignes de cache), mais d'un autre coté on alloue de nombreux objets de petite taille, avec cycle de vie court (la performance des ctor/dtor a été évoquée), et on ne peut pas faire de pré-allocation massive parce qu'il faut aussi réduire l'empreinte mémoire globale...

                                                        Un exemple concret serait le bienvenu.

                                                        • [^] # Re: works for me

                                                          Posté par  . Évalué à -4.

                                                          Un pool à multiples blocs, typé et réutilisable, c'est grosso-modo 20 lignes de code, sans aucun impact sur le reste si on surcharge new/delete dans la structure bob. Ou est le problème ?

                                                          20 lignes ? J'aimerais bcp voir un pool en 20 lignes qui marche et qui est efficace (temps d'allocation, support multithread,...)

                                                          J'ai un peu de mal à cerner le genre de programme auquel tu fais référence : on a besoin d'un maximum de performances (on descend jusqu'au lignes de cache), mais d'un autre coté on alloue de nombreux objets de petite taille, avec cycle de vie court (la performance des ctor/dtor a été évoquée), et on ne peut pas faire de pré-allocation massive parce qu'il faut aussi réduire l'empreinte mémoire globale...

                                                          Un OS ou soft serveur, ces jouets la typiquement on besoin de controle sur leur empreinte memoire et doivent etre rapide.

                                                          • [^] # Re: works for me

                                                            Posté par  . Évalué à 2.

                                                            20 lignes ? J'aimerais bcp voir un pool en 20 lignes qui marche et qui est efficace (temps d'allocation, support multithread,...)

                                                            Oui, 20 lignes, c'est nettement suffisant pour un pool simple, sans multi-thread (tu rajoutes des contraintes quand ça t'arrange). Pour un exemple, demande à Herb, il te montrera.

                                                            • [^] # Re: works for me

                                                              Posté par  . Évalué à -4.

                                                              Je rajoutes des contraintes quand ca m'arrange ? Je t'ai donne un exemple typique plus haut : gestion du protocole TCP

                                                              Explique moi quel OS a une stack TCP mono-thread, ou quel soft serveur est mono-thread et lequel de ces softs peut se permettre un pool non-performant...

                                                      • [^] # Re: works for me

                                                        Posté par  (site web personnel) . Évalué à 0.

                                                        Comment peut-on avoir du code significatif avant la première insertion ? S'il y en a, le vecteur n'existera alors même pas chez moi. Le moment où le vector est vide est anecdotique au cours de l'exécution du programme. Il est fait pour fonctionner initialisé avec des données dans ses tuyauteries, et pas à vide.
                                                        Du coup le hack du pointeur sur vecteur ressemble(rait) plus (avec mes données et algos métiers) à une pessimisation, en volume de RAM consommée, qu'autre chose.

                                                        Et il n'y a pas d'alloc sur vecteur vide: push_back fait toujours un check de capacité, autant le laisser faire son boulot. Il y a juste l'init de 2-3 membres.

                                                        • [^] # Re: works for me

                                                          Posté par  . Évalué à -2.

                                                          Si tu te contentes de faire un push_back, alors tu auras des reallocations frequentes plutot qu'une allocation, sachant que la taille moyenne est de 10, le moyen pour regler ca est de faire un reserve(10) a la 1ere insertion, mais dans ce cas, autant creer le vecteur a la 1ere insertion aussi.

                                                          Tu crois qu'un vecteur vide est forcement rare, c'est pas forcement le cas, ca depend du scenario, il y a plein de cas ou t'as besoin d'une structure pour gerer un tableau a taille dynamique mais qu'il se peut que tu n'aies jamais d'elements.

                                                          Prend un protocole avec une liste d'options par exemple (TCP par exemple), a chaque connection tu veux garder la liste des options et leur parametres. Il y a de fortes chances que tu n'aies aucune option, mais il se peut tout a fait que tu aies plusieurs options aussi

                                  • [^] # Re: works for me

                                    Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                    Effectivement, je rajouterai aux problèmes d'empreinte mémoire que tu as évoqué, qu'on peut également invoquer le découplage entre l'objet utilisateur et un vecteur, et donc les problèmes d'ABI qui en découle.

                                    #include <vector>
#include "people.hpp"

class Peoples
{
  std::vector<People> m_peoples ; 
}


                                    #include <vector>
#include "people.hpp"

class Peoples
{
  std::vector<People> * mp_peoples ; 
}

                                    Dans le premier cas, si on veut changer le conteneur on change aussi la structure et donc la taille de la classe qui encapsule le conteneur. Donc on casse l'ABI. Dans le second cas, ça n'a plus d'importance puisqu'un pointeur a toujours la même taille, quelque soit l'objet pointé.
                                    Ceci dit, je pense que si l'ABI est un problème, on pimp la classe.

                                • [^] # Re: works for me

                                  Posté par  (site web personnel) . Évalué à 1.

                                  Le problème apparait dans ce cas d'utilisation:

                                  void f(smart, smart);
...
f(smart(alloc()), smart(alloc()));

                                  Si les fonctions d'allocation peuvent lever une exception (typiquement new, voire même un constructeur, peut échouer), vu que le C++ n'apporte aucune garantie ici quant à l'ordre d'exécution des opérations (le compilo est libre de réordonner pour maximiser les perf), on peut se retrouver avec la première allocation réussie, mais non récupérée par sa capsule RAII (smart), et la seconde allocation échouée. Résultat des courses, une fuite de ressource.

                                  PS: je m'étais planté pour COTS, c'est commercial off-the-shelf. Composant, c'est dans la VF.

                                  • [^] # Re: works for me

                                    Posté par  (site web personnel, Mastodon) . Évalué à 1.

                                    C'est bien ce que je pensais. Il n'y a pas de problème à demander deux smart pointer en paramètres. Le problème vient quand on a un sagouin qui ne respecte pas le mantra « une opération, une ligne ». Parce que le problème que tu soulève, il existera quelque soit le nombre de paramètres prenant un smart pointer.

                                    smart r(alloc()) ;
smart l(alloc()) ;
f(r, l) ;

                                    • [^] # Re: works for me

                                      Posté par  (site web personnel) . Évalué à 0.

                                      C'est ça: il faut passer par des variables intermédiaires.
                                      Quant au sagouinisme, je suis sûr que l'on peut trouver des avantages aux temporaires non nommés, entre d'autres circonstance.

                                      • [^] # Re: works for me

                                        Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                        Je sais que, au libre choix de l'implémentation, la copy de l'objet temporaire peut être optimisée. Mais franchement, je préfère des temporaires nommées, qui ne mettent pas en cause la cohérence de l'application.

                      • [^] # Re: works for me

                        Posté par  . Évalué à 3.

                        Tu viens de montrer qu'il est techniquement possible de dériver de std::vector, c'est a dire que le compilateur ne génère pas de diagnostic. Le problème, c'est que le compilateur ne va pas t'avertir des dangers potentiels a l'utilisation.

                        En modifiant légèrement le main() :

                        int run( std::vector<int> const& v ) {
    try {
        std::cout << v[1] << std::endl;
    } catch (const std::exception & e) {
        std::cout << "received exception" << std::endl;
        return 1;
    }
    return 0;
}   

int main() {
    MyVector<int> v;
    v.push_back(5);
    return run( v ) ;
}

                        On obtient a l'exécution :

                        $ g++ -o vector_inherits -Wall vector_inherits.cpp
$ ./vector_inherits
0
$

                        Et pourtant, dans la fonction run(), c'est bien l'instance de MyVector qui est utillisée, n'est-ce pas ? Pourquoi le comportement du programme a-t'il changé ?

                        Tu auras aussi des résultats comiques si tu ajoute un destructeur spécifique a MyVector et que tu manipules tes instances par l'intermédiaire de pointeur sur sdt::vector...

                        Les containers de la STL ne sont pas conçus pour êtres dérivés en public, mais il n'y a pas de garde fou, comme d'habitude.

                        • [^] # Re: works for me

                          Posté par  . Évalué à -1.

                          Effectivement, ca ne fonctionne que si tu n'utilises que des fonctions prenant des MyVector et pas des std::vector, mais ca peut être vu comme un "framework".
                          Les méthodes (et destructeurs) des containers STL n'étant pas virtuels, la classe n'est pas faites pour être dérivables. En pratique, tu peux quand même en hériter pour ne pas avoir à recoder la STL, mais cela implique de s'imposer de n'utiliser que ce type aux endroits où il est attendu.

                          • [^] # Re: works for me

                            Posté par  (site web personnel, Mastodon) . Évalué à 1.

                            Ce qui est très propice aux erreurs ;) Bref, hérite en privé, et le problème ne se posera plus. Tu réutilisera std::vector, mais tu en changeras la sémantique. Bref, beaucoup de boulot pour utiliser std::vector<>::operator [] au lieu de std::vector<>::at ;)

                • [^] # Re: Chacun son style

                  Posté par  (site web personnel) . Évalué à 1.

                  Des implémentation checkées de la STL vont permettre de réaliser les vérifications de bornes. Ainsi en phase de développement et de tests on pourra consolider les accès.
                  Et en phase de production, on a aura les perfs.
                  Maintenant si on pense que les dév sont trop des gorets, et qu'il font n'importe quoi, on peut en prime faire de la prog défensive qui vérifiera les bornes aux endroits vraiment critiques, et pas dans une boucle "for_each(v.begin(),v.end(),[&]{actions});" où cela serait totalement idiot.

                • [^] # Re: Chacun son style

                  Posté par  (site web personnel) . Évalué à 2.

                  Il te prévient pas si tu utilises l'opérateur [].

                  Ce que tu lui reproches, c'est de laisser le choix?
                  Salaud de langage qui laisse le choix, faudrait interdire le choix (après, si les programmeurs choisissent la version rapide sans faire attention aux limites, c'est la fautes à eux, pas au langage!)

                  Certes, il n'y a pas de compilo que je connaisse qui a une option "trucs sans tests de limites interdit", mais si il y a un besoin je ne pense pas que ce soit dur à faire.

                  Sinon, Java, les tableaux en version non escargot, tu fais comment?

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 3.

                    Non mais attends, c'est même pire que ça, en plus, si tu veux faire dans le multidimensionnel, C++ c'est nul, il faut passer par () et pas par [], parce que sinon ça passe pas. Quel fourbe ce Bjarne !

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à 1.

                      Ca marche très bien. Retourne des proxys et puis basta.
                      Ce sera juste un chouilla moins efficace.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 2.

                        Beurk. Et si j'ai un tableau à 5 dimensions? Dans un cas j'ai tab(i,j,k,l,m), qui fait correctement ce qu'il faut, dans l'autre, j'ai tab[i][j][k][l][m] qui fabrique tout plein de proxys juste pour pouvoir émuler la notation des tableaux classiques en C...

                        • [^] # Re: Chacun son style

                          Posté par  (site web personnel) . Évalué à 1.

                          Un tableau à 5 dimensions ... hum hum. Perso, j'appelle ça un code-smell, mais passons vu qu'à 2 voire 3 dimension, il y a un besoin pertinent.
                          Un proxy, cela va être quoi ? Un pointeur encapsulé dans une variable copiable, et qui expose un accès indexé. Ouais, un pointeur quoi.
                          Éventuellement un taille en plus. C'est ça le problème ? En quoi c'est différent de que que d'autres langages vont fournir en natif?
                          (Sans parler, que diverses bibliothèques vont déjà fournir tout ce qu'il faut pour enchainer les [], et ce de façon transparente.)

          • [^] # Re: Chacun son style

            Posté par  (site web personnel) . Évalué à 7.

            Ton programme Java va immédiatement te dire que ton accès est mauvais, alors qu'en C ou C++, dans le pire cas personne ne te dit quoi que ce soit et tu as l'impression que ça marche

            Tout pareil avec C++ qu'avec Java:
            http://www.cplusplus.com/reference/stl/vector/at/
            "vector::at signals if the requested position is out of range by throwing an out_of_range exception."

            Juste que C++ permet effectivement de programmer à l'ancienne (version C) pour une compatibilité ascendante (avec les risques qui voient avec), mais voila, C++ est critiqué non pas pour C++, mais pour sa compatibilité. Alors, que Java, il faut tout refaire (ou se faire chier pour faire un binding vers la lib C, ça marche certes, mais c'est chiant), ou c'est hyper lent (car Java ne permet pas de déactiver le test out of range, et parfois, ça fait ramer à mort par rapport à C++ et son [] qui ne teste pas, bref, avec C++, tu as le choix).

            Bref, non, Java ne protège pas plus que C++, juste Java protège plus que C mal codé (comme C++ protège plus que C mal codé)

            • [^] # Re: Chacun son style

              Posté par  . Évalué à -2.

              D'ailleurs c'est assez rigolo de voir que ça y est ce seras avec Java7 (sortie prévue à la fin du moi) que Java aura de quoi vérifier les modifications sur un fichier ou un dossier sans faire de polling (peut être que Netbeans va gagner en performance au lieu de continuellement revérifier l'état du système de fichier).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Chacun son style

                Posté par  (site web personnel) . Évalué à 5.

                Quel est le rapport avec la choucroute ?
                Aucun langage n'a prévu ce mécanisme par défaut, ce ne sont que des bibliothèques qui permettent de s'abonner à des modifications du système de fichier. Exemple : inotify, utilisable en C++ ou en Java, bien avant Java7...

                https://launchpad.net/inotify-java

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à -2.

                  Javascript dans le navigateur est un peu prévu pour, au contraire.

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 2.

                  En C comme en C++ c'est utilisable directement dès que le système le permet, comme quoi ça n'a pas que des inconvénients d'être proche du système.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Chacun son style

                    Posté par  (site web personnel) . Évalué à 2.

                    Non, c'est pareil, un peu de code JNI et on appelle le C direct.

                    inotify-java est juste une glue avec ce code JNI déjà créé par quelqu'un autre.

                    Cela n'a rien à voir avec être prêt du système, la question est juste de savoir si oui ou non il existe une bibliothèque dans un langage donné ? Dans pratiquement tous les langages (Java, Python, Perl...), on fait un binding C, mais l'inverse pourrait être vrai. Il est tout à fait possible d'appeler du java depuis du C (on pourrait imaginer de créer une interface CGI dans Tomcat par exemple).

                    D'ailleurs être prêt du système ne veut pas dire grand chose au final, il y a des langages dans lesquels on est plus proche de l'architecture du CPU, dans tous les cas, un appel système entraîne un changement de contexte, alors JVM ou pas, ça ne change pas grand chose.

                    Je ne parle même pas du fait que pour être prêt du CPU en C, il faut compiler pour l'architecture donnée alors qu'une JVM ou équivalent peut s'adapter exactement au système (utilisation ou non d'unités vectorielles, utilisation d'unités de calcul flottant...)

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 10.

                sortie prévue à la fin du moi

                Freud aurait adoré te rencontrer...

            • [^] # Re: Chacun son style

              Posté par  . Évalué à 0.

              Je suis tellement d'accord... Il suffit par exemple d'utiliser les vector stl pour éviter beaucoup d'ennuie.

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 0.

              Je suis curieux de découvrir les cas où les tests de dépassement de taille de tableau transforment une appli fluide en appli arthritique… Allez, peut-être pour les calculs haute performance en sciences physiques, et encore…

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 1.

                Pour ça je en sais pas. Mais l'utilisation de la concaténation de String pose vraiment problème en Java, il faut à tout prix utiliser une classe comme StringBuilder ou StringBuffer.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 2.

                  Je te conseil de regarder la bytecode généré par javac... Dans 99% des cas, quelque soit le source tu te retrouveras avec le même bytecode.

                  Même au pire cas où tu utiliserais un StringBuffer quand il faut pas, il va détecter qu'il
                  qu'il ne peut pas avoir de concurrence sur le lock.

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 2.

                    Je regarderais, mais il y a eu un impact sur les performance (et non ce n'était pas dans une boucle ni conditionnel).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 3.

                En haute performance, on utilise pas la vérification automatique de dépassement de taille de tableau, car le seul moyen de le faire correctement, c'est de vérifier les bornes pour chaque accès (et ça coûte énormément en temps CPU). C'est un des cas où l'utilisation de Fortran, C ou C++ a plus d'intérêt que Java par exemple:

                • C te force à tout penser, et puisque de toute manière on parle de calcul haute-perf, ça « va de soi » (et c'est bibi qui doit optimiser le tout ensuite...)
                • Fortran propose tout un tas de constructions de relativement haut niveau concernant le calcul scientifique. Par exemple, si A et B sont des tableaux de même taille, je peux faire A=A+B et le compilateur va automatiquement générer le bon type de code: SSE pour x86/x86_64, Altivec pour PowerPC, etc.
                • C++ n'est pas qu'un langage orienté objet. Comme le dirait S.Meyers (Efficient C++), il s'agit de plusieurs « langages » (ou dialectes) en un: C, C-avec-classes, templates, et STL. En HPC, on a tendance à utiliser C++ en tant que C + templates + surcharge des opérateurs (pour pouvoir reproduire ce que Fortran permet de faire nativement, et étendre le tout à de nouvelles structures données).

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à -1.

                  En haute performance, on utilise pas la vérification automatique de dépassement de taille de tableau, car le seul moyen de le faire correctement, c'est de vérifier les bornes pour chaque accès

                  ??? L'analyse statique, ce n'est pas pour les chiens. Si j'ai un tableau de 1000 entrées et que mon indice va de 0 à 999, il est inutile de "vérifier les bornes pour chaque accès".

                  C te force à tout penser

                  Fortran propose tout un tas de constructions de relativement haut niveau

                  Faudrait savoir : il vaut mieux un langage qui te force à tout penser, ou un langage qui propose des constructions de relativement haut niveau ? C'est le grand n'importe quoi, là.

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 7.

                    L'analyse statique, ce n'est pas pour les chiens

                    Et si l'indice auquel tu veux accéder est connu seulement à l'éxecution ? Il va bien falloir vérifier qu'il est compris entre les borne au moment ou tu accède au tableau, de même si les bornes ne sont pas connues à la compilation ect.

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 1.

                      Et si l'indice auquel tu veux accéder est connu seulement à l'éxecution ? Il va bien falloir vérifier qu'il est compris entre les borne au moment ou tu accède au tableau, de même si les bornes ne sont pas connues à la compilation ect.

                      Oui bien sûr. Mais je ne crois pas que cela représente la majorité des situations où les performances sont critiques.

                      Quant aux bornes "non connues à la compilation", certes, avec un langage comme C où un tableau se résume à un pointeur sur le début des données, mais même C++ avec la STL permet d'éviter ce souci.

                      Enfin bon, on peut toujours vouloir faire de l'optimisation prématurée pour montrer qu'on est un dur, hein...

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 3.

                        Je crois que tu as tort. :)

                        Les noyaux de calcul (par exemple une tuile pour faire une multiplication de matrice) ont généralement des bornes fixées à la compilation (en fonction de la taille des différents niveaux et tailles de cache, etc.). Cependant, on se retrouve avec des algorithmes généraux pour gérer des tailles arbitraires. Dans les codes de HPC que j'ai croisés jusqu'ici, les bibliothèques pour le calcul intensif sont bien entendu optimisées et spécialisées, mais les programmes traitent des entrées de taille arbitraire.

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 3.

                      Dans certains cas, même si l'indice n'est connu qu'à l'exécution, l'analyse statique peut détecter s'il n'a aucune chance d'être en dehors. Par exemple si tu as un tableau de 365 valeurs, indexé par le jour dans l'année, provenant d'une fonction définie comme retournant un entier entre 1 et 366, l'analyse statique peut te dire que ton tableau peut être dépassé. Et ne rien dire (normal) si tu utilises 366 valeurs.
                      Tu vas me dire que ce n'est pas vraiment "inconnu" à la compilation, du coup. C'est pas faux, mais parfois ça peut être plus dur à détecter. Là c'est un exemple simple, car tout le monde sait qu'il peut y avoir 366 jours dans une année, mais parfois ça peut être plus compliqué (par exemple quand tu fais des calculs d'angles et que tu es persuadé que ton angle est dans [0, 90[ alors qu'il est dans [0, 90] (mais ça ne te saute pas aux yeux car ton angle a été transformé 42 fois dans un algo), ou des choses comme ça. Un outil d'analyse statique peut détecter ce genre de problème (si c'est basé sur des langages t'encourageant à définir les bornes d'entrée/sortie des fonctions ou procédures)

                      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à 2.

                      Ton programme de preuve pourrait détecter que rien ne borne ton index et donc que tu as potentiellement un trou. Il pourrait déduire des bornes en détectant des tests ou un modulo sur l'élément.

                      "La première sécurité est la liberté"

                      • [^] # Re: Chacun son style

                        Posté par  (site web personnel) . Évalué à 3.

                        C'est d'ailleur ce que font les runtimes un peu malin, celui de .NET détecte très bien le test d'une boucle for du genre :
                        for(int i = 0; i < tab.Length; i++)
                        ...
                        Et il supprime la vérification des bornes lors de l'accès au tableau.
                        http://blogs.msdn.com/b/clrcodegeneration/archive/2009/08/13/array-bounds-check-elimination-in-the-clr.aspx

                        Après, sauf à faire du calcul intensif, le gain est minime voir insignifiant :
                        http://blogs.msdn.com/b/ricom/archive/2006/07/12/663642.aspx

                        • [^] # Re: Chacun son style

                          Posté par  (site web personnel) . Évalué à 1.

                          Après, sauf à faire du calcul intensif, le gain est minime voir insignifiant :

                          A la base, je n'ai pas dit le contraire. Ce que j'essaye de faire comprendre, c'est qu'à force de "protéger" le programmeur, on ne peut pas faire certaines choses utiles (dans 99.99% des cas c'est peanuts, reste le reste, pourquoi dois-je changer de langage pour ce cas précis si j'en ai besoin plutôt que d'avoir le choix?)

                          J'aime bien avoir le choix (que j'utilise plus ou moins bien certes), Java ne m'en laisse que très peu (pour troller : j'ai l'impression d'être sous Mac OS ou Gnome).

                          • [^] # Re: Chacun son style

                            Posté par  (site web personnel) . Évalué à 5.

                            Donc tu préfères utiliser 100% du temps le même language, quitte à avoir 100% de ses inconvénients sans aucun des avantages dans 99,9% des cas :)
                            Nan mais pkoi pas, t'assumes c déjà bien :)
                            Sinon tu as des alternatives entre les 2, qui te laisse jouer avec des void * après avoir indiqué au compilo que t'étais un warrior avec un -unsafe, mais je citerai pas de nom au risque de réveiller un autre troll ;)

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 3.

                    Cf. la réponse de brendel pour les problèmes de bornes.

                    Fortran ET C sont de relativement bas niveau. Les deux forcent le programmeur à faire attention à ce qu'ils font pour (presque) chaque ligne de code. Cependant, Fortran propose EN PLUS des construction spécifiques pour le calcul (addition de vecteurs, etc). J'aurais pu être plus explicite, il est vrai.

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 2.

                      oui en même temps le programmeur qui ne fait pas attention aux lignes qu'il écrit, je me demande ce qu'il écrit.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 2.

                        Certes, mais dans un cas tu dois te soucier de l'impact de ton code sur la machine (genre le C range les données par ligne pour les tableaux 2D, alors que le Fortran le fait par colonne), dans l'autre (Java, C#, etc.), tu devras sans doute t'y intéresser à terme si tu veux de vraies perfs, mais sans doute pas aussi vite.

                        De plus, C et Fortran peuvent compiler sans pour autant être toujours capables de t'avertir de tous les problèmes potentiels que des langages tels que Java ou C# ou autres détectent. Et dans un cas (C/Fortran) je peux avoir une exécution erronée alors que dans l'autre le compilateur n'aurait simplement pas accepté de compiler.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 3.

                        du PHP !

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 1.

              En sécurité, il faut des garanties. Et permettre au programmeur de faire des conneries (comme ne pas utiliser la STL quand c'est possible), c'est la garantie d'avoir des programmes qui partent en prod avec les dites conneries.

              Et il y a pleins de contexte où la STL n'est pas utilisable.

          • [^] # Re: Chacun son style

            Posté par  . Évalué à 4.

            En même temps dans un langage objet utiliser les indices sur un tableau c'est pas forcément le plus courant. Les itérateurs et/ou l'utilisation de structure de données adéquate permet de ne pas avoir se genre de problématique dans beaucoup de cas (beaucoup ça veut pas dire tous, ça veut dire un nombre non négligeable de fois).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Chacun son style

              Posté par  . Évalué à -4.

              Donc, si j ai bien tout lu et compris, l avantage de java c est que les securitees sont dans la JVM et donc qu un mauvais dev peut coder, alors qu en C il faut quelqu un qui utilise son cerveau pour sortir un programme fonctionnel. C est pour ca que les etudes sont de plus en plus simples alors ? ca sert a rien d etre doue, java corrige les conneries ?

              Je suis aussi amuse de lire "en C/C++ t as des soucis de BOFs". Ah bon ? pourtant je code en C tous les jours (bon, ok, parfois c est seulement du lundi au vendredi, et parfois je suis en conges). C est soit une etourderie, soit le fait d une meconnaissance du langage, et non un probleme du langage!

              C est limite si certains tenteraient pas de nous dire qu on peut pas coder en C car c est trop difficile! Mince, comment on a fait jusque la alors ?

              J imagine aussi qu a cette adresse on nous ment : http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java

              Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!

              Mais bonne blague tout cela.

              • [^] # Re: Chacun son style

                Posté par  (site web personnel) . Évalué à 3.

                J'ai fait beaucoup de C, si tu ne fais pas de gros calcul, je te conseil de passer à ocaml. C'est incroyable le gain de productivité.

                "La première sécurité est la liberté"

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 3.

                Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!

                argument simpliste ! la gestion de la mémoire peut devenir plus ardue à cause de la complexité du programme ou à cause du parallèlisme qui échappent tous deux très facilement au "premier venu"...

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à -2.

                  Il suffit de savoir structurer son programme ...
                  C est sur que si on ne respecte aucune rigueur, on obtient de la bouillie. Mais c est comme ca partout, pas juste en informatique ...

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 1.

                Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!

                Je suis sûr que même en assembleur on s'y retrouve facilement. Pourquoi s'embêter avec des langages structurés ? Le premier venu qui connaît BOUND sait éviter les BOFs !

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 3.

                  Je suis plutôt d'accord (même si toutes tes réponses dans les commentaires de cette dépêche ont tendance à être un chouïa trop agressifs à mon gout...). Hors domaines extrêmement spécifiques comme l’embarqué [1], le calcul haute performance [2], et dans une certaine mesure les jeux vidéo [3], le reste du temps, je préfère des langages qui me garantissent plus de choses que ce que C et C++ offrent. J'adore le C, j'aime bien le C++, mais c'est parce que j'ai un coté bidouilleur (et que je bosse dans le HPC, donc C+assembleur c'est assez fréquent). Par contre bizarrement, quand j'ai du traitement de chaines a faire de façon un peu intelligente, ou bien d'autres petits traitements (sur potentiellement de gros volumes de données), je ne sais pas vous, mais je préfère quand même bien plus des langages de plus haut niveau ou en tout cas qui vont me permettre de réduire mon temps de développement (grâce a une bonne analyse statique, parce que le langage lui-même propose des constructions de haut-niveau tels que des tables de hachage, des tableaux dynamiques, etc.).

                  Le C et le C++ ne devraient être utilises selon moi que si la performance est un enjeu critique pour la majorité de l'application. Dans l’idéal bien sûr, on voudrait de la performance partout. En pratique, optimiser un bout de code pour une architecture particulière peut prendre des semaines, voire des mois. Et à, c'est en supposant qu'on est certain que l'algo utilise est le meilleur pour la tache donnée (et dans un contexte donnée).

                  [1] Je parle vraiment de matériel avec juste "une" tache bien spécifique a réaliser (avec des contraintes de puissance de calcul et d'espace mémoire drastiques), pas un machin qui peut se permettre d'avoir une JVM embarquée...
                  [2] Par calcul haute performance, je pense au traitement vidéo, a diverses simulations en physique et chimie, a l'utilisation de gros calculs mathématiques (par exemple de l’algèbre linéaire creuse ou dense), mais aussi au parcours de graphes en parallèles.
                  [3] Dans une certaine mesure parce qu'une bonne partie est réalisée a l'aide de langages de scripts customisés pour un moteur donné.

                  • [^] # Re: Chacun son style

                    Posté par  (site web personnel) . Évalué à 10.

                    Fais péter la RAM!
                    Si je devais remplacer chacun des programmes graphiques que j'utilise par une version Java, je crois que je devrais m'acheter quelques barrettes mémoires de plus. Un navigateur web en Java, ça prendrait combien de mémoire? Déjà que ceux écrits en C++ sont assez gourmand pour chaque onglet ouvert, alors avec une version java...
                    Rajoutons sur le bureau le lecteur de mail en Java, le lecteur de musique en java, le client de messagerie instantanée en java, le client bittorrent en java (j'ai longtemps utilisé Azureus), le tout en gardant le même nombre de fonctionnalités ça va commencer à faire beaucoup.

                    J'ai pendant pas mal d'années développé en C++. Dire qu'à l'époque je pleurais sur la lourdeur de Visual C++/Studio. Maintenant je suis sous Netbeans (que je trouve très très pratique), et je suis passé à un niveau supérieur de lourdeur.

                    Pour moi, les softs développés en Java sont beaucoup plus un confort pour le développeur que pour l'utilisateur.

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 6.

                      Je suis bien d'accord. :) Cela étant dit, je parlais de langages de plus haut niveau en général, pas uniquement de Java (Perl, Ruby, Python, etc. sont pour moi de bons candidats).

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à -4.

                      Dire qu'à l'époque je pleurais sur la lourdeur de Visual C++/Studio. Maintenant je suis sous Netbeans (que je trouve très très pratique), et je suis passé à un niveau supérieur de lourdeur

                      En même temps Visual Studio est lourd pour rien, c'est à peine mieux qu'un éditeur de texte!

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                      • [^] # Re: Chacun son style

                        Posté par  (site web personnel) . Évalué à 6.

                        En même temps Visual Studio est lourd pour rien, c'est à peine mieux qu'un éditeur de texte!

                        T'as pas essayé de visual studio depuis combien d'années ?

                        • [^] # Re: Chacun son style

                          Posté par  (site web personnel) . Évalué à -2.

                          Depuis la semaine dernière :-)

                          Et je maintiens: à côté des fonctionnalités de Netbeans ou d'Eclipse, Visual C++, c'est de la daube en plastique.

                          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                      • [^] # Re: Chacun son style

                        Posté par  (site web personnel) . Évalué à 5.

                        En même temps Visual Studio est lourd pour rien, c'est à peine mieux qu'un éditeur de texte!

                        Que dire des IDE sous Linux alors... (bon, qui est le premier à me vanter emacs?)

                        Faudrait un minimum se renseigner sur la concurrence et ne pas se la ramener sur un des produits les plus appréciés justement car complet, contrairement aux IDE sous Linux.

                        • [^] # Re: Chacun son style

                          Posté par  . Évalué à 4.

                          C'est pas du tout intégré à la Netbean/eclipse/VisualStudio, mais geany est vraiment bien. Au lieux de chercher à tout faire il s'interface avec d'autres outils. Ça demande un chouilla plus de configuration (mais c'est plus simple) et il manque encore beaucoup de choses comme le refactoring (faut tout de même faire gaffe avec le refactoring parce qu'on a vite fais de dupliquer du code et/ou mal structuré son code), mais il est tout de même intéressant.

                          Ensuite pour les vrais concurent il y a KDevelop et QDevelop qui sont pas si mauvais.

                          (il n'en reste pas moins que vim les dépasse tous)

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Chacun son style

                          Posté par  . Évalué à 6.

                          Moi la dernière fois que j'ai cherché à l'utiliser (vs2010), y avais une indentation de merde qui marchait pas, c'était chiant pour splitter des fenêtres (surtout si tu veux des fenêtres de 80 de largeur), y avais aucune intégration avec git/mercurial, et je suis même pas sûr qu'il y avais ne serait-ce que cvs ou svn, et les options des projets restent comme d'habitude complètement imbitables (surtout sous windows ou linker est une vraie galère) et mal organisé avec encore leur séparation minable debug-release ou par défault tu n'en configure qu'un seul des deux. Sans parler de la gestion chiante des fichiers (impossible d'arriver à lui faire respecter l'arbo du système de fichier !) et de l'importation (si tu veux importer 500 fichiers .h++/.c++ qui n'ont pas de projet ... ben t'est foutu. bonne chance pour lui faire bouffer du .c++/.h++ en tant que "source C++" et "header C++" sans devoir lui dire pour chaque fichier).

                          Sans oublier le système d'aide qui est tellement évolué avec des services qui se lancent en tâche de fond ... tout ça pour qu'au final il t'affiche une erreur ! Et puis oui, l'éditeur de texte, qui ne vaut pas mieux qu'un bête notepad++ (ne parlons pas d'Emacs/vim), et encore, notepad++ à une recherche incrémentale utile il me semble. Sinon sur les avantages que devrai pouvoir sortir un IDE, la fonction "rechercher la définition" qui me trouve des définitions qui ne sont dans des classes ayant rien à voir avec même pas le même nombre d'argument, et qui au final ne trouve même pas la bonne dans le lot. La completion de code C++ qui veut me compléter des méthodes après un point en prenant tout les noms de classes existants (même s'ils appartiennent à des librairies windows alors que je fait du C++03 pur)

                          Après je pourrai râler sur bien d'autres choses spécifique à la gestion du C++ dans VS, mais ça serait spécifique et non général. Et pour le peu de C# que j'ai fait, monodevelop >>>>>> VSC#

                          • [^] # Re: Chacun son style

                            Posté par  . Évalué à 2.

                            y avais aucune intégration avec git/mercurial, et je suis même pas sûr qu'il y avais ne serait-ce que cvs ou svn

                            Ce genre de truc se fait a travers des plugins, http://www.visualsvn.com/ par exemple.

                            et les options des projets restent comme d'habitude complètement imbitables (surtout sous windows ou linker est une vraie galère) et mal organisé avec encore leur séparation minable debug-release ou par défault tu n'en configure qu'un seul des deux.

                            Tu assumes totalement si tu n'en configures qu'un des deux, il est tout a fait possible de changer les parametres dans toutes les config a la fois d'un coup.

                            Sans parler de la gestion chiante des fichiers (impossible d'arriver à lui faire respecter l'arbo du système de fichier !)

                            Ca veut dire quoi ca ? J'ai rien compris, j'ai jamais eu de problemes a lui faire creer les fichiers la ou je veux ou lui faire ajouter des fichiers existants sans qu'il les recopie ailleurs.

                            et de l'importation (si tu veux importer 500 fichiers .h++/.c++ qui n'ont pas de projet ... ben t'est foutu. bonne chance pour lui faire bouffer du .c++/.h++ en tant que "source C++" et "header C++" sans devoir lui dire pour chaque fichier).

                            Tools -> Options -> Projects & Solutions -> VC++ Project Settings -> C/C++ File Extensions

                            On va dire que tu connais VStudio assez mal...

                            • [^] # Re: Chacun son style

                              Posté par  . Évalué à 1.

                              Ce genre de truc se fait a travers des plugins

                              Désolé... Moi je croyais qu'un logiciel prenant autant de place que deux DVD Debian n'avais pas besoin de plugin, puisque pour que ça prenne cette taille c'est que ça devait intégrer tout ce qui existait sur terre ...

                              Et puis SVN ça va bien 5 minutes, et de ce que j'en lis, VS n'est pas adapté aux workflow des SCM distribués. On dirait Eclipse et son plugin pour Git, qui est complètement imbitable que même linus torvalds ne retrouverai pas ses petits.

                              Tu assumes totalement si tu n'en configures qu'un des deux, il est tout a fait possible de changer les parametres dans toutes les config a la fois d'un coup.

                              Ça c'est quand c'est moi qui fait la config, et encore, c'est tellement chiant de devoir resélectionner toujours l'option que parfois j'oublie. Et si c'est pas moi, mais quelqu'un d'autre et qu'il ne fait pas gaffe ...
                              Franchement, ou est la justification du fait de séparer les deux complètement ? La conffe de développement est si différente de la conffe de prod ?

                              Tools -> Options -> Projects & Solutions -> VC++ Project Settings -> C/C++ File Extensions

                              Manifestement à l'époque ou je l'utilisait (y a 6 mois), je t'avais pas attendu pour trouver ce menu, puisque j'y vois un c++ et h++ dedans... Bien sur, après c'est reconnu comme source C++, mais ça veut pas pour autant le compiler. À la place ça me met une erreur bien flippante du genre "t'a tout merdé, réinstalle!". On sens le logiciel de qualité !

                              • [^] # Re: Chacun son style

                                Posté par  . Évalué à 3.

                                Désolé... Moi je croyais qu'un logiciel prenant autant de place que deux DVD Debian n'avais pas besoin de plugin, puisque pour que ça prenne cette taille c'est que ça devait intégrer tout ce qui existait sur terre ...

                                Deux DVD Debian ? Marrant, mon install ne prend pas autant de place...

                                Et puis SVN ça va bien 5 minutes, et de ce que j'en lis, VS n'est pas adapté aux workflow des SCM distribués. On dirait Eclipse et son plugin pour Git, qui est complètement imbitable que même linus torvalds ne retrouverai pas ses petits.

                                Les SCM distribues j'en sais rien je les ai jamais utilises, pour les autres c'est totalement utilisable avec le plugin approprie, on ne fait que ca en interne.

                                Ça c'est quand c'est moi qui fait la config, et encore, c'est tellement chiant de devoir resélectionner toujours l'option que parfois j'oublie. Et si c'est pas moi, mais quelqu'un d'autre et qu'il ne fait pas gaffe ...
                                Franchement, ou est la justification du fait de séparer les deux complètement ? La conffe de développement est si différente de la conffe de prod ?

                                Absolument oui, par exemple :
                                - T'as des #define definis uniquement pour le mode DEBUG qui ralentissent le produit mais facilitent enormement le debuggage (cherche _ITERATOR_DEBUG_LEVEL dans STL pour un exemple)
                                - T'as pas forcement envie que les actions post-builds balancent tes binaires au meme endroit (machine de test, etc...)
                                - Si tu link des binaires entre eux avec interfaces C++, tes modes debug et release doivent cibler des binaires differents car ces binaires seront differents
                                etc...

                                Manifestement à l'époque ou je l'utilisait (y a 6 mois), je t'avais pas attendu pour trouver ce menu, puisque j'y vois un c++ et h++ dedans... Bien sur, après c'est reconnu comme source C++, mais ça veut pas pour autant le compiler. À la place ça me met une erreur bien flippante du genre "t'a tout merdé, réinstalle!". On sens le logiciel de qualité !

                                Une fois que tu m'auras montre que le probleme est situe dans le produit (c'est repetable, etc...) je penserais a cibler le produit, d'ici la je continuerai a penser, en ayant lu ce que tu connais de VStudio, que le probleme est sur la chaise...

                                • [^] # Re: Chacun son style

                                  Posté par  . Évalué à 2.

                                  Deux DVD Debian ? Marrant, mon install ne prend pas autant de place...

                                  Je ne sais pas pour l'install (la flemme d'aller voir) mais mon ISO de Visual Studio 2008 Professional fait 3,5 Go. Certes, c'est pas deux DVD, mais c'est quand même très gros.

                                  • [^] # Re: Chacun son style

                                    Posté par  . Évalué à -1.

                                    Si tu installes absolument tout ca va certainement prendre bcp de place mais je connais peu de gens qui ont besoin des outils de dev pour embedded, pour VB, pour C#, pour C++, pour Office, pour SQL, etc... avec toutes les sous-options.

                                    • [^] # Re: Chacun son style

                                      Posté par  (site web personnel) . Évalué à 0.

                                      Pour que le soft soit aussi gros, il faut que toutes les library soit en 12 000 exemplaires. 3.5Go de binaires, cela représente des milliards de lignes de code.

                                      "La première sécurité est la liberté"

                                      • [^] # Re: Chacun son style

                                        Posté par  . Évalué à 3.

                                        bwarf. on a des librairies en plusieurs versions (dont debug), on a des docs diverses en plusieurs formats, et on a enfin des exemples et autres ressources avec plein d'images, d'icones et autres modèles 3D, textures ou dump de bases de données.

                                        on aurait la même chose sous n'importe quel SDK équivalent sous GNU/Linux, faut chercher la petite bête ailleurs

                                      • [^] # Re: Chacun son style

                                        Posté par  . Évalué à -1.

                                        Il y a plein de choses sur ce DVD: des symboles de debuggage par exemple, de la doc dans plusieurs langues, du code source, le platform SDK qui comprends les headers et les .lib pour l'OS, etc... l'IDE et le compilo ne sont qu'une petite partie du DVD.

                          • [^] # Re: Chacun son style

                            Posté par  (site web personnel) . Évalué à -1.

                            Voilà quelqu'un qui parle d'expérience!

                            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                            • [^] # Re: Chacun son style

                              Posté par  (site web personnel) . Évalué à 7.

                              Comme souvent quand un Linuxien parle de la concurrence, il trouve tous les défauts (dont la plupart existent mais qu'il n' a pas voulu chercher 10 secondes alors que sous son IDE préféré, il a passé plusieurs heures à le comprendre) et oublie aussi les défauts de son poulain.

                              Car pour moi si il faut aller dans les superlatifs, à côté des fonctionnalités de Visual C++, Netbeans ou d'Eclipse c'est de la daube en plastique. D'ailleurs, bizarrement, Visual C++ (payant) est énormément utilisé sous Windows alors que Netbeans et Eclipse sont aussi disponibles (gratuitement!), et la, il n'y a pas de vente liée comme excuse... Faudrait un peu regarder objectivement la concurrence pour comprendre pourquoi c'est vendu non? Accuser les gens d'être stupide c'est plus simple, mais ça ne les fera pas changer d'avis.

                              • [^] # Re: Chacun son style

                                Posté par  . Évalué à 5.

                                Il n'y a pas la vente liée comme excuse, mais il y a la compatibilité binaire. Je me souviens avoir écrit des plugins pour Maya sous Visual, là où tout les autres dèvs utilisaient Eclipse, simplement parce que si on n'utilisait pas le compilo Visual, les plugins ne marcheraient pas. C'est certes pas de la vente liée, mais c'est bien une situation où on n'a pas trop le choix.

                              • [^] # Re: Chacun son style

                                Posté par  . Évalué à 2.

                                bizarrement, Visual C++ (payant) est énormément utilisé sous Windows alors que Netbeans et Eclipse sont aussi disponibles (gratuitement!)

                                Tu as des chiffres ? Parce que ça m’intéresserais. J'ai pas vu un VS depuis 4 ans alors qu'eclipse/netbeans/intlliJ j'en vois régulière (et non pas nécessairement pour faire du Java, la plupart des fois c'est pour faire du PHP (je ne sais pas ce qu'ils y gagnent face à un éditeur de texte)). La seule fois que j'ai touché à VS c'était pour faire du C# (et monodevelop était réellement instable (c'est lui qui m'a appris à faire du ctrl+s à tout va)).

                                Donc vraiment je ne connais pas VS (je ne sais pas s'il peut être utile au développeurs Java) et mal la concurrence (je ne connais pas les fonctionnalités offertes par les eclipse/netbeans pour faire autre chose que du Java), mais je trouverais intéressant d'avoir des stats sur leur part de marché respective.

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: Chacun son style

                                  Posté par  . Évalué à 1.

                                  A mon avis ces comparaisons n'ont pas trop de sens. L'IDE utilise va bcp varier selon le langage, bref t'auras plus une estimation des parts de langages qu'autre chose.

                                  C++ ou C# ? A peu pres tout le monde utilise Visual Studio sous Windows
                                  Java ? Ca sera Eclipse/netbeans, Visual Studio ne gere pas Java par defaut donc faudrait etre un peu dingue pour se faire chier a le customiser et l'utiliser la.

                                  • [^] # Re: Chacun son style

                                    Posté par  (site web personnel) . Évalué à -2.

                                    Le débat a dévié: on comparait les qualités d'IDE entre Visual Studio pour du C++ et Netbeans/Eclipse pour du Java.

                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                    • [^] # Re: Chacun son style

                                      Posté par  (site web personnel) . Évalué à 5.

                                      Heureusement que le débat à dévié, comparer deux IDE pour deux langages différents n'a aucune pertinence tellement les capacités de l'IDE sont intimement liées aux langages.
                                      Donc comparer les qualités de Visual Studio pour du C++ et Netbeans/Eclipse pour du Java c'est juste du grand n'importe quoi !

                                      Donc si tu veux vraiment, compare VS et Eclipse sur du C++, on commencera à rigoler.
                                      Et compare VS en C# et Eclipse/Netbeans en java (c'est pas les même langage mais c'est comparable).

                                      Mais mélanger les deux c'est vraiment faire preuve de mauvaise foi.

                                      • [^] # Re: Chacun son style

                                        Posté par  (site web personnel) . Évalué à 2.

                                        Mais mélanger les deux c'est vraiment faire preuve de mauvaise foi.

                                        Non, c'est juste être pro: quand on choisit une plateforme de développement, on prends en compte le langage et les outils.

                                        On n'utilise pas de clou sans marteau.

                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                        • [^] # Re: Chacun son style

                                          Posté par  (site web personnel) . Évalué à 3.

                                          non non, comparer deux ide dans des langages totalement différent c'est faire preuve de mauvaise foi.

                                          Si tu veux être pro (vu la question) dans ce cas tu compare langage + ecosystem + IDE + outils + ...
                                          Mais pas VS en C++ et Eclipse en Java.
                                          D'ailleurs pourquoi dans ce cas ne pas parler de Eclipse en C++ ? C'est totalement idiot si le but est de choisir une plateforme de développement.

                                          On n'utilise pas de clou sans marteau.

                                          Non, mais pour pour choisir entre clou et goupille on ne compare pas marteau et maillet.

                                          • [^] # Re: Chacun son style

                                            Posté par  (site web personnel) . Évalué à 2.

                                            Si tu veux être pro (vu la question) dans ce cas tu compare langage + ecosystem + IDE + outils + ...

                                            Je ne dis pas autre chose! Et là dessus, il faut être honnête: le monde Java vient avec de meilleurs outils, des temps de compilation très faibles, de meilleurs IDE, plus de documentation, plus bibliothèques et plus de développeurs recrutables maîtrisant le tout...

                                            Après la plateforme a des défauts (performance d'exécution, occupation mémoire, Oracle), mais largement compensés par le confort offert aux développeurs et c'est ça la clé du succès de Java en entreprise.

                                            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                            • [^] # Re: Chacun son style

                                              Posté par  (site web personnel) . Évalué à 1.

                                              Donc pourquoi ne pas comparer Visual Studio C++ et Eclipse C++ ?
                                              En voulant comparer VS C++ et Eclipse Java tu biaise volontairement ton comparatif dans le sens qui t'intéresse il me semble...

                                              • [^] # Re: Chacun son style

                                                Posté par  (site web personnel) . Évalué à 3.

                                                Tu lis un peu les réponses qu'on te fait ou bien?

                                                Le comparatif c'est Java vs C++, pas Visual Studio vs Eclipse.

                                                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                • [^] # Re: Chacun son style

                                                  Posté par  (site web personnel) . Évalué à 2.

                                                  (je voulais répondre avec un ton très linuxfr, mais je suis d'humeur cordiale ce matin...)

                                                  https://linuxfr.org/nodes/86730/comments/1252588

                                                  on comparait les qualités d'IDE entre Visual Studio pour du C++ et Netbeans/Eclipse pour du Java

                                                  Donc :

                                                  • Visual Studio pour C++
                                                  • Netbeans/Eclipse pour du Java

                                                  C'est bien toi qui a recentré le débat sur ça, non ?
                                                  Donc non, c'est pas Java vs C++...

                                                  • [^] # Re: Chacun son style

                                                    Posté par  (site web personnel) . Évalué à 2.

                                                    Recentré oui, c'est donc bien que "certains" ont dévié... Mais si tu veux discuter d'un autre sujet, créé un journal sur les IDE C++!

                                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                    • [^] # Re: Chacun son style

                                                      Posté par  (site web personnel) . Évalué à 2.

                                                      Tu lis un peu les réponses qu'on te fait ou bien?
                                                      Le comparatif c'est Java vs C++, pas Visual Studio vs Eclipse.

                                                      C'est bien toi qui a recentré le débat sur [VS C++ contre Eclipse Java], non ?

                                                      Recentré oui

                                                      Donc on est bien d'accord sur l'incohérence de ta critique.

                                                      Mais sinon, merci pour la leçon, mais dans ce cas si tu veux comparer des plateformes de dev crée un journal car c'est une news sur la genèse de java pas sur Java vs C++.
                                                      Ou alors on continue comme ça, et c'est tant mieux.

                                                      • [^] # Re: Chacun son style

                                                        Posté par  (site web personnel) . Évalué à 1.

                                                        Donc on est bien d'accord sur l'incohérence de ta critique.

                                                        Non, mais de toute façon, tu ne lis que ce que tu veux lire alors arrêtons là et bonne nuit!

                                                        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                                                        • [^] # Re: Chacun son style

                                                          Posté par  (site web personnel) . Évalué à 1.

                                                          Indique alors ce que je n'ai pas lu (ou mal lu) car là j'ai justement cité les messages et leur enchaînement et j'aimerais bien savoir ce que je n'ai pas capté...

                                        • [^] # Re: Chacun son style

                                          Posté par  . Évalué à -1.

                                          quand on choisit une plateforme de développement, on prends en compte le langage et les outils.

                                          L'ide est souvent là pour compenser les faiblesses du langage. Autocompletion pour les langages trop verbeux, auto indentation pour python, correction de syntaxe à la volée pour syntaxe trop $;]}, accès rapide à la doc quand c'est pas intuitif...

                                          • [^] # Re: Chacun son style

                                            Posté par  (site web personnel) . Évalué à 4.

                                            Autocompletion pour les langages trop verbeux [...]

                                            Ca n'est absolument pas une faiblesse du langage, au contraire, c'est la nature du langage qui permet d'obtenir une autocomplétion intuitive, par exemple si je tapes :

                                            objet.
                                            • L'autocomplétion va me proposer l'ensemble des méthodes/propriétés accessible sur l'objet
                                            • L'accès rapide à la doc va m'afficher une courte phrase décrivant la méthode

                                            • [^] # Re: Chacun son style

                                              Posté par  . Évalué à 1.

                                              Autocompletion pour les langages trop verbeux [...]

                                              Ca n'est absolument pas une faiblesse du langage, au contraire, c'est la nature du langage qui permet d'obtenir une autocomplétion intuitive

                                              Simplement, plus il y a du texte à taper plus ça devient indispensable. En python je n'utilise jamais d'autocompletion (je pourrai), en java tout le temps... C'est juste une constatation, quand je programmais en Java j'avais besoin d'un ide le plus sophistiqué possible, en python j'utilise vim avec très peu de plugins et pourtant c'est pour exactement les mêmes programmes (réécris). Par contre je ne pourrai pas utiliser Python sans un ide avec l'auto-indentation.

                                              • [^] # Re: Chacun son style

                                                Posté par  (site web personnel) . Évalué à 3.

                                                Tout dépend de l'ampleur de tes projets. Pour un petit script, pas besoin d'une grosse artillerie. Pour un gros projet impliquant des dizaines de développeurs sur plusieurs années, la complétion et des outils de refactoring, ça fait gagner du temps.

                                                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                              • [^] # Re: Chacun son style

                                Posté par  (site web personnel) . Évalué à 0.

                                D'ailleurs, bizarrement, Visual C++ (payant) est énormément utilisé sous Windows alors que Netbeans et Eclipse sont aussi disponibles (gratuitement!), et la, il n'y a pas de vente liée comme excuse...

                                C'est bien connu que succès égale qualité. Le gendarme à Saint Tropez étant plus rediffusé que Citizen Kane, on voit bien que c'est une oeuvre majeure du cinéma.

                                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                      • [^] # Re: Chacun son style

                        Posté par  (site web personnel) . Évalué à 8.

                        En même temps Visual Studio est lourd pour rien, c'est à peine mieux qu'un éditeur de texte!

                        Ça sent le troll.

                        Visual Studio a toujours eu (enfin, au moins depuis la version 5 sortie il y a 15 ans) un debugger C++ infiniment meilleur que tout ce que j'ai testé par ailleurs (libriste convaincu, ça me fait mal au cœur). Rapidité incroyable par rapport à gdb, tellement plus agréable à utiliser et moins plantogène que les fronts-end de gdb (à l'époque: DDD, xxgdb, insight). J'ai essayé KDevelop récemment, il y a du mieux mais on en est encore loin.

                        Je n'ai jamais pu me faire aux makefiles. Je préfère un truc basique mais très pratique à utiliser. Taper les noms de fichiers du projet à la main, non merci.

                        L'éditeur de texte depuis très longtemps peut se scripter en VBscript (un langage pourri, mais supportable pour les trucs simple). J'ai écrit un bon nombre de macros qui me simplifient énormément la vie. La doc des objets Visual Studio est bien organisée.
                        On peut enregistrer les macros (ce qui génère du VBscript), ce qui peut être une bonne base.
                        On peut écrire des plugins en C++ sans trop de difficulté. J'en ai écrit un qui permettait de scripter Visual C++ en Python (mes fonctions Python étaient visibles comme des plugins ou des scripts). J'étais assez fier de moi et c'était très pratique.
                        Dans les versions récentes, on peut faire des plugins en C# (ce qui est un peu moins risqué que du C++).
                        On peut piloter Visual Studio depuis un programme externe car il est vu comme un objet COM.

                        Bref, pas d'accord.

                        • [^] # Re: Chacun son style

                          Posté par  (site web personnel) . Évalué à -1.

                          Ça sent le troll.

                          Essaye un jour de faire du java avec Netbeans ou Eclipse et tu verras la différence avec du C++ et Visual Studio: une complétion qui marche, un debugger plus évolué, du refactoring, mille fois plus de plugins, une bonne intégration des gestionnaires de version, des assistants pour corriger les erreurs de compilation...

                          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                          • [^] # Re: Chacun son style

                            Posté par  (site web personnel) . Évalué à 5.

                            dans ce cas, faudrait ptetre comparer :

                            • C++ sous eclipse et C++ sous Visual Studio

                            ou

                            • Java sous eclipse et C# sous Visual Studio

                            Le résultat serait-il assurément le même ?

                            En C# j'ai pas le souvenir d'avoir eu des problèmes de complétion par exemple (note : c'était il y a qq années de manière importante, aujourd'hui c'est rare que j'ouvre mon Visual Studio mais ça m'arrive quand même)

                            mille fois plus de plugins

                            et combien qui ne sont pas finis / mal fait / ... ?

                            une bonne intégration des gestionnaires de version

                            cvs je sais pas, svn ok (enfin sauf lorsque après un update les raccourcis claviers ne fonctionnent plus), mercurial ok. Git c'est pas encore ça...
                            Sous VS ? ben cvs tu peux, svn tu peux, mercurial tu peux, git je crois mais pareil, je pense que c'est pas encore ça.

                            Finalement c'est pas si différent...

                          • [^] # Re: Chacun son style

                            Posté par  (site web personnel) . Évalué à 4.

                            mille fois plus de plugins,

                            Voila : tu parles de quantité, comme un collectionneur. Les autres utilisent, donc cherche de la qualité.

                            En plus, hop, tu mélanges deux langages pour noyer le poisson. Si tu compares, compare des choses sans changer deux paramètres dans ta comparaison, parce que la ça sent juste la comparaison foireuse dont tu sais quelle conclusion tu veux avoir (si tu veux un équivalent à Java, programme plutôt en C#. Sinon comparaire les possibilité en C++ commun... Aïe pour tes poulains)

                            • [^] # Re: Chacun son style

                              Posté par  (site web personnel) . Évalué à 3.

                              En plus, hop, tu mélanges deux langages pour noyer le poisson.

                              Non, le débat est C++ versus Java. Pourquoi faudrait-il "pardonner" à C++ d'avoir des IDE en carton? De bons outils de développement, ça compte autant que le langage lui même.

                              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                          • [^] # Re: Chacun son style

                            Posté par  . Évalué à 4.

                            Tu me montres un soft qui fait du refactoring en C++ correctement ? Ah oui ca n'existe pas...

                            Et le refactoring de VStudio pour C#, t'en penses quoi ?

                          • [^] # Re: Chacun son style

                            Posté par  (site web personnel) . Évalué à 2.

                            Essaye un jour de faire du java avec Netbeans ou Eclipse

                            Merci, j'utilise Netbeans tous les jours. J'ai vu la différence. Je me suis rendu compte aussi que ce n'était pas le même langage qui est ciblé. Donc si tu as mieux à me proposer pour du C++, n'hésite pas.
                            Pour ce qui est du debugger, il y a aussi TotalView qui fonctionne bien, qui est super pas-donné (quand tu dois passer par un commercial pour avoir un prix, il faut s'y attendre).

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à -2.

                  On peux tout a fait coder des gros projets en C.
                  Le faire en assembleur est bien plus delicat, notamment car les optims de gcc sont plus interessantes que notre capacite a optimiser le code.

                  Java ne fait pas cela. Java permet seulement de donner moins de boulot au dev, au detriment d une JVM et de perfs amoindries. Hors, chez moi (dev de softs pour des serveurs), ce compte c est que ce soit leger et rapide sans avoir besoin d un serveur a 10k€

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 0.

                Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!

                Avec snprintf() on peut aboutir a des buffer overflow lorsque la chaîne de formatage est mal contrôlée et que le hacker arrive a y insérer des %n.

                Quant à strncpy() si le programmeur ne pense pas au cas limite, la chaine produite peut ne pas contenir de \0 final.

              • [^] # Dépassement de tampon

                Posté par  . Évalué à 0.

                Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!

                Avec snprintf() on peut aboutir a des buffer overflow lorsque la chaîne de formatage est mal contrôlée et que le hacker arrive a y insérer des %n.

                Quant à strncpy() si le programmeur ne pense pas au cas limite, la chaine produite peut ne pas contenir de \0 final.

                • [^] # Re: Dépassement de tampon

                  Posté par  . Évalué à 2.

                  Oui c est vrai, mais ca me parait evident que si tu passes n importe quoi comme parametres a une fonction, tu obtiens n importe quoi, non ?

                  Si tu donnes a une fonction de formatage de la data non controlee, elle va formater n importe comment..

                  Si tu ne sait pas calculer la taille max d une chaine, forcement strncpy() ne t es pas d un grand secours, car il a besoin de toi pour compte le MAX ...

                  Si on en est a ce niveau la ... je pense qu il vaut mieux ne pas coder du tout.

                  • [^] # Re: Dépassement de tampon

                    Posté par  . Évalué à 4.

                    Si tu donnes a une fonction de formatage de la data non controlee, elle va formater n importe comment..

                    Ben, entre ça et ouvrir une brèche de sécurité, il y a un gouffre. Un problème du C, c'est qu'un bug peut très vite se transformer en faille.

                  • [^] # Re: Dépassement de tampon

                    Posté par  . Évalué à 4.

                    Tu n'as jamais eu de bug dans ton code ? T'as jamais eu un cas ou tu t'es rendu compte que t'as fait une connerie ?

                    Oui ? Ben bienvenue dans le monde de tous les developpeurs de cette planete. C'est comme ca que les failles se creent, dire "il suffit de" est juste un gag, parce que bon, je peux generaliser hein :

                    Il suffit de ne jamais faire d'erreur et c'est regle, c'est pourtant simple !

                • [^] # Re: Dépassement de tampon

                  Posté par  . Évalué à 1.

                  un programmeur normalement constitué lirait la doc et verrai ce qu'il faut faire pour éviter les buffer overflow avec ce genre de fonctions.

                  un programmeur débile fera toujours des choses débiles, quelque soit le langage utilisé

                  Si tu es si intéressé que ça par la validité d'un code, utilise ADA.

                  • [^] # Re: Dépassement de tampon

                    Posté par  . Évalué à 5.

                    Moi je te dirai plutot que tu n'as visiblement pas bcp d'experience du sujet.

                    Le nombre de failles causees par les fonctions type printf est enorme et nombre de gens s'y sont pris les pieds. Croire que seuls les developpeurs debiles se plantent et qu'il 'suffit' de lire la doc est un gros gag. Si c'etait si simple il n'y aurait jamais de bugs.

                    • [^] # Re: Dépassement de tampon

                      Posté par  . Évalué à -1.

                      La tres grande majorite des devs ne fait ni de tests unitaires, ni de fuzzing.
                      Certains devs reprennent du vieux code de personnes n ayant aucune notion de securite, et donc, rien n est controle.

                      Il n est pas si difficile de se proteger contre les attaques type BOF, mais ca demande de la rigueur.

                      En fait dans la majorite des cas, le dev ecrit, et attend que quelqu un lui montre la faille avant de comment a se poser des questions.

                    • [^] # Re: Dépassement de tampon

                      Posté par  . Évalué à -1.

                      Croire que seuls les developpeurs debiles se plantent et qu'il 'suffit' de lire la doc est un gros gag.

                      Je comprend mieux dans quelle optique ont été écrite les pages de documentation du MSND.

                    • [^] # Re: Dépassement de tampon

                      Posté par  . Évalué à 2.

                      mouais, ça fait juste une vingtaine d'années que je programme en C et je n'ai participé qu'à une vingtaine de projets open source, windows ou unix. Je manque en effet un peu d'expérience. Il faudra aussi que je mentionne devant mes étudiants en informatique que je n'ai pas beaucoup d'expérience.

                      Ironie à part (je déteste les gens qui se permettent un jugement de valeurs sans connaître la personne), la majorité des erreurs d'utilisation de ce type de fonction est la non lecture attentive de la doc. Je connais de bon programmeurs qui ne lisent pas correctement la doc et qui se plantent. Inversement, de piètres programmeurs qui font des efforts de lecture de doc et qui font de bonnes choses.

                      Alors, oui, je confirme, la lecture (évidemment une lecture attentive, car si c'est juste lire l'api, c'est insuffisant) de la doc suffit à éviter les erreurs avec snprintf et strncpy. Note que je n'ai parlé que de ces 2 fonctions. Libre à too de généraliser à toutes les fonctions que tu veux. Ca sera juste un hors sujet de ta part.

                      • [^] # Re: Dépassement de tampon

                        Posté par  . Évalué à 5.

                        Un bon programmeur ca se reconnait pas à la bio qu'il te sort pour te montrer la taille de sa bite, mais au fait qu'il a comprit qu'il n'est pas superman et qu'un truc difficile à comprendre/utiliser ça finissait un jour ou l'autre par te sauter dans les pâtes.

                        La lecture de la doc de strncpy suffit tellement que les petits gars d'OpenBSD se sont dit que ça serait une bonne chose d'inventer un truc plus compliqué, strlcpy, histoire de pouvoir distinguer les bons devs des mauvais devs. Ou alors non...

                      • [^] # Re: Dépassement de tampon

                        Posté par  . Évalué à 3.

                        mouais, ça fait juste une vingtaine d'années que je programme en C et je n'ai participé qu'à une vingtaine de projets open source, windows ou unix. Je manque en effet un peu d'expérience. Il faudra aussi que je mentionne devant mes étudiants en informatique que je n'ai pas beaucoup d'expérience.

                        Desole mon cher, mais sortir une ineptie pareille donne l'image que j'ai decrite. Il suffit de regarder les failles trouvees pendant des annees pour voir que non, lire la doc ne suffit pas, l'erreur est humaine et certains cas sont plus compliques que tu ne le penses (il n'est pas evident que le texte vient de l'exterieur, etc...)

                        • [^] # Re: Dépassement de tampon

                          Posté par  . Évalué à -3.

                          ok, les mecs. On m'insulte et on ne dit rien, je me défend et on m'enfonce. belle mentalité. Je me désinscrit immédiatement de ce site finalement inintéressant.

                          • [^] # Re: Dépassement de tampon

                            Posté par  (site web personnel) . Évalué à 2.

                            Les arguments d'autorité "moi je suis prof", comment dire...

                          • [^] # Re: Dépassement de tampon

                            Posté par  . Évalué à 1.

                            On peut avoir ton code avant que tu te désinscrives ?

                            J'offre la gloire éternelle à celui qui trouve une faille sur un BOF dans un de tes projets ;)

                          • [^] # Re: Dépassement de tampon

                            Posté par  . Évalué à 2.

                            Bienvenu sur Linuxfr ! (pourtant tu n’es pas un nouveau Oo)

                            Règle de base : ne jamais se défendre, attaquer. Quelqu’un met en doute tes compétences ? Ne jamais sortir ton pedigree, c’est une marque de faiblesse. Non, il faut faire de même. Attaquer, toujours. Et ne plus s’attendre à une discussion enrichissante.

                            Sinon tu peux laisser couler, garde ton compte, tu es tombé sur des durs de chez les durs. Tu n’es pas le premier et tu ne seras pas le dernier. Évite les, tout simplement… Le site est intéressant en soit, fait le tri et ignore les trolls (cette dépêche était un appeau). J’ai appris quelques petites choses sous cette dépêche, le compte apporte des avantages pour faire le tri. N’agit pas en fonction de quelques commentateurs : c’est leur accorder plus d’importance qu’ils n’ont et il auront gagnés. Si j’ai suivi le fil jusqu’ici, c’est exceptionnellement parce que le sujet m’intéresse plus particulièrement. Parce qu’il y a des gens comme toi qui viennent faire un commentaire pertinent, noyé dans la masse. N’accorde pas d’importance à ce que tu peux avoir comme réponse, prend les arguments que tu estimes valables, jettes aux orties le troll, et reste zen. -_-

                            Enfin tout ça pour pertinenter, j’aurai pu juste cliquer, mais l’effet n’aurait pas été le même je crois :) Mon commentaire a l’air celui d’un donneur de leçon, je me permets parce que je suis passé par là moi aussi…

                            • [^] # Re: Dépassement de tampon

                              Posté par  (site web personnel) . Évalué à 6.

                              ne jamais se défendre, attaquer.

                              En même temps c'est lui qui attaque : grosso modo, il y a 2 types de programmeurs (selon lui), les gens "normalement constitué", qui savent lire la doc et ne font jamais de conneries, et les autres.
                              Sachant que dans la vraie vie tout le monde fait des conneries de programmation, même les meilleurs, il prend tous les programmeurs (et beaucoup le sont par ici) pour des cons.
                              Donc oué logiquement on se dit qu'il a soit aucune expérience de la vraie vie de programmeur, soit qu'il est totalement imbu de sa personne et est persuadé d'être à l'abri des bugs. On demande logiquement à voir.

                              • [^] # Commentaire supprimé

                                Posté par  . Évalué à 6.

                                Ce commentaire a été supprimé par l’équipe de modération.

                                • [^] # Re: Dépassement de tampon

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Ce n'est absolument pas ce qu'il dit.
                                  Excuse moi, paraphrasons alors :
                                  "un programmeur normalement constitué lirait la doc [...]"
                                  "un programmeur débile fera toujours des choses débiles"

                                  Sur la forme c'est agressif voir insultant, et celà laisse trop de sous-entendu sur le fond.

                                  La forme de ce qui est dit n'est peut-être pas la bonne mais le message est le bon.

                                  Le problème, c'est que ce qu'on lit, c'est la forme, et le fond, c'est ce qu'on en déduit.

                                  En clair, si tu ne maitrises pas quelque chose : ne l'utilise pas.

                                  Ca c'est un message effectivement plus intelligent, mais ce n'est absolument pas celui qu'il a fait passer, même si c'est ce qu'il a voulu dire. Y'a un moment faut arrêter : se cacher derrière le "c'est pas ce que je voulais dire" c'est un peu trop facile, faut assumer.

                                  Par contre ne pas avoir lu la doc et après venir pleurer, cela fait de toi une sous-merde infâme.

                                  On peut aussi lire la doc, mal la comprendre, mal l'interpréter, avoir un moment d'égarrement, etc.
                                  Et c'est justement là qu'est le débat : le langage est tellement "dangereux" qu'il en devient inutilisable : pour écrire une ligne de code, il faut lire 1 doc, un man, un tutorial et prier pour que personne te traite de débile ou de sous-merde infâme.

                                  Quand on commence un post en déformant les propos

                                  C'est pas moi qui est opposé les programmeurs normalement constitué aux programmeurs débiles hein.

                                  Quels sont donc tes buts en faisant des attaques ad-hominem

                                  C'est l'hopital qui se fou de la charité ! T'as vu ce que tu es en train de balancer à mon propos ?

                                  qu'on s'efforce de détruire ce qui n'a jamais été dit

                                  Ce qui n'a jamais été dit, c'est ce que tu tentes d'expliquer dans ton commentaire. D'ailleur ses propos de 3 lignes était tellement "transparent" qu'il te faut un commentaire de 20 lignes pour tenter de l'expliquer.

                                  Qu'on remette les choses à leur place : j'essai juste d'expliquer les réactions "violentes" à son commentaire, en précisant bien que "on se dit que" : si les gens ont réagit par des attaques ad-hominem, c'est bien parcqu'ils se sont senti eux-même agressé ad-hominem. Bref, qu'on vienne pas pleurer quand on a lancé le pti jeu.

                                  Pour moi, le plus faible, il faut le protéger l'aider. L'inculte, il faut lui apprendre.

                                  Et le débile, t'en fait quoi ? Non parcque c'est quand même lui qui est visé le débile. Et vu que tout le monde a eu un problème de lecture de doc une fois un jour, on est tous débile hein.

                                  Je traine ici depuis assez longtemps pour avoir étudié ton comportement qui pour moi est inacceptable et intolérable.

                                  Alors celle là elle est facile : je décrédibilise ton propos actuel en faisant référence à tes anciens propos. On dirait que t'utilises les méthodes que tu dénonces là ;)

                                  • [^] # Re: Dépassement de tampon

                                    Posté par  . Évalué à 3.

                                    On peut aussi lire la doc, mal la comprendre, mal l'interpréter, avoir un moment d'égarrement, etc.
                                    Et c'est justement là qu'est le débat : le langage est tellement "dangereux" qu'il en devient inutilisable : pour écrire une ligne de code, il faut lire 1 doc, un man, un tutorial et prier pour que personne te traite de débile ou de sous-merde infâme.

                                    Tu es tres a cote de la verite. ce que vous traitez de dangereux depuis le debut, ce sont des erreurs de debutants, laxisme, ou etourderie.
                                    Peu importe la fonction et le langage, si tu connais pas, il faut lire sa doc. Je te rassures, je n ai pas a relire les docs de toutes les fonctions que j utilise quotidiennement ... Un grand nombre semble aussi croire que le C, ca se resume a partir de la glibc et rien d autre, autre tres grande erreur. Il y a plein de librairies de plus haut niveau pour facilement le boulot ...

                                    Je ne dev pas en Java, j evite donc de balancer dessus.
                                    Par contre je dev en C chaque jour, et je suis en profond desaccord avec vous. Si c etait aussi difficile que vous le dites, comment on a fait pour dev tous ces programmes en C, ainsi que ces OS ? ou alors les devs C seraient des etres d une intelligence superieure ? j en doute quand meme.

                                    • [^] # Re: Dépassement de tampon

                                      Posté par  (site web personnel) . Évalué à 2.

                                      Tout d'abord, merci de faire revenir la conversation au débat initial.

                                      Tu es tres a cote de la verite. ce que vous traitez de dangereux depuis le debut, ce sont des erreurs de debutants, laxisme, ou etourderie.

                                      Oui, des erreurs du programmeur qui conduisent à bugs non détectés par un compilo ou un runtime, et qui se transforme en faille de sécurité potentielle. D'où le danger.

                                      Disons que c'est le coeur du débat : d'un côté on reporte la faute sur le programmeur qui s'est coupé avec le scalpel, de l'autre on indique qu'il y a des langages qui évite justement 90% des conneries de l'utilisateur qui avait juste besoin de se couper une tranche de saucisson.

                                      Peu importe la fonction et le langage, si tu connais pas, il faut lire sa doc.

                                      Justement non. C'est 2 visions totalement différentes, mais pour de nombreux programmeurs une API bien faite est une API intuitive, où je n'ai pas besoin d'utiliser la doc, ou peu. Le problème c'est pas qu'il n'y a pas d'API intuitive en C, le problème c'est que le langage est tellement dangereux qu'il est extrêment complexe de faire une API 100% secure : il est donc effectivement indispensable de lire la doc pour tous les aspects non-intuitif inhérent à l'environnement technique.
                                      L'exemple du strncpy, qui se veut secure mais ne l'est pas à 100% est un très bon exemple : l'équivalent fonctionnel est parfaitement implémentable dans des langages "modernes" sans tous ces problèmes de documentation indispensable à sa bonne utilisation.

                                      Si c etait aussi difficile que vous le dites, comment on a fait pour dev tous ces programmes en C, ainsi que ces OS ?

                                      Ben vous le faites, mais avec pleins de problème de sécurité qui conduisent à des failles, pourtant "classiques", mais qui auraient été évités avec un langage de plus haut niveau.
                                      Il y a plein de bonnes raisons d'utiliser le C pour coder un OS, mais la contrepartie est une forte exposition aux problèmes de sécurité.

                                      • [^] # Re: Dépassement de tampon

                                        Posté par  . Évalué à 0.

                                        Oui, des erreurs du programmeur qui conduisent à bugs non détectés par un compilo ou un runtime, et qui se transforme en faille de sécurité potentielle.
                                        C est pour ca que je code des tests unitaires qui inclus les tests qui valident que tout fonctionne quand tout est normal, mais aussi les cas extremes (fuzzing). Se contenter d ecrire un code sans le valider, c est faire la moitiee du taff d un dev.

                                        Le problème c'est pas qu'il n'y a pas d'API intuitive en C, le problème c'est que le langage est tellement dangereux qu'il est extrêment complexe de faire une API 100% secure
                                        En fait non, il existe des methodes assez claires, le probleme c est qu il y a un fosse entre ce qu on apprend a l ecole, le code crado qu on trouve sur google, et de vraies fonctions/libs.

                                        Ben vous le faites, mais avec pleins de problème de sécurité qui conduisent à des failles, pourtant "classiques", mais qui auraient été évités avec un langage de plus haut niveau.
                                        Comme j ai dit au dessus, tests unitaires et fuzzing (au sein d un buildbot), c est primordial. ca detecte tous ces problemes sans avoir a les chercher, et si t as bien fait tes tests tu sauras automatiquement ou ca merde. Ca fait longtemps que les BOFs sont des soucis d un autre age pour moi, les plus gros problemes dans l ecriture d un soft en C, sont la coherence necessaire entre la gestion des ressources, threads et forks (resistance au DDOS, ou grosse charge)

                                        et puis niveau dialogue avec l exterieur, dans mon cas c est a 95% du temps des sockets, et une fois que tu sais le faire une fois, tu sais le faire 100 fois. j avai ecrit une lib pour ca dans le passe, avant de switcher sur ecore (et donc, eina), qui sont deux libs tres agreables.

                                        • [^] # Re: Dépassement de tampon

                                          Posté par  . Évalué à 1.

                                          Mes excuses, j ai totalement merde sur les quotes, j ai zappe la previsualisation comme un couillon =)

                                        • [^] # Re: Dépassement de tampon

                                          Posté par  (site web personnel) . Évalué à 1.

                                          C est pour ca que je code des tests unitaires qui inclus les tests qui valident que tout fonctionne quand tout est normal, mais aussi les cas extremes (fuzzing).

                                          C'est vrai, et quelque soit le langage d'ailleur. Mais qui t'assure que tes tests sont correctement écrits ? Rien. Qui t'assures que tes tests sont complets ? Rien. Qui t'assures que les cas extrêmes sont tous couvert par le fuzzing ? rien. Qui te garantie que le contexte (archi, compilo, etc.) dans lequel tu exécutes ton fuzzing va rester valable dans un autre contexte ? Rien.
                                          Ce type de tests, qui par nature ne garantisse rien, ne permettent que de se rapprocher, avec un coût exponentiel, vers l'absence totale de bug.
                                          Il faut les utiliser, mais à bon escient, et accepter qu'ils ne sont pas suffisant. Un language de haut niveau, offre beaucoup plus de garantie, by design, qui ne fera que compléter ces bonnes pratiques pour offre une meilleure sécurité, à moindre coût.

                                          En fait non, il existe des methodes assez claires,

                                          Je ne parle pas de clareté mais de sécurité. La méthode peut être clair, la doc aussi, mais tout repose sur le programmeur qui ne doit pas se "planter" lorsqu'il code, sinon boum. D'où l'idée d'avoir un outil (langage + compilo + runtime) qui permet d'assurer l'absence des problèmes les plus courants, by design.

                                          • [^] # Re: Dépassement de tampon

                                            Posté par  . Évalué à -2.

                                            C'est vrai, et quelque soit le langage d'ailleur. Mais qui t'assure que tes tests sont correctement écrits ? Rien. Qui t'assures que tes tests sont complets ?

                                            Je m amuse avec plusieurs outils, des valeurs extremes, des caracteres aleatoires ... mon but est que dans le pire des cas, ca remonte seulement une erreur. Il est facile de tester tous les caracteres possibles ainsi que des tailles depassant les buffers internes qui sont bornes. les soucis d archi, ca se passe a un autre niveau que ton code C (hormis la taille de certaines variables, mais c est connu et documente)
                                            Et comme j ai dit, la problematique des BOFs t en as vite fait le tour. Il existe pire que cela.

                                            Je ne parle pas de clareté mais de sécurité. La méthode peut être clair, la doc aussi, mais tout repose sur le programmeur qui ne doit pas se "planter" lorsqu'il code, sinon boum. D'où l'idée d'avoir un outil (langage + compilo + runtime) qui permet d'assurer l'absence des problèmes les plus courants, by design.

                                            pareil, il faut eviter d adopter une lib simplement parce qu elle fonctionne quand tout est 'dans la norme'. Franchement, mon but n est pas de dire que java ne sert a rien, mais dire que le C c est dangereux, c est quand meme abuse. tout est logique, documente, tout s explique ... ca peux paraitre effrayant quand on vient de java, mais c est juste des methodes a connaitre et respecter.

                                            • [^] # Re: Dépassement de tampon

                                              Posté par  . Évalué à 3.

                                              Je m amuse avec plusieurs outils, des valeurs extremes, des caracteres aleatoires ... mon but est que dans le pire des cas, ca remonte seulement une erreur. Il est facile de tester tous les caracteres possibles ainsi que des tailles depassant les buffers internes qui sont bornes. les soucis d archi, ca se passe a un autre niveau que ton code C (hormis la taille de certaines variables, mais c est connu et documente)
                                              Et comme j ai dit, la problematique des BOFs t en as vite fait le tour. Il existe pire que cela.

                                              Je peux te citer une ribambelle de developpeurs chez nous qui ont des annees et des annees d'experience, qui ont un niveau a faire rougir le plus baleze des developpeurs que tu connaisses, et pourtant j'ai trouve des failles dans leur code, malgre le fuzzing de leur equipe de test.

                                              Encore une fois, croire que c'est simple est un aller simple pour le ravin. Si tu crois que le fuzzing c'est facile et qu'il suffit de tester tous les caracteres et tailles, crois-moi t'as encore rien vu, ca c'est les cas basiques de fuzzing. Il y a tous les cas de race conditions, de changement d'etat, etc... qui entrent en compte par exemple et qui peuvent te sortir un BOF la ou tu ne l'attendrais jamais.

                                              • [^] # Re: Dépassement de tampon

                                                Posté par  . Évalué à -2.

                                                Je veux bien qu un race condition te provoque des dead locks ou de la data corrompue, mais un BOF ... faut pas pousser

                                                • [^] # Re: Dépassement de tampon

                                                  Posté par  . Évalué à -1.

                                                  il suffit de corrompre une taille de buffer non ?

                                                  • [^] # Re: Dépassement de tampon

                                                    Posté par  . Évalué à -2.

                                                    Il faudrait pour cela que ton race condition soit sur un acces a cette taille, hors je doute fortement que tu aies des acces concurrents complexes sur des gestions de buffers/size. Autant ce genre de chose est possible sur un FS avec un acces en cluster concurrent pour lequel il est parfois tres difficile de garantir la data, mais en ram tout est OK, et a la relecture de la data, sur le FS, tu fais des reads, donc pas de corruption au niveau de cette taille.

                                                  • [^] # Re: Dépassement de tampon

                                                    Posté par  . Évalué à -1.

                                                    Si ta taille est corrompue, ton probleme n est pas un buffer overflow, ton soucis est ce qui a genere cette taille corrompue. Soit c est un autre buffer overflow, et donc c est tjs le meme soucis type d erreur de conception ou on borne mal, ou alors il y a autre chose, qui n a rien a voir avec un BOF (RAM defectueuse par exemple). Et dans ce cas, le probleme c est pas un BOF.

                                                • [^] # Re: Dépassement de tampon

                                                  Posté par  . Évalué à 3.

                                                  T'as une variable qui definit la taille d'une structure globale a allouer.

                                                  T'as 2 requetes qui arrivent presque en meme temps, la 1ere definit une taille et ton thread bouge un peu plus loin pour allouer mais est preempte, pendant ce temps la 2eme requete passe, definit une nouvelle taille plus petite et est preempte, ton premier thread reprend, alloue un buffer plus petit que la structure de la 1ere requete, et paf lors de la copie il y a un buffer overflow.
                                                  La cause initiale est une race condition, le resultat final est un buffer overflow.

                                                  C'est un exemple basique que je t'ai cuit en 2 minutes. Tu vas me dire "ouais mais il suffit de XXX pour que ca n'arrive pas, le developpeur est un nul !", mais tu vois, la realite est que tu as certainement deja fait des erreurs de ce genre ou meme pire, parce que ca arrive a tout le monde quand le code devient un minimum complique, et crois moi un OS ca a des bouts codes incroyablement complexes avec du code s'executant en asynchrone un peu partout histoire d'avoir des performance correctes.

                                                  J'en ai plein d'autres si tu veux, les failles de securite ca a ete mon pain pendant plus de 6 ans sur une plateforme qui a ete probablement 10x plus testee que tous les bouts de code que tu as pu voir dans ta carriere, t'as pas idee de ce qu'il peut y avoir comme faille...

                                                  • [^] # Re: Dépassement de tampon

                                                    Posté par  . Évalué à -2.

                                                    Je ne vais donc pas dire "ouais mais il suffit de XXX pour que ca n'arrive pas, le developpeur est un nul !" puisque tu t y attend, je vais donc partir sur autre chose :
                                                    Le probleme n est donc pas un BOF, mais un acces concurrent a une data, qui a pour consequence un BOF dans ce cas la (et qui fait que du coup on remarque le probleme). On en reviens donc tjs a la meme chose : Les buffers on sait les manipuler. Ce cas de probleme d acces concurrent qui vient corrompre de la data, tu peux l avoir sur n importe quel langage. Et meme si avec java tu n aurai pas eu l effet d un BOF, qui entraine eventuellement (en l esperant, je prefere seg que manipuler de la donnee corrompue) un segfault, tu as de toute facon corruption de la data.

                                                    • [^] # Re: Dépassement de tampon

                                                      Posté par  . Évalué à 0.

                                                      Le probleme n est donc pas un BOF, mais un acces concurrent a une data, qui a pour consequence un BOF dans ce cas la (et qui fait que du coup on remarque le probleme). On en reviens donc tjs a la meme chose : Les buffers on sait les manipuler

                                                      Et quand tu te loupes dans ton calcul de taile a copier, c'est pas un BOF non plus alors, c'est un mauvais calcul mathematique qui a pour consequence un BOF.
                                                      Et puis un printf ou tu fais pas gaffe au format, c'est pas un BOF non plus, c'est une erreur de validation de la chaine de caracteres pour etre sur que l'user a pas mis de %s dedans
                                                      etc...

                                                      D'ailleurs en realite, l'erreur elle est toujours ailleurs, elle est dans le calcul d'un ou plusieurs parametres d'une fonction, qui au final amene un BOF. un BOF ca n'existe pas de lui-meme, il est toujours un resultat d'une mauvaise operation.

                                                  • [^] # Re: Dépassement de tampon

                                                    Posté par  . Évalué à -2.

                                                    En fait on va simplifier le debat, car je pense qu on est d accord sur la technique mais qu on en tire peux etre pas les memes conclusions :

                                                    1) La data est corrompue par le BOF ou les threads qui accedent en meme temps a la meme data ?
                                                    2) Le patch se fait en priorite sur l evitement d un BOF ou sur l evitement de corruption de data ?

                                                    si tu repond :
                                                    1) les threads
                                                    2) la corruption generee par les threads

                                                    Alors on est d accord, le soucis c est pas de gerer des BOFs.
                                                    Un autre exemple aussi valable que le tiens aurait ete : Si ta RAM est defectueuse, et que tu y lis des valeurs qui ne sont pas celles que tu as ecrites, et que ca genere un BOF, le soucis c est le BOF ou la RAM ?

                                                    • [^] # Re: Dépassement de tampon

                                                      Posté par  . Évalué à 0.

                                                      On sait tous les 2 ce qui corrompt les donnees : la mauvaise operation a la base (acces concurrent, mauvais calcul de taille, ...)

                                                      Et c'est ca qui fait que ton message "eviter les BOF c'est simple" est une horreur pour mes oreilles, il y a 10'000 manieres differentes de causer un BOF dans un soft, aucun developpeur sur cette planete n'a les capacites pour eviter tous ces cas de maniere garantie dans un soft non trivial.

                                                      • [^] # Re: Dépassement de tampon

                                                        Posté par  . Évalué à -2.

                                                        Donc, je reste sur ce que j ai dit :
                                                        - Eviter les BOFs c est simple, il est facile d encadrer ce qu un soft recoit d un input clavier, d une lecture de fichier, d une socket.
                                                        - Il y a des cas bien plus difficiles a gerer, comme des threads (deadlocks, acces concurrents) qui eux vont corrompre ta stack. Si ta stack est corrompue, tout peux arriver, ca peux etre un BOF, mais aussi un fonctionnement ou tu ne detecte pas d erreur (ce qui est pire!) mais ou tu traites de la donnee CORROMPUE. et ca, si pour une raison X ou Y, ta stack est corrompue, peux importe le langage, que ca seg ou pas, c est pas le probleme, le soft ne fonctionne pas, et la raison n a rien a voir avec un BOF.

                                                        • [^] # Re: Dépassement de tampon

                                                          Posté par  . Évalué à -1.

                                                          Eviter les BOFs c est simple, il est facile d encadrer ce qu un soft recoit d un input clavier, d une lecture de fichier, d une socket.

                                                          Non c'est toujours et encore une enorme connerie.

                                                          Il y a des cas bien plus difficiles a gerer, comme des threads (deadlocks, acces concurrents) qui eux vont corrompre ta stack. Si ta stack est corrompue, tout peux arriver, ca peux etre un BOF

                                                          Je me demandes, tu comprends ce que c'est un BOF ? Le buffer overflow est l'action qui corrompt ta stack(en assumant que ton buffer est sur la stack), c'et pas la modification concurrente de ta variable de taille qui corrompt la stack.
                                                          Tout buffer overflow est le resultat d'une action precedente qui etait fautive : calculer une taille de buffer, mal gerer des acces concurrents a cette variable de taille, etc...

                                                          Dire qu'eviter les BOFs c'est simple, mais pas dans certains cas c'est contradictoire hein. Soit c'est simple dans TOUS les cas, et alors eviter les BOFs c'est simple, soit eviter les BOFs n'est pas simple.
                                                          Dire qu'eviter les BOFs c'est simple sauf dans les cas A, B, C, D, E, F, G, H, I, J, K, .... c'est pas serieux.

                                                          • [^] # Re: Dépassement de tampon

                                                            Posté par  . Évalué à -1.

                                                            Huuuum, stoi qu est pas serieux!
                                                            Desole, j ai pas mieux la ...
                                                            Au jeu du "ouais mais si j ecris nawak en ram tu sais pas garantir la donnee" a mon avis, tout le monde se vautre. Si j ai un thread qui ecrit 3, un autre qui ecrit 4, et que je lis que 4, j ai rate 3, et ce soucis c est pas un probleme du langage C, ca concerne tous les langages.

                                                            On en revient toujours aux memes conclusions.

                                                            • [^] # Re: Dépassement de tampon

                                                              Posté par  . Évalué à 0.

                                                              Et tu crois qu'un BOF c'est quoi d'autre que "j'ecris n'importe quoi en RAM" ?

                                                              Si j'ecris n'importe quoi dans la variable contenant la taille du buffer a allouer
                                                              Si j'ecris n'importe quoi dans la variable contenant la taille a copier
                                                              Si j'ecris n'importe quoi dans la chaine de caractere definissant les parametres a ecrire du printf
                                                              etc...

                                                              Un BOF c'est TOUJOURS une erreur ou un gars fait une connerie quelque part. Le cas de threads ecrivant l'un apres l'autre n'est qu'un cas parmis bcp d'autres et il n'est en rien different d'une erreur dans le calcul de taille a allouer.

                                                              C'est pour ca que je te dis que tu ne te rends pas compte de quoi tu parles, des cas ou tu peux causer un BOF je peux t'en citer des dizaines auquel tu n'aurais jamais pense.

                                                              • [^] # Re: Dépassement de tampon

                                                                Posté par  . Évalué à -1.

                                                                Oui, c est tjs l erreur d un gars, on est d accords.
                                                                Et ton exemple est bidon, car si tu geres mal tes threads, c est pas java qui va te sauver. Hors tout mon dialogue est la, car au dessus si tu relis, on parle bien de "ouais mais le C/C++ c est trop complique, car t as des BOFs partout quand tu manipules des char *", et toi tu viens avec un probleme de gestion des threads, pas un probleme de gestion de char *. la source du probleme n est pas du tout la meme.

                                                                Tu ne parles pas de probleme de gestion de debordement memoire comme ca a ete le cas au debut, tu parles de probleme de gestion des threads sur un acces concurrent, qui donnent une corruption de la data qu aucun langage ne va corriger pour toi.

                                                                • [^] # Re: Dépassement de tampon

                                                                  Posté par  . Évalué à -1.

                                                                  t en es presque a me dire "si tu passes pas les bons parametres a une fonction, elle ne donne pas le bon resultat, c est vraiment un langage pourri!"

                                                                • [^] # Re: Dépassement de tampon

                                                                  Posté par  (site web personnel) . Évalué à 2.

                                                                  Et ton exemple est bidon, car si tu geres mal tes threads, c est pas java qui va te sauver.

                                                                  Ah si : si tu gères mal les threads, Java fera de toute façon en sorte que ca ne se transformera jamais en un BOF potentiel. Ton programme marchera peut être pas comme il faut, mais t'auras pas de faille de sécurité liée à un BOF potentiel.
                                                                  CQFD.

                                                                  • [^] # Re: Dépassement de tampon

                                                                    Posté par  . Évalué à -1.

                                                                    Alors, reprenons :
                                                                    - Dans son cas, il a deux threads, et deux variables, ou il pose ses mutex sur une variable apres l autre, ce qui provoque cette corruption entre le size_t et la vraie taille memoire du char *. Le soucis est de ne pas avoir ecrit ses threads correctement (deux erreurs de conception) ca n a rien a voir avec une gestion de char *.

                                                                    En java, tu traiteras n importe quoi de toute facon. Si tu fais un FS (mettons via FUSE), tu vas corrompre ton FS.

                                                                    Un hacker aura bien du mal faire expres de foirer les threads comme decrit alors que tout fonctionne autrement, pour une raison tres simple : le probleme ne vient pas d une attaque!

                                                                    Ce n est donc pas plus un probleme de securite lie a un BOF potentiel.
                                                                    De plus, je rappelle que pour des serveurs ou il faut de la securite, y a un mec qui s appelle Spender et qui produit des patchs kernels plus qu interessants.

                                                                    • [^] # Re: Dépassement de tampon

                                                                      Posté par  . Évalué à -2.

                                                                      Dans son cas, il a deux threads, et deux variables, ou il pose ses mutex sur une variable apres l autre, ce qui provoque cette corruption entre le size_t et la vraie taille memoire du char *. Le soucis est de ne pas avoir ecrit ses threads correctement (deux erreurs de conception) ca n a rien a voir avec une gestion de char *.

                                                                      Ben donnes moi un exemple ou l'erreur est dans le traitement du char* alors, c'est quoi l'erreur ? Il s'est trompe de variable et a passe le mauvais char* comme parametre ?
                                                                      Non la plupart des cas sont dus au fait que la taille de buffer (a lire, a allouer, a ecrire, ...) est fausse pour une raison X ou Y. X ou Y peut etre une erreur de calcul, un integer overflow/underflow, une race condition, etc...

                                                                      Un hacker aura bien du mal faire expres de foirer les threads comme decrit alors que tout fonctionne autrement, pour une raison tres simple : le probleme ne vient pas d une attaque!

                                                                      Tu es naif mon cher, tu crois que je l'ai invente de toute piece ce scenario ? Je te rappelles que j'ai passe 6 ans a bosser sur des failles dans un OS de 30 millions de lignes hein, le hacker il va simplement constamment te lancer 2 requetes en simultane et attendre qu'une fois ca declenche la faille toute simplement...

                                                                      Ce n est donc pas plus un probleme de securite lie a un BOF potentiel.
                                                                      De plus, je rappelle que pour des serveurs ou il faut de la securite, y a un mec qui s appelle Spender et qui produit des patchs kernels plus qu interessants.

                                                                      Moi je te suggeres de te demander si tu devrais prendre en compte l'avis de quelqu'un dont la securite a ete le boulot pendant 6 ans plutot que balancer cela par dessus l'epaule comme ca...

                                                                      • [^] # Re: Dépassement de tampon

                                                                        Posté par  . Évalué à -4.

                                                                        • tu n a pas relu ce qui etait dit, l exemple etait un strncpy et prendre en compte le '\0' dans le calcul. Rien a voir avec deux threads qui vont corrompre un size_t qui va ensuite partir sur une mauvaise utilisation du char *.

                                                                        • Bah oui moi ca me surprend qu un test de charge en interne ne voit pas ca.

                                                                        • Oh, bah non moi je m arrete pas la dessus, j ai vu un homme de 55ans partir a la retraire, il a code quasimment toute sa vie, et pourtant il a fini sur windev, ne gerait jamais les erreurs, alors la securite j en parle meme pas. Par contre moi je me demande jusqu a quel point va ton orgueil. Car des "Je bosse avec les meilleurs du monde", "l os le plus utilise" bla bla et bla, desole de ne pas etre autant impressionne de toi que l est toi meme sur ton parcours professionnel. tu n a fait que sortir des propos qui etaient hors contexte. On parlai de savoir utiliser strncpy sans faire de gaffe, tu es tout de suite parti totalement autre chose, qui sont des problemes en AMONT. Ne pas savoir coder un thread (ou une faute d etourderie, fatigue) et donc provoquer une corrumption memoire, ca n a rien a voir avec le fait de savoir dimensionner un char * et savoir passer les bons params a strncpy ou controler si une chaine passee a snprintf ne contiendrai pas des caracteres qui vont provoquer un seg.

                                                                        • [^] # Re: Dépassement de tampon

                                                                          Posté par  . Évalué à -4.

                                                                          •tu n a pas relu ce qui etait dit, l exemple etait un strncpy et prendre en compte le '\0' dans le calcul. Rien a voir avec deux threads qui vont corrompre un size_t qui va ensuite partir sur une mauvaise utilisation du char *.

                                                                          Et la taille de buffer pour strncpy tu l'oublies ? C'est un entier, comment tu le calcules sans te prendre les pieds dans le tapis ? Tu crois que ca sera toujours une valeur statique toute simple ?

                                                                          On parlai de savoir utiliser strncpy sans faire de gaffe, tu es tout de suite parti totalement autre chose, qui sont des problemes en AMONT. Ne pas savoir coder un thread (ou une faute d etourderie, fatigue) et donc provoquer une corrumption memoire, ca n a rien a voir avec le fait de savoir dimensionner un char * et savoir passer les bons params a strncpy ou controler si une chaine passee a snprintf ne contiendrai pas des caracteres qui vont provoquer un seg.

                                                                          Vraiment ? L'exemple que je t'ai donne est exactement la meme chose : se louper dans le calcul d'un des parametres, exactement comme dans ta phrase savoir passer les bons params a strncpy

                                                                    • [^] # Re: Dépassement de tampon

                                                                      Posté par  (site web personnel) . Évalué à 1.

                                                                      Si tu fais un FS (mettons via FUSE), tu vas corrompre ton FS.

                                                                      Oui enfin là on parle de BOF, restons dans le sujet.

                                                                      Java t'offre des garanties vis-à-vis des BOF et pBpG te montre que même avec les meilleurs outils du monde t'es pas à l'abri d'un BOF en C/C++ et donc d'une faille de sécu potentielle.

                                                                      le probleme ne vient pas d une attaque!

                                                                      Si le problème est reproductible, un attaquant peut très bien le reproduire, à plus forte raison s'il a accès au code (open-source par exemple).

                                                                      • [^] # Re: Dépassement de tampon

                                                                        Posté par  . Évalué à -2.

                                                                        Il me parait relativement invraissemblable qu un code soit release avec une bourde de conception pareille.

                                                                        Et java n est pas non plus a l abris de tout. Il y a meme eu une epoque ou la version courante de java ne pouvait s executer sur un kernel compile avec GRSEC.

                                                                        • [^] # Re: Dépassement de tampon

                                                                          Posté par  (site web personnel) . Évalué à 1.

                                                                          On est effectivement en Java t'es pas à l'abris de tout : si ton programme Java accède à des ressources externes sous certaines conditions métiers qu'un attaquant arrive à violer parcque t'as pas fait les bons testsU, oui, t'as une faille potentielle de type "divulgation d'information". Et pour ça les outils de fuzzing sont nul.

                                                                          Tu es aussi vulnérable aux failles potentielles de la VM elle-même, celle-ci étant écrite dans un langage non-sûre :)

                                                                          D'où les recherches actuelles de MS, oui je me répète, sur son OS Singularity : utiliser un environnement "sûr" au coeur de l'OS, le plus bas possible, pour limiter les risques de failles de sécurité de type corruption de mémoire ou accès à des ressources illégales.

                                                                          • [^] # Re: Dépassement de tampon

                                                                            Posté par  . Évalué à -2.

                                                                            perso j utilise grsec depuis ... tres longtemps, peut etre 10ans, et je n ai pas memoire d avoir vu un exploit qui arrivait a bypass les patchs de grsec.

                                                                            Par contre, j ai vu plein de softs cesser de fonctionner avec grsec car ils faisaient des trucs malsaints =)

                                                                • [^] # Re: Dépassement de tampon

                                                                  Posté par  . Évalué à -1.

                                                                  on parle bien de "ouais mais le C/C++ c est trop complique, car t as des BOFs partout quand tu manipules des char *", et toi tu viens avec un probleme de gestion des threads, pas un probleme de gestion de char *. la source du probleme n est pas du tout la meme.

                                                                  Non tu n'as visiblement pas compris le probleme. En C++ tu peux meme utiliser std::string si ca te chante est t'es dans le meme cas que Java, la seule difference c'est qu'en C++ si t'as un acces hors buffer rien ne t'arrete, tu vas aller ecrire sur les structures de la heap, sur la stack, etc... alors qu'en Java tu vas prendre une belle exception dans la tete. C/C++ te permet de faire de l'arithmetique de pointeur et aller lire/ecrire ou tu veux, et c'est ca l'enorme difference avec des langages type C# ou Java, avec eux t'as beau avoir une variable modifiee sans le savoir par un autre thread, tu n'auras jamais de BOF car la VM ne te laissera jamais lire ou ecrire hors du buffer.

                                                                  Tu ne parles pas de probleme de gestion de debordement memoire comme ca a ete le cas au debut, tu parles de probleme de gestion des threads sur un acces concurrent, qui donnent une corruption de la data qu aucun langage ne va corriger pour toi.

                                                                  Si c'est un probleme de gestion de debordement memoire, et justement un langage comme Java te protege de cela alors que C/C++ non.

                                                                  • [^] # Re: Dépassement de tampon

                                                                    Posté par  . Évalué à -2.

                                                                    Oui, codons en java, et fermons les yeux sur les erreurs de conception, tant que ca plante pas, y a pas de probleme =)

                                                                    • [^] # Re: Dépassement de tampon

                                                                      Posté par  . Évalué à 1.

                                                                      Vaut mieux ca que coder en C en croyant qu'eviter les BOF est simple. Au moins ca evitera que le systeme se mette a executer du code externe.

                                                                      • [^] # Re: Dépassement de tampon

                                                                        Posté par  . Évalué à -2.

                                                                        C est exactement ce que font les mecanismes de securite actuels via grsec, pas besoin de rajouter une JVM pour cela.

                                                                        • [^] # Re: Dépassement de tampon

                                                                          Posté par  . Évalué à -1.

                                                                          Cadeau : http://www.securityfocus.com/bid/48538/discuss

                                                                          Serieusement, tu n'as absolument aucune idee des risques et consequences de diverses erreurs de programmation en matiere de securite visiblement.

                                                                          • [^] # Re: Dépassement de tampon

                                                                            Posté par  . Évalué à -2.

                                                                            Et ?
                                                                            Ca va deborder de l espace alloue mais avec GRSEC tu ne pourra pas executer le code que tu injectes. ca ne change rien.

                                                                            • [^] # Re: Dépassement de tampon

                                                                              Posté par  . Évalué à -2.

                                                                              Dis-moi, c'est quelle partie de la phrase

                                                                              Attackers can exploit this issue to execute arbitrary code with superuser privileges, facilitating the complete compromise of affected computers

                                                                              que tu as rate ?

                                                                              a) GRSEC n'est de loin pas present sur tous les kernels, de tres loin meme
                                                                              b) C'est pas une protection a 100%, il y a des manieres de passer outre (cf. http://jon.oberheide.org/blog/2011/04/20/stackjacking-your-way-to-grsec-pax-bypass/ )

                                                                              Serieusement, je te suggeres de te renseigner un peu plus sur ce champs avant d'affirmer des choses comme tu le fais. La securite c'est vraiment pas le bon champs pour prendre des decisions sans comprendre de quoi il en retourne.

                                                                              • [^] # Re: Dépassement de tampon

                                                                                Posté par  . Évalué à -2.

                                                                                Moi je te conseilles plutot de revenir sur terre.
                                                                                La question etait : "c est trop dur en C/C++ de borner un char *"
                                                                                Pour prouver que c est vrai, tu as derive sur "j ecrit mal mes threads en posant mal des mutex, pour corrompre mes variables" ce qui est un probleme d ecriture de threads.

                                                                                Maintenant, tu en es a venir au sein meme du kernel pour prouver le contraire. En quoi l ecriture d une application JAVA va changer le fonctionnement du KERNEL ?

                                                                                Moi je repondai aux BOFs quand il s agit de lire via son appli ce qui vient d une source externe, tu me parle de race condition au en interne d une appli, puis du kernel.

                                                                                Le bypass de grsec est tres sympa, je ne me rappelle pas l avoir vu, il faudrait que je check mes activitees pour cela. Mais je le repete, on est encore sorti du cas qui etait discute au debut, on est pas en train de faire un BOF sur un demon qui ecoute sur la socket, on a un programme qui s execute deja sur le systeme, donc on a deja bypass la stack qui n est pas executable, ce qui est bloque par GRSEC.

                                                                                • [^] # Re: Dépassement de tampon

                                                                                  Posté par  . Évalué à -3.

                                                                                  La question etait : "c est trop dur en C/C++ de borner un char *"
                                                                                  Pour prouver que c est vrai, tu as derive sur "j ecrit mal mes threads en posant mal des mutex, pour corrompre mes variables" ce qui est un probleme d ecriture de threads.

                                                                                  Je me suis contente de te parler de la realite, dans le monde reel, ou les BOFs sont legion, et qui prouve que non c'est pas simple.

                                                                                  Maintenant, tu en es a venir au sein meme du kernel pour prouver le contraire. En quoi l ecriture d une application JAVA va changer le fonctionnement du KERNEL ?

                                                                                  J'en viens au kernel ? Quel rapport ? Le kernel est un bout de code en C/C++ comme un autre, si tu veux je te sors un BOF trouve la semaine passee dans un soft user-mode, il y en a a la pelle.

                                                                                  Moi je repondai aux BOFs quand il s agit de lire via son appli ce qui vient d une source externe, tu me parle de race condition au en interne d une appli, puis du kernel.

                                                                                  Et moi je te parles exactement de la meme chose mais tu ne le comprends pas, une appli qui lit un buffer sur plusieurs sockets a la fois car plusieurs connections en meme temps et qui a une race condition causant un BOF c'est quoi d'apres toi ?

                                                                                  Le bypass de grsec est tres sympa, je ne me rappelle pas l avoir vu, il faudrait que je check mes activitees pour cela. Mais je le repete, on est encore sorti du cas qui etait discute au debut, on est pas en train de faire un BOF sur un demon qui ecoute sur la socket, on a un programme qui s execute deja sur le systeme, donc on a deja bypass la stack qui n est pas executable, ce qui est bloque par GRSEC.

                                                                                  La stack non-executable c'est un gag a passer, je t'invites a aller chercher ce qu'est le return-oriented programming par exemple.

                                                                                  • [^] # Re: Dépassement de tampon

                                                                                    Posté par  . Évalué à -1.

                                                                                    • La realite qui ne correspond pas a la problematique initiale que j ai du aller rechercher : utiliser strncpy et snprintf. Tu es sorti du contexte des le debut

                                                                                    • On parlai de dev des applis il me semble, mais pareil, si on est pas dans le meme contexte...

                                                                                    • "une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.

                                                                                    • La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.

                                                                                    • [^] # Re: Dépassement de tampon

                                                                                      Posté par  . Évalué à -4.

                                                                                      une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.

                                                                                      Il y a plein d'implementations differentes oui tout a fait, c'est une des nombreuses raisons qui font que tu ne comprends toujours pas qu'eviter des BOFs est complique, parce qu'il y a 10'000 cas differents a gerer.
                                                                                      Si ton propos est de dire "appeler strcpy est simple dans 3 cas" super, mais ca on s'en fout pas mal, il reste 9997 cas a gerer.

                                                                                      •La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.

                                                                                      Moi je regarde les distribs dispo au grand public, et force est de constater qu'en tant que developpeur, tu n'as qu'un choix: eviter les BOFs dans ton code parce que les protections du systeme et du compilateur ne sont pas suffisantes pour te proteger.

                                                                                      • [^] # Re: Dépassement de tampon

                                                                                        Posté par  . Évalué à -3.

                                                                                        • Question de contexte et de ce que fait le code.

                                                                                        • C est vrai que la quasi totalite des distros n a pas les patchs kernels necessaires mais un desktop bateau a moins de besoins de secu qu un serveur, il y a une relativite a savoir conserver, y en a meme qui veulent juste un systeme rapide, et donc, les patchs grsec tu as plutot interet a ne pas les avoir. Mais il y a bien pire que cela : Si tu utilises checksec tu verras que pas mal de demons sont compiles sans aucune protection. Apres c est encore et toujours une question de contexte : pour un desktop linux qui ne fait qu utiliser firefox, il n y a pas grand chose a encadrer. Mais il est evident qu on va eviter une ubuntu de base pour un serveur. La chance que l on a, c est qu on peux tout changer selon notre bon vouloir. Apres il est aussi evident qu il faut chercher la securite dans son code, a moins de s en foutre.

                                                                              • [^] # Re:Dépassementde tampon

                                                                                Posté par  . Évalué à 4.

                                                                                La securite c'est vraiment pas le bon champs pour prendre des decisions sans comprendre de quoi il en retourne.

                                                                                Chez MS ils ont bien suivi ce principe, d'ailleurs on est pas près de les voir prendre des décisions.

                                                                                • [^] # Re:Dépassementde tampon

                                                                                  Posté par  . Évalué à -9.

                                                                                  Le jour ou Linux arrivera a notre cheville a se sujet on en reparlera, d'ici la je me contenterai de rire de ton post qui prouve que tu ne connais absolument rien au sujet.

                                            • [^] # Re: Dépassement de tampon

                                              Posté par  . Évalué à 4.

                                              Et comme j ai dit, la problematique des BOFs t en as vite fait le tour

                                              Ah ok... Tiens, un bug qui m'a pourri la vie plusieurs jours (crash aléatoire dans le driver Intel pour X11). C'est un buffer overflow.
                                              https://bugs.mageia.org/show_bug.cgi?id=2067

                                              Puisque tu es si fort, tu veux pas faire la maintenance de X11 et ses drivers ?

                                • [^] # Re: Dépassement de tampon

                                  Posté par  . Évalué à 1.

                                  En clair, si tu ne maitrises pas quelque chose : ne l'utilise pas.

                                  c'est le bé à bas b.a.-ba

                                  Je confirme : c'est un sage conseil qu'il nous a donnés là...

                                  • [^] # Re: Dépassement de tampon

                                    Posté par  . Évalué à 3.

                                    donnés ?

                                    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                                  • [^] # Re: Dépassement de tampon

                                    Posté par  (site web personnel) . Évalué à 3.

                                    Personnellement je pense que c'est un conseil à ne surtout pas suivre.
                                    Qui peut affirmer maîtriser quelque chose sans avoir eu d'expérience avec ? Il faut bien commencer par être débutant, accepter de ne pas tout maîtriser, puis progresser. Et surtout ne jamais affirmer qu'on maîtrise : c'est la meilleur façon de se planter.

                        • [^] # Re: Dépassement de tampon

                          Posté par  . Évalué à -1.

                          Tu as dit que vtorri n avait pas beaucoup d experience, il te donne son experience, tu repond que c est une ineptie (synonyme : absurdite), j aimerai bien comprendre pourquoi.

                          Linus lui meme l admet : il ne cherche pas a dev un truc blinde.
                          Donc forcement, on trouve des failles dans le kernel (biensur, on en trouve bien plus dans les milliards de logiciels existants), qui ne sont patchees qu une fois devoilees.

                          L erreur humaine du dev n est pas un probleme du langage.
                          Les soucis lies aux BOFs sont surtout une question de securiser les "liens avec l exterieur" que ce soit des inputs clavier, la lecture d un fichier externe, une bdd, ou encore des sockets. Beaucoup de devs ne le font pas, car l aspect "fonctionnel" prime sur l aspet "securite", et comme je l ai deja dit, tu connais beaucoup de projets qui sont passes au fuzzing par leurs devs ? Il est la le vrai probleme.

                          Si parrer aux BOFs c etait si difficile, en patcher un prendrai des mois, et pas quelques minutes lorsque l exploit est publie.
                          Il leur suffit de lancer gdb, lancer l exploit, et backtrace tout ca pour voir ou est ce que c est mal controle, fiou, que c est difficile!

                          Les cas les plus complexes ne sont pas les exploitations mais plutot les implementations.
                          blinder un programme d une exploitation c est juste un boulot chiant et du coup les devs ne le font pas vraiment : Il est pourtant tres facile de fuzzer.

                          • [^] # Re: Dépassement de tampon

                            Posté par  . Évalué à 6.

                            J'ai passe plus de 6 ans a faire de la securite sur l'OS le plus utilise de la planete, ecrit par certains des meilleurs developpeurs C de la planete avec probablement un des meilleurs niveau de QA tous OS confondus, et j'ai vu nombre de problemes avec ces fonctions au point ou maintenant elles ont TOUTES ete remplacees par d'autres fonctions plus sures, bref on va dire que de l'exeperience niveau BOFs j'en ai jusqu'au cou.

                            Alos dis-moi donc, pourquoi un groupe comme le notre compose de gens pourtant tres solides niveau C, avec des outils d'analyse statique parmis les plus avances qui soient, avec une utilisation systematique du fuzzing, avons pris cette decision ? On avait envie pour le fun de virer ces appels partout ?

                            Parer des BOFs n'est PAS simple. C'est simple dans le cas simple et basic ou t'as un printf dans un hello world evidemment, mais c'est pas le cas de la majorite des printf dans des vrais softs un tant soit peu complexe.

                            • [^] # Re: Dépassement de tampon

                              Posté par  . Évalué à -2.

                              • Quelles fonctions ?
                              • Et pourtant, borner des espaces memoire, c est pas si complique. On pourrait meme s amuser a creer une structure representant des chaines, leur taille, et leur type. Et en interne, forcer un controle du contenu de la chaine par rapport a son type, et en permanence borner sa taille. La seule chose compliquee, c est de jouer avec des fonctions de formatage comme sscanf ou snprintf quand on ne controle pas tous les arguments, et donc leur taille, ce qui veux donc dire que c est une mauvaise idee de les utiliser directement. Il y a des cas beaucoup plus complexes a gerer que ca.

                              Tes fonctions plus sures, c est tjs du C non ? tout est dit.
                              Je ne developpe pas que des hello world.

                            • [^] # Re: Dépassement de tampon

                              Posté par  . Évalué à 3.

                              J'ai passe plus de 6 ans a faire de la securite sur l'OS le plus utilise de la planete, ecrit par certains des meilleurs developpeurs C de la planete avec probablement un des meilleurs niveau de QA tous OS confondus, et j'ai vu nombre de problemes avec ces fonctions au point ou maintenant elles ont TOUTES ete remplacees par d'autres fonctions plus sures, bref on va dire que de l'exeperience niveau BOFs j'en ai jusqu'au cou.

                              .

                              Alos dis-moi donc, pourquoi un groupe comme le notre compose de gens pourtant tres solides niveau C, avec des outils d'analyse statique parmis les plus avances qui soient […]

                              .

                              Je peux te citer une ribambelle de developpeurs chez nous qui ont des annees et des annees d'experience, qui ont un niveau a faire rougir le plus baleze des developpeurs que tu connaisses, et pourtant j'ai trouve des failles dans leur code, malgre le fuzzing de leur equipe de test.

                              C'est toi qui expliquait à vtorri que ça ne sert à rien d'allonger son CV ?

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: Dépassement de tampon

                                Posté par  . Évalué à -1.

                                Non c'est pas moi, tu m'as vu faire ca ou ?

                                Perso je consideres que l'experience d'une personne a de la valeur tant qu'il n'est pas incompetent.

                                • [^] # Re: Dépassement de tampon

                                  Posté par  . Évalué à 1.

                                  tu m'as vu faire ca ou ?

                                  Les 3 citations viennent de tes commentaires plus haut.

                                  Perso je consideres que l'experience d'une personne a de la valeur tant qu'il n'est pas incompetent.

                                  Bien c'est cool, comment tu fais pour juger de la compétence de quelqu'un ?

                                  Enfin tout ça pour dire que jouer à celui qui a le plus gros et le plus beau CV qui travaille dans l'entreprise la plus grosse et ayant les meilleurs développeurs du monde (et qu'en plus tu es capable de corriger !), tu peut le garder pour draguer à la plage (par exemple).

                                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                  • [^] # Re: Dépassement de tampon

                                    Posté par  . Évalué à -2.

                                    Bien c'est cool, comment tu fais pour juger de la compétence de quelqu'un ?

                                    Je lis ce qu'il ecrit et tant que ca a un minimum de sens c'est qu'il a un minimum de competence.

                                    Enfin tout ça pour dire que jouer à celui qui a le plus gros et le plus beau CV qui travaille dans l'entreprise la plus grosse et ayant les meilleurs développeurs du monde (et qu'en plus tu es capable de corriger !), tu peut le garder pour draguer à la plage (par exemple).

                                    Le but est pas de dire que j'ai la plus grosse, je pense pas forcement que les dev/testeurs ici sont plus forts que chez Google, Oracle ou autres entreprises de ce style, mais force est de constater que ces gens ont une experience de developpement de gros softs largement utilises qui doivent tenir la route. Quand a trouver des bugs dedans, le point est justement de dire que meme si t'es bon, il y a toujours des bugs dedans, j'ai jamais dit qu'ils etaient super dur a trouver et que j'etais un genie pour ca.

                                    • [^] # Re: Dépassement de tampon

                                      Posté par  . Évalué à 1.

                                      Je ne vois pas le liens entre la taille de l'entreprise et la qualité des développeurs.
                                      D'ailleurs je ne vois pas plus de lien avec la taille des projets, tout le monde sais aujourd'hui que le nombre de ligne de code n'indique pas la complexité du projet.

                                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                      • [^] # Re: Dépassement de tampon

                                        Posté par  . Évalué à -2.

                                        Tu m'as vu ou parler de taille d'entreprise ?

                                        Je regarde le type de projet :
                                        - Base de donnees haute performance & disponibilite (Oracle)
                                        - OS grand public stable et performant (Mac OS X, Windows, ...)
                                        - Soft serveur performant & stable (Oracle encore, SQL Server, platformes Google, etc...)

                                        Tout ca c'est des projets gros et extremement complexes, sans rapport avec l'enorme majorite des projets software. Evidemment tu vas avoir des petites boites specialisees dans les softs pour Airbus avec des requirements de qualite incroyables, mais compare a l'enorme majorite des boites de soft c'est clair et net. C'est d'ailleurs flagrant lors de nos rachats de societes, le code qu'on trouve est souvent de sacrement pietre qualite.

                      • [^] # Re: Dépassement de tampon

                        Posté par  . Évalué à 1.

                        la majorité des erreurs d'utilisation de ce type de fonction est la non lecture attentive de la doc

                        Cette remarque sonne à la fois paternaliste et arbitraire.

                        Grosso modo, si certains programmeurs se retrouvent avec des trous de sécurité, ce serait de leur faute (ils n'ont pas bien lu la doc, ou ont oublié la moitié de ce qu'ils ont lu, etc.). Le problème, c'est que cette position ne répond absolument pas à la question. On peut certes considérer que toute erreur est une faute humaine, et appuyer péremptoirement sur la culpabilité du programmeur ; la question est bien de minimiser les conséquences des dites fautes ou erreurs.

                        Note que je n'ai parlé que de ces 2 fonctions. Libre à too de généraliser à toutes les fonctions que tu veux. Ca sera juste un hors sujet de ta part.

                        Non, justement, ce n'est pas du tout hors sujet.

                        Si deux primitives aussi simples que la copie et le formatage de chaînes nécessitent une attention soutenue pour ne pas se retrouver avec un trou de sécurité, alors la programmation d'une appli complexe en C relève de l'acrobatie ou du jemenfoutisme.

                        (sauf bien sûr à postuler l'existence d'une race inconnue de programmeurs parfaits)

                        • [^] # Re: Dépassement de tampon

                          Posté par  . Évalué à 5.

                          Grosso modo, si certains programmeurs se retrouvent avec des trous de sécurité, ce serait de leur faute (ils n'ont pas bien lu la doc, ou ont oublié la moitié de ce qu'ils ont lu, etc.).

                          Alors là oui, je te le dis sans hésiter un bug c'est une erreur des programmeurs. On peut discuter de la pertinence du choix des langages, mais se réfugier derrière le langage pour expliquer ses erreurs, c'est vraiment pas une bonne idée.

                          Je ne dis pas qu'ils sont mauvais, je dis qu'ils ont fait une erreur, c'est tout.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Dépassement de tampon

                            Posté par  . Évalué à -2.

                            J ai ouie dire que dans le cas de Windev ou Webdev, on pouvait se cacher derriere le langage.

                            pour la libc, c est plus difficile.

                            • [^] # Re: Dépassement de tampon

                              Posté par  . Évalué à 4.

                              C'est d'ailleurs pour ça qu'entre la page de manuel de (disons) scanf, et ce qu'on peut trouver sur le net pour expliquer son fonctionnement, ça peut donner ça : http://xrenault.developpez.com/tutoriels/c/scanf/

                              Par là je veux dire: certaines fonctions de la bibliothèque standard sont juste mal foutues, point. À l'époque elles avaient peut-être du sens, mais le langage C est loin d'être simple (enfin, sa syntaxe et sa grammaire le sont, mais pas son utilisation).

                              Ensuite, concernant strncpy/strncat: « il suffit de lire la doc » ? Vraiment ? C'est pour ça que, malgré la ressemblance entre les deux noms, chaque fonction a une page de manuel super étendue je suppose, avec des comportements différents pour que ce soit encore plus rigolo (et encore, elles étaient bien plus succintes il y a dix ans) ?

                              Ça donne de joyeux bouts de code du genre : 

                              char *src;
char dst[size+1];
char buf[K*size];
size_t len = 0;

/* ... src est alloué, initialisé, etc. quelque part ici ... */

/* strncpy() copie au maximum "size" caractères de la chaîne src vers la chaîne dst. 
 * Mais attention ! Si la longueur de src dépasse "size", alors il n'y aura pas de '2878b2550166f39398d09567f242898acfb5ed97' 
 * final ! Il faudra le rajouter à la main du coup.
 */
len = strlen(src); /* il faut espérer que src est bien terminé par '\0'... */
strncpy(dst,src,size); 
if (size <= len) 
    dst[size] = '\0';

/* ... */

process(buf,...); /* traitement de buf, qui contient une certaine chaîne de caractères au retour de l'appel */
len = strlen(buf); /* il faut espérer que buf est bien terminé par '\0'... */
/* Rigolons un bon coup. strncat() prend un taille en troisième paramètre. 
 * Si celle-ci est plus grande que la taille de ce qu'il faut concaténer, 
 * "tout va bien" : strncat rajoute un '\0' juste après le dernier caractère copié. 
 * Bon bien sûr, maintenant, j'ai beau avoir demandé N caractères max à concaténer,  
 * si ma chaîne source contient plus que n caractères, alors strncat va écrire n+1 
 * caractères.
 */
strncat(buf,dst,K*size-len-1); /* Comme quoi, c'était pas si compliqué ! */

                              et faire un truc du genre 

                              char *src;
char dst[size+1];
char buf[K*size];
size_t len1 = 0, len2 = 0;

/* ... src est alloué, initialisé, etc. quelque part ici ... */

len1 = strlen(src);
memcpy(dst,src,size);
dst[size] = '\0';

/* ... */

process(buf,...); 
len2 = strlen(buf); 
size_t tmp = len1+len2+1 <= K*size ? len1+len2 : K*size-1;
memcpy(buf,dst,tmp);
buf[tmp] = '\0';

                              Ou encore :

                              char *src;
char dst[size+1];
char buf[K*size];
size_t len1 = 0, len2 = 0;

/* ... src est alloué, initialisé, etc. quelque part ici ... */

len1 = strlen(src);
memcpy(dst,src,size);
dst[size] = '\0';

/* ... */

process(buf,...); 
len2 = strlen(buf); 
if (len2+len1 < K*size)
    strcat(buf,dst); /* La concaténation est sûre */
else /* K*size < len1+len2 */
{
    memcpy(buf+len2,dst,K*size-len2-1);
    buf[K*size-1] = '\0';
}

                              Ah si: au moins, dans le deuxième cas, tu ne te poses pas la question de « est-ce que c'est strncat ou strncpy qui rajoute un \0 additionnel ? »: dans tous les cas tu as un comportement éprouvé (i.e. tu ne manipules que des bytes). Bon bien entendu, t'es niqué quand le byte fait 1 octet, mais que le char en fait 2 (comme ça peut arriver sur certains DSP).

                              Ce n'est pas pour rien que les dévs OpenBSD on rajouté strlcat/strlcpy: non seulement le comportement des fonctions est homogène, mais en plus elles renvoient une vraie information utile : le nombre de caractères copiés (au lieu du pointeur destination que tu as toi-même passé en paramètre au moment de l'appel…).

                              char *src;
char dst[size+1];
char buf[K*size];

/* ... src est alloué, initialisé, etc. quelque part ici ... */

size_t src_len = strlen(src);
size_t cpy_res = strlcpy(dst,src,size); /* J'ai la garantie que dst est a un '\0' */
if (cpy_res < src_len) {
    /* Gestion de la troncature */
}

/* ... */

process(buf,...);
size_t buf_len = strlen(buf); 
size_t cat_res = strlcat(buf, dst, K*size);
if (cat_res >= buf_len) {
    /* Gestion de la troncature */
}

                              (Il est tard au moment où j'écris ces lignes, et il y a de fortes chances que j'aie fait une erreur : je n'ai pas compilé pour vérifier)

                              Donc voilà. Je suis surpris que tu te permettes de dire que « y'à qu'à bien savoir compter », alors que même les développeurs d'environnements qui se veulent sécurisés disent que strcpy/strcat Vs strncpy/strncat est une fausse « sécurité ». Je me souviens avoir entendu et lu Marc Espie à plusieurs reprises concernant le fait que, même plein de bonne volonté, le dév qui cherche à remplacer ses strcpy/strcat par strncpy/strncat va souvent se planter à cause de la différence de sémantique dans les deux fonctions. Alors qu'au moins avec strcpy/strcat, la règle est simple : tu vérifies la taille de tes buffers avant de faire quoi que ce soit (et bien entendu, avec strlcat/strlcpy, c'est ENCORE plus simple).

                  • [^] # Re: Dépassement de tampon

                    Posté par  (site web personnel) . Évalué à 3.

                    un programmeur normalement constitué lirait la doc et verrai ce qu'il faut faire pour éviter les buffer overflow avec ce genre de fonctions.

                    Pour éviter les débordements de tampon, les spécialistes sont unanimes: le top, c'est la sphaigne!

                    • [^] # Re: Dépassement de tampon

                      Posté par  . Évalué à 4.

                      si on me pique mes blagues, maintenant...

                      LES DÉPASSEMENTS DE TAMPON, CAI DEGUEULASSE !

          • [^] # Re: Chacun son style

            Posté par  . Évalué à 1.

            On peut ajouter qu'en C++ les variables ne sont pas automatiquement initialisées à 0.

            J'avais fait un rapport de bug pour Notepad++ pour un tampon (défini sur la pile) qui n'était pas initialisé avec des 0, et qui provoquait un bug dans l'estimation du caractère de fin de ligne d'un fichier texte ouvert.

            Bug toujours présent d'ailleurs, car il se produit dans un cas précis et que ce n'est pas un problème de sécurité. Et non reproductible alors qu'une exécution pas à pas (logiciel open source) montre bien le bug.

            • [^] # Re: Chacun son style

              Posté par  . Évalué à 1.

              Un compilateur qui ne préviens pas quand on utilise une variable non-initialisée, ou bien ça n'est pas un compilateur, ou bien l'idiot de programmeur à viré les warnings, et donc c'est de sa faute.

              On peut en virer des warnings dans Java aussi...

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 1.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Chacun son style

                  Posté par  . Évalué à 1.

                  Et tu n a pas code de fonction d init ?

                  AFFECT_DATA *paf = affectdate_new();

                  avec dans cette fonction un :
                  AFFECT_DATA *tmp = calloc(1, sizeof(AFFECT_DATA));

                  c est la base.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 2.

                    Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 2.

                On peut en virer des warnings dans Java aussi...

                Certes, mais ne pas initialiser une variable locale ou finale est une erreur, il est impossible de compiler le code.
                Quand aux variables non-locales et non-finales, si le compilateur détecte qu'elles ne sont pas initialisée dans le constructeur il va ajouter lui-même l'initialisation à la valeur par défaut (false, 0 ou null)

                • [^] # Re: Chacun son style

                  Posté par  (site web personnel) . Évalué à -1.

                  Et si on veut, pour des raison de performances, ne pas initialiser la valeur dans le constructeur mais plus tard?
                  par exemple (trivial, peu utile, mais pour démontrer un cas d’intérêt d'une variable non définie à l'init) :
                  int64_t value;
                  bool valueIsValid;
                  constructeur
                  {
                  valueIsValid=false;
                  //value=0; //Inutile, ne pas initialiser
                  }
                  void set (int64_t newValue)
                  {
                  value=newValue;
                  valueIsValid=true;
                  }
                  int64_t get ()
                  {
                  if (!valueIsValid) throw();
                  return value;
                  }

                  En C/C++, on peut faire en rapide, en Java comment on fait rapide si le compilo rajoute une initialialisation inutile et consommatrice de cycles? C'est un exemple bateau qui consomme peu, mais parfois quand c'est appelé 1000 milliard de fois, c'est du temps gagné.

                  Bref, plus je lis sur Java, plus j'ai une frustration sur l'optimisation de vitesse... Et je comprend de mieux en mieux pourquoi les programmes Java que j'ai pu avoir à sûbir ont besoin d'une machine de guerre en CPU, sans parler du garbage collector qui fait exploser le besoin de RAM. (Après, Sun était vendeur de machines, donc ça vallait le coup de filer un langage qui consomme...)

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 3.

                    mais parfois quand c'est appelé 1000 milliard de fois, c'est du temps gagné.

                    suffit de ne pas l'appeler 1000 milliard de fois, cong. si tu fais ça c'est qu'il y a un problème quelque part ou alors que tu le fais vraiment exprès, avec un programme qui tournera sur une très longue période de temps

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à 3.

                      suffit de ne pas l'appeler 1000 milliard de fois, cong.

                      Oui, il y a des fois des optimisations "changer l'algo". Mais ça ne répond pas à la question : quand c'est le seul et unique passage obligé, comment on fait en Java pour pas que ça rame?

                      Java, c'est "dit-moi ce dont tu as besoin, je te dirais comment t'en passer (on je vais ramer si je trouve pas)", bref tu ne réponds pas à la question à part "tu n'en as pas besoin", ça ne m'apporte rien.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 2.

                        oh ça me rappelle juste les développeurs de Firefox quand on leur dit que leur petit bébé est devenu un bloatosaure : "tu peux pas comprendre" "c'est hyper compliqué" "25 000 000 appels au zigouigoui engine !"

                        • [^] # Re: Chacun son style

                          Posté par  . Évalué à 2.

                          En attendant il semble que dans Aurora (firefox 7) ils aient diminués de 30% l'usage de la mémoire).

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 4.

                    Donc pour éviter d'initialiser ta variable, tu ajoute une variable booléenne, que tu initialise et que tu teste à chaque get et que tu dois en plus affecter à chaque set.
                    Hum...

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 1.

                      en plus affecter à chaque set.

                      Avec un static statement c'est fais qu'une seule fois.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Chacun son style

                        Posté par  (site web personnel) . Évalué à 3.

                        oui et c'est thread-safe.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 2.

                        Tu fais comment pour initialiser une variable d'instance avec un statement statique?
                        Je connais mal le C++, mais je ne vois pas comment une variable d'instance, qui est créée pour chaque instance de l'objet, pourrait n'être initialisée qu'une fois.

                        • [^] # Re: Chacun son style

                          Posté par  . Évalué à -4.

                          A la crade : le constructeur appelle une methode d'init statique...

                          • [^] # Re: Chacun son style

                            Posté par  . Évalué à 2.

                            On continue de progresser à reculons, donc c'est quand même initialisé à chaque création d'objet et tu y ajoute un appel de fonction.

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à 3.

                      c'est un exemple.
                      Dans l'idée, toutes les valeurs du int64_t sont valides (donc faire une test if(valeur) ne marche pas), donc il me faut ce bool pour dire que la valeur est valide ou pas. bref, j'ai besoin de 2^64+1 valeurs différentes (2^64 valeurs valides + 1 indicateur qui dit que la valeur est inconnue)

                      Si tu as une autre façon de faire pour savoir si une valeur est valide, je suis preneur, j'en ai plein des merdes comme ça qui me ralentissent...

                  • [^] # Re: Chacun son style

                    Posté par  (site web personnel) . Évalué à 2.

                    Et si on veut, pour des raison de performances, ne pas initialiser la valeur dans le constructeur mais plus tard?

                    Tu aurais un exemple intéressant? En général j'ai bien envie de dire que si tu crées ton objet pour ne pas t'en servir, autant attendre le bon moment pour la création. Quel gain en performances recherches-tu?

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 3.

                      Boost a un exemple qui me semble intéressant.

                      http://www.boost.org/doc/libs/1_46_1/libs/optional/doc/html/boost_optional/examples.html#boost_optional.examples.bypassing_expensive_unnecessary_default_construction

                      Tu initialise la taille du vecteur dans le constructeur pour ne pas qu'il soit déplacé par la suite, mais la construction des objets qu'il contiens est lourde (en même temps que je l'explique je me dis qu'un appel à reserve() serais encore plus efficace).

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 2.

                        Ce n'est pas un problème, en java (puisque c'est quand même la base de la discussion) les éléments sont simplement initialisés à null et la création des instances lourdes peut être faite à la demande.

                        • [^] # Re: Chacun son style

                          Posté par  . Évalué à 2.

                          Pour un ArrayList, je crois qu'il appel le constructeur par défaut.
                          Mais oui l'équivalent du optional de boost c'est le null de Java.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Chacun son style

                    Posté par  (site web personnel) . Évalué à 2.

                    Le jit de java est du niveau de gcc -o0 ou gcc -o1, des mini optims "à la con" font de gain énorme de performances (genre virer les setter/getter qui ne sont pas inliner !)

                    "La première sécurité est la liberté"

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 1.

                      D’ailleurs connait-on la raison de ne pas inliner les get/set?

                      • [^] # Re: Chacun son style

                        Posté par  (site web personnel) . Évalué à 3.

                        quand ils sont virtuels et donc potentiellement surchargés ?

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 1.

                        connait-on la raison de pourquoi on les implémente ? :-)

                        • [^] # Re: Chacun son style

                          Posté par  . Évalué à 5.

                          Ton commentaire est sans doute une touche d'humour (au vu du smiley), mais il sonne tout de même assez juste. En effet, au yeux de pas mal de programmeurs, la POO c'est mettre des classes et ajouter un set et un get à chaque membre. Et au final on n'a rien gagné et on ne raisonne pas du tout en objet ayant un comportement avec une telle méthode. Je me dois donc de plusser ton commentaire pour inciter les programmeurs à se poser la question du pourquoi ajouter un getter/setter à un membre.

                          Étienne

                          • [^] # Re: Chacun son style

                            Posté par  (site web personnel) . Évalué à 5.

                            A court terme, c'est parfaitement inutile.

                            A long terme, si tu te rend compte de l'inadéquation de ton modèle de donnée dans la classe, c'est facile de le changer et de garder les getter/setter précédent.

                            En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.

                            "La première sécurité est la liberté"

                            • [^] # Re: Chacun son style

                              Posté par  (site web personnel) . Évalué à 4.

                              Un autre avantage reste le debug. Ok, c'est peut-être limité et dans certains cas / langages on peut faire autrement, mais placer un point d'arrêt dans un get/set est juste très pratique.

                              Ensuite, sur la discussion get/set on dirait que vous n'avez que des get/set bidons genre

                              setPlop: function(plop) {
  this.plop = plop;
}

                              Mais l'avantage d'avoir des get/set est aussi de permettre de centraliser une partie de vérifications / tests, pouvoir j'en sais rien, gérer des compteurs lors des accès, lancer des exception, réaliser des traitements sur le set, etc.
                              C'est aussi assez sympa pour faire du lazy load.
                              Ha oui, et le tout en le masquant de l'utilisation.
                              L'autre intérêt est aussi de séparer la visibilité, masquer les variables et ne présenter que des méthodes.

                              Ensuite, l'inline par le compilo devrait régler les problèmes de perf.

                              • [^] # Re: Chacun son style

                                Posté par  (site web personnel) . Évalué à 1.

                                Tu as tout à fait raison.
                                C'est pourquoi il est important de systématiquement utiliser des getter/setter : même si ca paraît idiot dans un premier temps, celà reste une bonne pratique essentielle à des concepts fondamentaux de la programmation objet : l'encapsulation et le contrat d'interface. Je cache les détails d'implémentation, qui peuvent évoluer d'un simple accès une variable à un truc plus complexe, tout en évitant de casser le contrat d'interface exposé aux utilisateurs de ma classe.

                                • [^] # Re: Chacun son style

                                  Posté par  . Évalué à 1.

                                  un int id; int getId() et setId(int _id); ne cache aucun détail d'implémentation

                                  • [^] # Re: Chacun son style

                                    Posté par  . Évalué à 2.

                                    private int id; en fait, mais ça ne change rien

                                  • [^] # Re: Chacun son style

                                    Posté par  . Évalué à 2.

                                    Aujourd'hui peut être mais demain peut être que ton identifiant tu iras le chercher à l'autre bout de la planète et tu préfèrerais donc faire de l'initialisation paresseuse, par exemple.

                                    Peut être que tu délègueras la gestion de cet identifiant à un autre objet membre, aussi.

                                    Tu pourrais vouloir sauvegarder en base de données ton identifiant à chaque fois qu'il change.

                                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: Chacun son style

                                Posté par  (site web personnel) . Évalué à 2.

                                Ensuite, l'inline par le compilo devrait régler les problèmes de perf.

                                C'est le "devrait" le problème : le jit de sun ne le fait pas.

                                "La première sécurité est la liberté"

                                • [^] # Re: Chacun son style

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Ha mais là je suis totalement d'accord ;)
                                  Mais d'ailleurs ce n'est pas suffisant tout court en java, car il faudrait pouvoir choisir de faire l'inline ou non en debug/release (concept assez inconnu et incompréhensible pour beaucoup de dev java...)

                            • [^] # Re: Chacun son style

                              Posté par  . Évalué à 3.

                              En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.

                              Mais c'est le principe de la POO d'avoir une liaison entre une classe et son usage. Rajouter un getter et un setter sur chacun de ses membres ce n'est pas de l'encapsulation, ça fait plaisir à ceux qui considèrent que tous les membres doivent être privés sans avoir trop à réfléchir. Je ne dit pas que la POO est la réponse à tous les problèmes, mais rajouter des get/set sans réflechir ce n'est pas de la POO.

                              En POO, on devrait réfléchir en terme de comportement et non de structure. Si je design une voiture en POO (l'exemple est un peu éculé, j'en suis désolé), ce qui m'intéresse c'est de la faire avancer, pas qu'elle ait 4 roues.

                              Par exemple, les getter et setter vont à l'encontre de la Loi_de_Déméter qui incite justement à programmer le comportement d'un objet et à moins s'attacher à sa composition (je cite l'article wikipédia : En particulier, un objet doit éviter d'invoquer des méthodes d'un membre objet retourné par une autre méthode).

                              Je ne parle bien sûr ici pas des objets "techniques" (un vecteur, un accès à une BDD, ...) mais de la partie fonctionnelle d'une application.

                              Étienne

                              • [^] # Re: Chacun son style

                                Posté par  (site web personnel) . Évalué à 3.

                                Si je design une voiture en POO (l'exemple est un peu éculé, j'en suis désolé), ce qui m'intéresse c'est de la faire avancer, pas qu'elle ait 4 roues.
                                J'achèterai jamais ta voiture si tu ne t'assures pas que je puisse changer les roues : si tu me dis que les roues sont directement soudées sur l'arbre de transmission parcque t'avais oublié de mettre une interface de type écrou...

                                Par exemple, les getter et setter vont à l'encontre de la Loi_de_Déméter W
                                Bien au contraire ! Exposer des membres directement sans getter/setter, c'est exposer toutes les hypothèses de ton implémentation aux objets qui utilisent le tient. Hors ce que dit la loi, je cite :

                                "La notion fondamentale est qu'un objet devrait faire aussi peu d'hypothèses que possible à propos de la structure de quoi que ce soit d'autre, y compris ses propres sous-composants."

                                La seule façon de s'assurer que tu ne puisses pas faire d'hypothèse sur la structure d'un objet, c'est d'en cacher tous les détails d'implémentation, et un membre exposé directement sans getter/setter, c'est exactement ça.

                                "Un désavantage de la règle de Déméter est qu'elle requiert l'écriture d'un grand nombre de petites méthodes "wrapper" pour propager les appels de méthodes à leurs composants. "

                                En gros cette loi conduit au contraire à écrire encore plus de getter/setter :
                                Au lieu d'écrire :
                                obj.getVoiture().getFirstRoue()
                                tu te retrouves à ajouter à ton obj un autre getter :
                                obj.getFirstRoueFromVoiture()

                                • [^] # Re: Chacun son style

                                  Posté par  . Évalué à 1.

                                  Hors ce que dit la loi, je cite :

                                  s/Hors/Or/, j'imagine. Oui je sais tu fais moins classe avec un mot aussi court et lucratif.

                                • [^] # Re: Chacun son style

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Non, nous nous retrouvons avec un car.doStuffOnFirstWheel(). La clé est bien de penser en termes de services, et non en termes de données.

                                  • [^] # Re: Chacun son style

                                    Posté par  (site web personnel) . Évalué à 2.

                                    Le problème de ce principe, c'est qu'il oppose service et données : il faut effectivement penser "service", mais parfois ton service c'est d'exposer des données : DTO, Controller, DOM, Composants IHM, etc.

                                    Reprends mon exemple de la voiture, moi je veux pouvoir changer moi même la roue, c'est ça le service que j'attend. Pas que la voiture m'expose un numéro de téléphone qui dépende de mon garagiste.

                                    De plus ton principe n'est applicable que si tu as la main sur le code de la voiture car, auquel cas tu peux ajouter toi même la méthode doStuffOnFirstWheel. Et si cette méthode est dans une bibliothèque, tu fais comment ? tu dérives à tout va ? Piouuu.

                                    • [^] # Re: Chacun son style

                                      Posté par  (site web personnel) . Évalué à 2.

                                      obj.getVoiture().getFirstRoue()

                                      là, c'est facile, c'est des getter, mais imagines que ta roue se "balade" dans ton code. Si tu appelles un seul setter, tu va modifier la roue mais aussi la voiture par la même occasion. C'est rarement ce que tu veux faire.

                                      "La première sécurité est la liberté"

                                      • [^] # Re: Chacun son style

                                        Posté par  (site web personnel) . Évalué à 2.

                                        Là encore, ca dépend fortement de ce que tu veux faire, si c'est par exemple :
                                        obj.getVoiture().geetFirstRoue().setNewPneu(new Michelin())

                                        autre exemple :
                                        doc.getNodes().first().getNodeById("3").setAttribute("name", "toto")

                                        Bon courrage pour le faire avec la loi pré-citée.

                                        • [^] # Re: Chacun son style

                                          Posté par  (site web personnel) . Évalué à 4.

                                          La loi a raison. Pour ton deuxième exemple bien complexe, tu as 2 cas de figures : soit il y a très peu de ce genre de pattern, et il est simple d'en faire des méthodes circonscrites à une seul classe, soit tu en as plein et tu est vraiment dans la m... par ce que ce truc va vite devenir complètement in-maintenable.

                                          "La première sécurité est la liberté"

                                          • [^] # Re: Chacun son style

                                            Posté par  (site web personnel) . Évalué à 3.

                                            Mon deuxième exemple est une API classique pour accéder un à DOM XML.
                                            Que proposes-tu concrêtement comme code pour un résultat identique ?

                                        • [^] # Re: Chacun son style

                                          Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                          Tu viens d'exposer le gros problème des accesseurs bêtes sans réflexion. Tu changes le pneu sur la roue, sans notifier la voiture que tu as changé le pneu. Comment la voiture le sais ? Si le calcul de la trajectoire dépend de la qualité du pneu, ça peut être un problème si l'implémentation de la voiture n'utilise pas l'objet roue qui aura été retourné. C'est clairement un problème d'encapsulation.

                                          Et vu qu'en C++, on renvoie généralement des références sur const, ben, ton objet accédé ne sera pas mis à jour.

                                          Moi je verrais plutôt un truc comme ça :

                                          Voiture mercedes = parking.sortirVoiture("111 AAA 111") ;
try
{ mercedes.changeRoue(0, PneuMichelin(12, 10)) ;
} catch(PneuIncompatible const &e) {
  // annuler la commande ?
}
parking.rangerVoiture(mercedes) ;

                                          Tu remarqueras qu'il n'y a pas d'accésseurs, mais uniquement des méthodes métier. Je pense que les accesseurs ne sont pas une bonne idée. Évidement, c'est Java qui a popularisé la méthode.

                                          • [^] # Re: Chacun son style

                                            Posté par  (site web personnel) . Évalué à 2.

                                            Tu changes le pneu sur la roue, sans notifier la voiture
                                            C'est son problème, pas le miens.

                                            Comment la voiture le sais ?
                                            Bah rien ne l'empêche de communiquer avec ses roues, par exemple s'abonner avec le patron observateur pour savoir qu'il y a un truc qui l'intéresse qui se passe sur ses roues.

                                            Prend un autre exemple, je veux redimensionner le bouton contenu dans une fenêtre :

                                            app.getMainWindow().getContainer().getChild(1).resize(10,3)

                                            Tu crois que le container et la Window sont inccapables de se redimensionner automatiquement parcque je ne les ai pas notifié ?

                                            t'aurais fais comment sans les get ?
                                            app.resizeFirstChildOfContainerInMainWindow(10, 3) ?

                                            Comment prévoir tous ces cas ?

                                            L'objectif est d'exposer une API conviviale et intuitive, après c'est le problème de celui qui créé la lib de s'assurer que l'état de tous les objets du graphe qu'il expose reste cohérent.

                                            Et vu qu'en C++, on renvoie généralement des références sur const, ben, ton objet accédé ne sera pas mis à jour.

                                            Oué enfin si on pouvait éviter de prendre le C++ comme langage de référence quand on parle programmation objet ca serait pas mal :)

                                            Tu remarqueras qu'il n'y a pas d'accésseurs, mais uniquement des méthodes métier.

                                            Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur. C'est peut-être l'effet recherché tu me diras. Si t'es garagiste, tu peux avoir envie de bricoler sans t'en tenir aux seuls cas imaginer par le fabriquant.

                                            Je pense que les accesseurs ne sont pas une bonne idée. Évidement, c'est Java qui a popularisé la méthode.

                                            Qu'on soit clair : l'objectif n'est pas de dire "mettez des accesseurs sur tous vos membres". L'objectif est d'utiliser des accesseurs quand il y a une interface intéressante à exposer.

                                            • [^] # Re: Chacun son style

                                              Posté par  (site web personnel) . Évalué à 2.

                                              Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur.

                                              non, tu encapsules, ou au pire, tu hérites, voir tu hérites juste de la bonne interface avec l'encapsulation.

                                              "La première sécurité est la liberté"

                                              • [^] # Re: Chacun son style

                                                Posté par  (site web personnel) . Évalué à 1.

                                                tu encapsules, ou au pire, tu hérites

                                                Ca changera rien, le programmeur, par soucis d'encapsulation et de cacher les détails d'implémentation ne t'as donné aucun get, même "protected" pour accéder à tes roues. Bref, t'es mort.

                                                Et que proposes tu sur
                                                app.getMainWindow().getContainer().getChild(1).resize(10,3)
                                                ?

                                                • [^] # Re: Chacun son style

                                                  Posté par  . Évalué à 2.

                                                  D'appliquer le design pattern Observateur ! Quand un élément subit un redimensionnement, il en informe tous les éléments qui l'écoutent (à savoir, l'élément-parent, au minimum).
                                                  Par effet de cascade, tu vois ta fenêtre se redimensionner "automagiquement"

                                                  • [^] # Re: Chacun son style

                                                    Posté par  (site web personnel) . Évalué à 2.

                                                    Oui, merci, ca c'est la solution que je donnais 2 commentaires plus haut :)

                                                    Je demandes justement quelle solution ils proposent qui respecte la loi de Démeter sans faire appel aux get/set.

                                            • [^] # Re: Chacun son style

                                              Posté par  (site web personnel, Mastodon) . Évalué à 4.

                                              Prend un autre exemple, je veux redimensionner le bouton contenu dans une fenêtre :
                                              app.getMainWindow().getContainer().getChild(1).resize(10,3)

                                              Quel est le sens pour, un objet qui a accès à l'objet app, de modifier un détail de la représentation des données à l'écran ?

                                              Tu crois que le container et la Window sont inccapables de se redimensionner automatiquement parcque je ne les ai pas notifié ?

                                              Ben oui, ils savent pas, ils font pas. Sauf si tu as une loop qui tourne fear

                                              t'aurais fais comment sans les get ?
                                              app.resizeFirstChildOfContainerInMainWindow(10, 3) ?

                                              Je ne le ferais pas car ça n'a pas de sens, dans le cas présent.

                                              Comment prévoir tous ces cas ?

                                              Est-ce nécessaire ? Est-ce qu'un composant graphique doit être modifiable par n'importe quelle portion du code qui l'utilise ?

                                              Oué enfin si on pouvait éviter de prendre le C++ comme langage de référence quand on parle programmation objet ca serait pas mal :)

                                              En matière de programmation orientée objet, il n'y a pas plus complet et avancé que le C++. D'aucun diront qu'il est même indigeste et incompréhensible.
                                              En C++, tu as les interfaces (classes abstraites), les classes et fonctions membres finales (bon ok, là c'est vraiment bricolo), le polymorphisme sous toutes ces formes, l'encapsulation (contrairement à Python qui se prétend orienté objet alors qu'il expose tout), la programmation fonctionnelle, etc. Mais si tu vois un concept manquant, je suis tout ouïe.

                                              Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu.
                                              Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur. C'est peut-être l'effet recherché tu me diras. Si t'es garagiste, tu peux avoir envie de bricoler sans t'en tenir aux seuls cas imaginer par le fabriquant.

                                              Je suppose que tu voulais dire que la mercedes a la fonction :o)

                                              C'est évidement l'objectif de la programmation orientée objet : des boîtes noires avec une interface pour faire des choses. Et si tu as besoin que la boîte noire fasse plus de choses, tu travailles avec le constructeur pour qu'il améliore la boîte noire. Sinon, comme tu l'as dit, ce sera du bricolage et la fiabilité de la voiture va légèrement en souffrir.
                                              D'ailleurs, j'ai bien parlé de calcul de trajectoire dans mon message, et ce n'était pas anodin. La plupart des véhicules modernes tendent à nécessité un outil informatique afin de réaliser les opérations de maintenance courante comme la vidange. Alors le changement de pneu !

                                              • [^] # Re: Chacun son style

                                                Posté par  (site web personnel) . Évalué à 2.

                                                Quel est le sens pour, un objet qui a accès à l'objet app, de modifier un détail de la représentation des données à l'écran ?

                                                Bah ca peut être le controller de l'application tout simplement.

                                                Où n'importe quoi, on s'en fou pas mal, ce qui compte c'est que ce type d'API existe réellement : il t'expose un arbre d'objets, et les méthodes sont placés sur les noeuds où c'est intuitivement là que tu les chercherais. Tu peux te placer au niveau que tu veux, imaginer le scénario que tu veux, l'API restera la même.

                                                Ben oui, ils savent pas, ils font pas. Sauf si tu as une loop qui tourne fear

                                                C'était ironique, j'ai indiqué la solution juste au-dessus : le patron de conception observateur. C'est pas de la théorie, c'est comme ça que c'est fait en pratique.

                                                Je ne le ferais pas car ça n'a pas de sens, dans le cas présent.

                                                Se cacher derrière la sémantique de l'exemple, c'est petit :) Imagine toi le scénario que tu veux, l'API reste identique.

                                                Est-ce qu'un composant graphique doit être modifiable par n'importe quelle portion du code qui l'utilise ?

                                                Quelque soit la portion de code, il faut qu'ils soient modifiables : tu fais l'API de composants graphiques, tu ne sais pas qui ni comment il va l'utiliser. Tu dois par contre exposer tes services : accès composant, modification des composants, etc.

                                                Mais si tu vois un concept manquant, je suis tout ouïe.

                                                L'introspection ?
                                                Le fait que pleins de type de base ne soit pas eux-même des objets ?
                                                Le fait que des fonctions puissent ne pas être raccroché à des définitions de classe ?
                                                Le fait de pouvoir aller modifier n'importe quel objet avec un bête pointeur baladeur ?
                                                Le fait qu'il n'est pas possible d'exposer une API C++ avec des templates qui soit réutilisable ?

                                                Je suppose que tu voulais dire que la mercedes a la fonction :o)

                                                Je voulais dire "que la mercedes ai la fonction" ;)

                                                des boîtes noires avec une interface pour faire des choses
                                                Ce que j'essai d'expliquer, c'est que cette fameuse interface peut être explosée en plusieurs interfaces et présentée à l'utilisateur sous la forme d'une arborescence, sans pour autant exposer plus d'information et donc enfreindre le principe d'encapsulation.

                                                La loi de Demeter a un objectif, certe louable, mais qui ne penses pas utilisateur : quand tu fais une API, tu la conçois de telle sorte qu'elle soit simple, intuitive et aisée à découvrir. Si on suit la loi de Demeter, on a une espèce de façade géante à tous les étages : non seulement l'objectif n'est pas atteint (pleins de méthodes proxy totalement inutiles, donc plus de code à maintenir) mais ca fait une API totalement bloated.

                                                Dans une API de voiture, je m'attend à pouvoir accéder au pneu sur l'objet roue que j'ai récupéré sur la voiture. Je m'attend pas à avoir 15000 méthodes directement sur mon objet voiture.

                                                Dans une API de composants graphiques, je m'attends à ce que la méthode de redimensionnement d'un objet soit sur l'objet concerné, pas sur son parent, son grand-parent ou sa soeur.

                                                Dans une API Xml, je veux pouvoir modifier un attribut d'un noeud directement sur le noeud et pas sur la classe Document.

                                                Mais je penses qu'on est dans 2 façon différentes de penser :
                                                * Je penses API, composants réutilisable par un tiers
                                                * Tu penses objet et logique métier.

                                                C'est pas forcement contradictoire, mais ce qui est sûr, c'est que la loi de Demeter est beaucoup trop théorique pour être applicable dans toutes les situations en pratique.

                                                • [^] # Re: Chacun son style

                                                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                                  Bah ca peut être le controller de l'application tout simplement.

                                                  C'est bien ça le problème, le tout simplement. On risque d'avoir beaucoup de complexité dans le contrôleur si on commence comme ça.

                                                  Se cacher derrière la sémantique de l'exemple, c'est petit :) Imagine toi le scénario que tu veux, l'API reste identique.

                                                  :D

                                                  Quelque soit la portion de code, il faut qu'ils soient modifiables : tu fais l'API de composants graphiques, tu ne sais pas qui ni comment il va l'utiliser. Tu dois par contre exposer tes services : accès composant, modification des composants, etc.

                                                  Oui, avec une classe qui expose ce qui est nécessaire et suffisant au pilotage du composant.

                                                  L'introspection ?

                                                  Je voulais parler des fonctionnalités utiles, pas des gadgets qui ne servent qu'à bricoler au runtime.

                                                  Le fait que pleins de type de base ne soit pas eux-même des objets ?

                                                  Ça dépend ce qu'on appelle un objet.

                                                  Le fait que des fonctions puissent ne pas être raccroché à des définitions de classe ?

                                                  C'est un avantage de C++ sur Java. De mettre toute le code dans une classe peut poser des problèmes d'encapsulation. Pourquoi une fonction facrory devrait absolument avoir accès aux membres privés ?

                                                  Le fait de pouvoir aller modifier n'importe quel objet avec un bête pointeur baladeur ?

                                                  Ça n'a rien à voir avec le caractère orienté objet du langage.

                                                  Le fait qu'il n'est pas possible d'exposer une API C++ avec des templates qui soit réutilisable ?

                                                  Exemple ?

                                                  La loi de Demeter a un objectif, certe louable, mais qui ne penses pas utilisateur : quand tu fais une API, tu la conçois de telle sorte qu'elle soit simple, intuitive et aisée à découvrir. Si on suit la loi de Demeter, on a une espèce de façade géante à tous les étages : non seulement l'objectif n'est pas atteint (pleins de méthodes proxy totalement inutiles, donc plus de code à maintenir) mais ca fait une API totalement bloated.

                                                  Ça dépend du type d'API que tu développe. C'est toujours le même problème : qu'est-ce qui peut être exposé, et à quel usage est destiné le composant.

                                                  Dans une API de voiture, je m'attend à pouvoir accéder au pneu sur l'objet roue que j'ai récupéré sur la voiture. Je m'attend pas à avoir 15000 méthodes directement sur mon objet voiture.

                                                  Récupérer le pneu, oui, puis le modifier et le remplacer. Mais l'assigner directement, c'est chercher les problèmes. Évidement qu'on peut mettre des observateurs dans tout les sens, mais est-ce que sa simplifie vraiment l'usage ?

                                                  Dans une API de composants graphiques, je m'attends à ce que la méthode de redimensionnement d'un objet soit sur l'objet concerné, pas sur son parent, son grand-parent ou sa soeur.

                                                  Moi aussi je m'attends à ce que le composant enfant ait cette fonctionalité. Mais lorsque tu composes une vue, et que l'ensemble de la vue nécessite des calculs particulier pour l'affichage, est-il pertinent de laisser n'importe qui venir modifier l'état interne d'un des composant.

                                                  Dans une API Xml, je veux pouvoir modifier un attribut d'un noeud directement sur le noeud et pas sur la classe Document.

                                                  Est-ce que modifier un nœud modifie l'état du parent ? Tu remarquera que pour remplacer un nœud, dans le DOM, on assigne pas le nœud ou on de modifie pas le nœud : on demande à son parent de le remplacer. Pareil pour créer un nouvel élément, on demande au document un nouveau nœud. Je crois que la loi de Demether a frappé là où tu ne l'attendais pas. D'ailleurs, ici, la logique métier c'est la gestion d'un arbre XML, et les méthodes exposées exposent bien les fonctionnalités de gestion de l'arbre.

                                                  Mais je penses qu'on est dans 2 façon différentes de penser :
                                                  * Je penses API, composants réutilisable par un tiers
                                                  * Tu penses objet et logique métier.
                                                  C'est pas forcement contradictoire, mais ce qui est sûr, c'est que la loi de Demeter est beaucoup trop théorique pour être applicable dans toutes les situations en pratique.

                                                  Je pense que c'est complémentaire, comme toujours, une succession de compromis.

                                                  • [^] # Re: Chacun son style

                                                    Posté par  (site web personnel) . Évalué à 2.

                                                    Oui, avec une classe qui expose ce qui est nécessaire et suffisant au pilotage du composant.

                                                    ...

                                                    Donc, vas-y, donne nous ta version de code qui fait la même chose en respectant la fameuse loi.

                                                    Je voulais parler des fonctionnalités utiles, pas des gadgets qui ne servent qu'à bricoler au runtime.

                                                    Trolleur :)

                                                    Ça n'a rien à voir avec le caractère orienté objet du langage.

                                                    Euh, pouvoir se balader avec un pointeur, c'est pouvoir défoncer n'importe quelle tentative d'encapsulation.

                                                    Exemple ?

                                                    Tu connais beaucoup d'API qui exposent leurs paramètres avec les types de la STL ? A ton avis, pourquoi ne le font-elles pas ?

                                                    Ça dépend du type d'API que tu développe.

                                                    Exemple ?

                                                    Mais l'assigner directement, c'est chercher les problèmes. Évidement qu'on peut mettre des observateurs dans tout les sens, mais est-ce que sa simplifie vraiment l'usage ?

                                                    Tu mets ce que tu veux dans le set hein, tu peux faire plein de contrôle, discuter avec la voiture toussa.
                                                    Mais oui, ca simplifie l'usage. Si on part de ton principe, cad mettre la méthode changeWheel sur la voiture, faisons de même pour toutes les pièces remplaçable de la voiture (1000 ?), tu fais une façade géante de 1000 méthodes ou tu éclates en un graphe d'objets ?

                                                    est-il pertinent de laisser n'importe qui venir modifier l'état interne d'un des composant.

                                                    Si c'est utile pour l'utilisateur, simple et intuitif, oui. Après tu fais ce que tu veux dans le setter pour assurer la cohérence globale. De toute façon le faire dans une fafade géante te conduiras à assurer le même niveau de cohérence.

                                                    Est-ce que modifier un nœud modifie l'état du parent ?
                                                    Oui potentiellement : si ton noeud parent a une propriété qui indique si elle contient d'autres éléments (HasChild), tu modifies bien son état (d'un point de vu utilisateur).

                                                    Tu remarquera que pour remplacer un nœud, dans le DOM, on assigne pas le nœud ou on de modifie pas le nœud : on demande à son parent de le remplacer.

                                                    Toutafé : on demande au parent (y'a pas le choix tu remplaces), et pas à l'ancètre le plus haut (le document) comme aurait dû y conduire la fameuse loi de Demeter.

                                                    Par code, ça donnerait, pour remplacer un noeud :

                                                    doc.getNode('item3').getChildNode('title').setChildNode(2, new Node("fr-FR"))

                                                    Si on avait suivi la fameuse loi, tu aurais écris quoi ?

                                                    Je crois que la loi de Demether a frappé là où tu ne l'attendais pas.

                                                    Arrête de théoriser, donne nous du code. Je m'évertue à montrer qu'en pratique cette loi ne marche pas, prouve le contraire en mettant l'équivalent de ce que j'écris.

                                                    • [^] # Re: Chacun son style

                                                      Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                                      Donc, vas-y, donne nous ta version de code qui fait la même chose en respectant la fameuse loi.

                                                      Le soucis est que tu veux faire quelque chose d'aberrant (contrôler le rendu graphique depuis n'importe quel point de l'application). Ça posera beaucoup de problèmes d'interdépendance des différentes parties du code, si tu fais ça.

                                                      Trolleur :)

                                                      Certes, mais je ne parviens toujours pas à comprendre l'intérêt de l'introspection.

                                                      Euh, pouvoir se balader avec un pointeur, c'est pouvoir défoncer n'importe quelle tentative d'encapsulation.

                                                      Sauf qu'il faut vraiment en vouloir pour défoncer l'encapsulation. À ce moment, on en est plus à de la négligence mais à de la malfaisance. L'encapsulation est un outil qui permet aux développeurs de se protéger d'eux-même. Ce n'est pas un système de protection mémoire.

                                                      Tu mets ce que tu veux dans le set hein, tu peux faire plein de contrôle, discuter avec la voiture toussa.
                                                      Mais oui, ca simplifie l'usage. Si on part de ton principe, cad mettre la méthode changeWheel sur la voiture, faisons de même pour toutes les pièces remplaçable de la voiture (1000 ?), tu fais une façade géante de 1000 méthodes ou tu éclates en un graphe d'objets ?

                                                      En quoi serait-ce pertinent d'exposer les 1000 pièces de la voiture ? C'est typiquement le genre de cas où on aura besoin d'un mécanicien, un objet qui sait comment visiter la voiture et la modifier. Exposer une méthode pour chaque élément de la voiture briserait évidement l'encapsulation et serait stupide.
                                                      Quand au graphe d'objet interne de la voiture, il ne serait pas disponible pour l'utilisateur de la classe, mais uniquement pour des visiteurs.

                                                      Toutafé : on demande au parent (y'a pas le choix tu remplaces), et pas à l'ancètre le plus haut (le document) comme aurait dû y conduire la fameuse loi de Demeter.
                                                      Tu viens de montrer que tu n'as pas compris la loi de Déméter.

                                                      Par code, ça donnerait, pour remplacer un noeud :
                                                      doc.getNode('item3').getChildNode('title').setChildNode(2, new Node("fr-FR"))
                                                      Si on avait suivi la fameuse loi, tu aurais écris quoi ?

                                                      // Et encore, la fonction membre setChildNode n'a pas une signature géniale
doc.getNode('item3').getChildNode('title').setChildNode(2, doc.createNode("fr-FR")) ;

                                                      Je pense que tu as un sérieux problème à séparé les responsabilités. Ici, on veut modifier un arbre XML. C'est le métier du code, donc il n'y a pas de soucis à faire ce qu'on fait ici. Si le XML était plus spécialisé, on aurait des classes et des méthodes plus adaptés, à l'image de DOM HTML.

                                                      Arrête de théoriser, donne nous du code. Je m'évertue à montrer qu'en pratique cette loi ne marche pas, prouve le contraire en mettant l'équivalent de ce que j'écris.

                                                      Je ne théorise pas. C'est toi qui ne comprend pas ce qu'est la loi de minimisation des interaction d'un objet avec d'autres objets. La programmation est une affaire de compromis, ce qui fait qu'appliquer bêtement la loi de Déméter est absurde. Mais c'est tout aussi absurde de la jeter avec l'eau du bain.

                                                      • [^] # Re: Chacun son style

                                                        Posté par  (site web personnel) . Évalué à 1.

                                                        Le soucis est que tu veux faire quelque chose d'aberrant (contrôler le rendu graphique depuis n'importe quel point de l'application).

                                                        Réponds par du code s'il te plaît : mon application a besoin de faire la modification que j'ai précisé, moi ca tient en une ligne, que proposes-tu qui soit plus maintenable et qui respecte la fameuse loi ?

                                                        Certes, mais je ne parviens toujours pas à comprendre l'intérêt de l'introspection.

                                                        L'intérêt ? De travailler au niveau du méta-modèle, de faire de la méta-programmation.
                                                        Découverte dynamique de type, de composants (plugins), sérialisation automatique, génération dynamique de proxy, de stub, de service web, programmation par aspect, etc.
                                                        Le C++ a essayé d'ajouter un minimum de support à travers le mot clé "typeid", mais ce n'est clairement pas suffisant. Qt a dû modifié le language pour introduire un concept un peu similaire.

                                                        Sauf qu'il faut vraiment en vouloir pour défoncer l'encapsulation. À ce moment, on en est plus à de la négligence mais à de la malfaisance.

                                                        Certes, l'exploitation de cette technique est de la malfaisance, mais parfois c'est un simple débordement de tampon par négigeance qui conduit à une faille exploitable (par malfaisance).

                                                        L'encapsulation est un outil qui permet aux développeurs de se protéger d'eux-même.

                                                        Le soucis du C++, c'est que l'utilisateur d'un composant ne peut pas ignorer sa structure interne : l'organisation des champs pourtant "privés", et la taille globale qu'ils représentent a un impact direct sur son utilisation.

                                                        Quand au graphe d'objet interne de la voiture, il ne serait pas disponible pour l'utilisateur de la classe, mais uniquement pour des visiteurs.

                                                        Là encore, tu théorises, sans vouloir écrire de code, mais va jusqu'au bout : tu vas obligé l'utilisateur/visiteur à implenter le pattern visiteur alors qu'il ne veut pas tout parcourir ? Comment vas-tu lui permettre d'atteindre sa cible ? (encore une fois, du code, merci).

                                                        Je pense que tu as un sérieux problème à séparé les responsabilités. Ici, on veut modifier un arbre XML. C'est le métier du code, donc il n'y a pas de soucis à faire ce qu'on fait ici.

                                                        Ah bah voilà ! C'est ce que je me tues à expliquer : par nature, certains API exposent "naturellement" pour l'utilisateur un arbre. J'ai pris 2 exemple : une API XML et une API de toolkit graphiques. Et il y a pleins d'autres exemples : API d'introspection, API SGBD, API de dessin vectoriel, API d'impression, API d'automatisation, etc.

                                                        objets. La programmation est une affaire de compromis, ce qui fait qu'appliquer bêtement la loi de Déméter est absurde. Mais c'est tout aussi absurde de la jeter avec l'eau du bain.

                                                        On est d'accord, c'est ce que je me tues à expliquer depuis le début : exposer des get/set n'est pas toujours absurde, bien au contraire. c'est pas pour autant qu'il faut systématiquement le faire.

                                          • [^] # Re: Chacun son style

                                            Posté par  . Évalué à 2.

                                            En fait ton exemple est pertinent, mais ce qu'essayais d'expliquer ceux qui parlaient plus haut c'était de ne pas exposer d'attribut en publique et donc d'écrire des accesseurs/modifieurs à la place. Il n'est pas toujours pertinents de les faire mais c'est toujours pour passer par des appels de méthodes et pas mettre des attributs en public.

                                            D'ailleurs l'une des erreur classique consiste a faire un accesseur de Collection en Java ou de vector en C++ par exemple. Il vaut mieux dans la mesure du possible faire une sorte de délégation.

                                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                    • [^] # Re: Chacun son style

                                      Posté par  . Évalué à 4.

                                      Le problème de ce principe, c'est qu'il oppose service et données : il faut effectivement penser "service", mais parfois ton service c'est d'exposer des données : DTO, Controller, DOM, Composants IHM, etc.

                                      C'est pour ça que je parlais plutôt de la partie fonctionnelle du code, les classes dont l'objectif est de fournir des données ne rentrent pas dans ce cadre.

                                      Si tu veux changer tes roues, tu as :
                                      * une factory qui sait te fabriquer des roues
                                      * une méthode changeWheels() de la voiture pour changer les roues

                                      Ce que la loi t'incite à faire, c'est à raisonner en terme fonctionnel et à faire l'analyse des services fournis par ton objet. Et encore un fois, je ne parle pas ici des classes vraiment techniques (factory, parser, container, ...).

                                      Pour reprendre l'exemple de The Paperboy, The Wallet, and The Law Of Demeter, Lorsque le garçon doit payer, on peut avoir :
                                      * une classe Customer avec une méthode getWallet et la caissière prend le porte monnaie et enlève l'argent du porte monnaie
                                      * ou alors une class Customer avec une méthode pour payer

                                      Comme le dit la section "Why Is This Better?", la deuxième solution représente mieux le monde réel.

                                      Étienne

                                      • [^] # Re: Chacun son style

                                        Posté par  (site web personnel) . Évalué à 2.

                                        Je penses qu'on est d'accord : il est évident qu'il ne faut pas se contenter d'utiliser des objets/données en se disant "j'ai mis des get/set, je fais de l'objet", et qu'il faut écrire des fonctions métiers plus élémentaires, tant qu'on parle de code métier.

                                        Après le débat initial était surtout d'indiquer qu'il était largement préférable d'utiliser les get/set vs l'accès direct aux membres, même si à première vu le get ne faisait pas grand chose.

        • [^] # Re: Chacun son style

          Posté par  (site web personnel) . Évalué à 6.

          Et puis qui peut se targuer d'avoir un code qui marche du premier coup ?

          Moi, depuis que je programme en OCaml! Sans blague le typage fort de OCaml permet au compilateur de supprimner presque toutes les erreurs d'étourderies qu'on peut faire en programmant, ce qui reste ce sont les vraies bonnes grosses erreurs comme un faux algorithme ou un mauvais emploi (on utilise une ressource système libérée, etc.).

      • [^] # Re: Chacun son style

        Posté par  . Évalué à -2.

        Je suis tout à fait d'accord, apprendre à programmer avec Java c'est une belle connerie.

        De mon point de vue, pour commencer il faut clairement se baser sur du C qui permet en paralèlle d'expliquer le fonctionnement de la machine et je pense qu'une bonne connaissance bas niveau du matériel est nécessaire pour former un bon développeur.

        Après une bonne compréhension du C, apprendre des langages de plus haut niveau ne peut qu'être plus simple (et évite toutes les aberrations citées).

        • [^] # Re: Chacun son style

          Posté par  (site web personnel) . Évalué à 8.

          De mon point de vue, pour commencer il faut clairement se baser sur du C qui permet en paralèlle d'expliquer le fonctionnement de la machine

          Pourquoi prendre un langage d'aussi haut niveau pour "expliquer le fonctionnement de la machine"? Non, non, avec un tel argument, le seul langage acceptable c'est l'assembleur.
          Argument ridicule.

          • [^] # Re: Chacun son style

            Posté par  . Évalué à 2.

            Non, il n'a pas tort, notamment pour ce qui est de la notion de pointeur et de la gestion de la mémoire. Comprendre comment ça fonctionne aux niveaux les plus bas permet de mieux comprendre comment fonctionnent les langages haut niveau. La notion de garbage collector reste extrêmement floue si tu n'as pas un minimum d'idée de ce qui se passe derrière.

            Ceci dit, pour cela, nul besoin de former des experts en C, juste de donner aux étudiants les bases nécessaires.

        • [^] # Re: Chacun son style

          Posté par  . Évalué à 1.

          Je suis désolé mais c'est, selon moi, un argument qui ne tient pas !
          On peut parfaitement commencer à apprendre à programmer avec Java, tout en étant capable de comprendre ce qui se passe "en-dessous".
          Après, si tu tombes sur des tutos mal branlés et/ou des profs incompétents, c'est sûr que tu pisseras du code de merde ! Mais ça n'est pas forcément lié...

          • [^] # Re: Chacun son style

            Posté par  . Évalué à -1.

            Java nécessite de comprendre des concepts assez évolués et abstraits dûs au modèle objet. À côté de ça tu as le C qui est un langage simple : peu de mots clef à apprendre, peu de notions à avoir pour commencer à programmer (tu mets dans un premier temps les pointeurs sous le tapis). Quand tu auras des étudiants à qui il faudra apprendre le principe d’une variable, les types, leur nature et leurs limitations, l’enchaînement des instructions, le contrôle du flux d’exécution (condition et boucles), la notion de fonctions, arguments et valeur de retour (à propos en Java, un int est passé par valeur ou référence? et un objet quelconque?), je t’assure qu’il vaut mieux commencer par le C…

            Parce que Python, qui est aussi encensé pour l’apprentissage donne (attention aux yeux, code crade):

            > def f(a):
..>     a = 3
..> 
> class myint(object):
..>     x = 0
..>     def get(self):
..>         return self.x
..>     def set(self, v):
..>         self.x = v
..> 
> def g(a):
..>     a.set(3)
..> 
> a = 0
> f(a)
> a
: 0
> a = myint()
> g(a)
> a.get()
: 3

            Bon courage pour expliquer ça à des débutants en programmation…

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 6.

              Bon courage surtout pour expliquer ça :

               def get(self):
     return self.x
 def set(self, v):
     self.x = v

              (pour ceux qui n'auraient pas compris, c'est de self dont je parle. Super logique dans un langage objet...)

              • [^] # Re: Chacun son style

                Posté par  . Évalué à 1.

                En fait, c'est parce qu'en python les classes comme les fonctions sont des objects de premier ordre. Voici un exemple qui peut justifier l'utilisation de self (d'ailleurs, self n'est qu'une convention, tu peux utiliser n'importe quel autre nom pour ton premier argument):

                class Plop(object):
    def __init__(self):
            print self

def print_me(x):
    print x

Plop.print_me = print_me

a = Plop()

a.print_me()

                Ce genre de fonctionalité permet de faire des choses complètement non maintenables, ou alors sert de base pour faire des trucs plutôt chouettes

                • [^] # Re: Chacun son style

                  Posté par  (site web personnel) . Évalué à 1.

                  Le truc c'est que si c'était malin on en aurait pas besoin.
                  En javascript par exemple (loin d'être un modèle dans tous les cas) on aurait pu écrire :

                  var Plop = function() {
  alert(this);
};
var print_me = function() {
  alert(this);
};

Plop.prototype.print_me = print_me;

var a = new Plop();
a.print_me();

                  (bon cet exemple est pas parfait car le alert ne comportera que des [object Object] mais il suffit de le debugger ou de changer les alert pour se rendre compte que ça fonctionne.)

                  On a donc exactement le comportement attendu par l'équivalent python mais sans la glue self qui finalement se révèle inutile (ou alors je n'ai toujours pas vu un cas où c'était nécessaire).

                  • [^] # Re: Chacun son style

                    Posté par  . Évalué à 1.

                    Je me suis mal exprimé. L'argument "self" n'est évidemment pas indispensable. Si je me rappelle bien, il s'agit d'un de ces fameux choix contreversés de Guido Van Rossum (comme par exemple le fait que l'indentation soit significative).

                    L'exemple que je prend sert à surtout voir le genre de considérations "esthétiques" (homogénéité?) qui ont probablement été prises en compte pour imposer une telle construction.

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à 1.

                      Je comprend. Mais c'est justement le côté faussement indispensable que je critique et, désolé pour python, c'est typiquement le genre de détail me que laisse une très mauvaise impression sur ce langage.

                      Côté homogénéité, this aurait été beaucoup plus clair et surtout juste légèrement implanté dans pas mal de langages.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 1.

                        Comme je le disais, si cela fait partie des choix controversés du BDFL, ça n'est pas pour rien! Bref, c'est avant tout une question de goût et de sensibilité (donc un sujet très polarisant).

                        Je conseillerais à ceux qui veulent découvrir python de ne pas s'arrêter à cela: l'emploi de "self" est peut être lourd, l'indentation est certainement pénible (mais on s'y fait très rapidement) etc etc...
                        Pourtant, il y a plein de subtilités et de choix dans le langage qui permettent d'écrire des scritps sympa en très peu de lignes (les méthodes XXX, les list comprehensions, les generator expressions etc... cf le tuto officiel), sans parler de sa bibliothèque ("batteries included") répondant à la plupart des besoins courants.

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 2.

                        désolé pour python, c'est typiquement le genre de détail me que laisse une très mauvaise impression sur ce langage.

                        Ce qui amusant c'est que tu prends pour référence un langage (Javascript) avec une quantité de "détails" rédhibitoires absolument monstrueuse. Rien que sur le sujet en discussion, regarde la signature de func.apply(...) où tu dois passer un "this" à null si la fonction n'est pas une méthode. Joli hein ?

                        Donc pour revenir au sujet, je ne connais aucun développeur Python confirmé qui ait un problème avec le "self" explicite, et qui voudrait le retirer. Je pense au contraire que cela rend intégralement explicite le contexte d'exécution, ce qui est une qualité.

                        Pour le reste et "l'impression sur le langage", il faudrait que tu le pratiques un peu histoire de dépasser les jugements stéréotypés (j'imagine que le "self" explicite arrive en deuxième après l'indentation dans la liste des clichés anti-Python).

                        • [^] # Re: Chacun son style

                          Posté par  (site web personnel) . Évalué à 2.

                          tiens, je croyais justement ajouté un truc genre loin d'être un modèle dans tous les cas pour éviter ce type de remarque.
                          Ha ben tiens, en fait oui je l'ai bien ajouté...

                          par contre, désolé mais j'ai pas tout capté sur ton paragraphe. La différence entre une méthode et une fonction c'est pas le fait, ou non, de retourner une valeur ? Si c'est bien ça, t'aurais pas confondu méthode et membre ?
                          Ensuite, sur func.apply : apply (ou call d'ailleurs) est fait pour exécuter une fonction dans un contexte. Genre je veux exécuter la fonction plop sur l'objet bla avec comme paramètre blurp : plop.apply(bla, blurp)
                          Dans quel cas tu souhaiterais passer null à la place de bla parce que là comme ça je ne vois pas immédiatement ?

                          Je pense au contraire que cela rend intégralement explicite le contexte d'exécution, ce qui est une qualité.

                          Et moi je pense que l'explicite à tout prix est inutilement verbeux, lourd, inefficace et que c'est loin d'être une qualité.

                          Mais au contraire, j'ai toujours aimé le principe de l'indentation forcée, ne serait-ce que parce que beaucoup de développeurs sont incapables d'indenter correctement un fichier (ni d'appeler une méthode qui le fait...) et que ça leur ferait les pieds. Mais reste que je trouve ça pas mal.
                          Le self, c'est pas lui qui me gène spécifiquement mais c'est plus le design qui est derrière, le fait de le montrer explicitement qui m'emmerde. Pour moi on ne devrait pas le voir et donc je trouve que c'est une erreur du langage.

                        • [^] # Re: Chacun son style

                          Posté par  (site web personnel, Mastodon) . Évalué à 2.

                          Rien que sur le sujet en discussion, regarde la signature de func.apply(...) où tu dois passer un "this" à null si la fonction n'est pas une méthode. Joli hein ?

                          Non, tu passes l'objet cible null si la fonction appelée ne nécessite pas un objet. En javascript, il n'y a pas de notion de fonction membre.

                          Donc pour revenir au sujet, je ne connais aucun développeur Python confirmé qui ait un problème avec le "self" explicite, et qui voudrait le retirer. Je pense au contraire que cela rend intégralement explicite le contexte d'exécution, ce qui est une qualité.

                          Moi ça m'emmerde de le taper à chaque fois. Surtout qu'on peut lui donner le nom qu'on veut, ce qui laisse libre court à l'imagination des marauds. Je préfère largement le mode C++ : on utilise les variables dans le scope, et les variable d'instance y sont jetées. Histoire d'éviter de répéter en permanence qu'on se modifie. L'indentation significative ne me pose pas de problème, tant que tout le monde utilise des tabulations équivalent à 4 blancs. Je sais, ce n'est pas pythonique, set expandtab.

          • [^] # Re: Chacun son style

            Posté par  (site web personnel) . Évalué à 3.

            Le problème de Java c'est que ça masque pas mal de concepts bas niveau, comme les adresses (pourtant utilisées dans les références, avec plein de limitations), la décomposition de la mémoire en octets (pas d'union, pas de cast de pointeurs, pas d'équivalent à void*), etc. Et donc l'étudiant qui programme en Java n'a limite pas besoin de savoir que ses variables sont stockées en binaire en mémoire, ce qui donne des situations où ils ne comprennent pas ce qu'est un masquage de bits ou un décalage, alors que ça sert tout le temps.

            Quand le langage n'est pas fait pour manipuler certains concepts, le programmeur ne les utilise tout simplement pas.

            De plus tu ne réponds pas au problème posé au départ: certains automatismes de programmation ne sont tout simplement pas assimilés par l'étudiant parce que le langage ajoute de la vérification et le garbage collector fait le ménage à la place du programmeur.
            Donc pas besoin de prévoir de libérer ce que tu alloues, pas de programmation défensive sur les indices de tableaux, pas d'initialisation de variables, ... L'étudiant sera complètement perdu quand il passera à un langage de plus bas niveau et qu'il devra se mettre à programmer proprement.

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 6.

              Le problème de Java c'est que ça masque pas mal de concepts bas niveau, comme les adresses (pourtant utilisées dans les références, avec plein de limitations), la décomposition de la mémoire en octets (pas d'union, pas de cast de pointeurs, pas d'équivalent à void*), etc. Et donc l'étudiant qui programme en Java n'a limite pas besoin de savoir que ses variables sont stockées en binaire en mémoire, ce qui donne des situations où ils ne comprennent pas ce qu'est un masquage de bits ou un décalage, alors que ça sert tout le temps.

              Ces trucs là, c'est utile à savoir oui... en fait, les cours de système devraient être obligatoires pour tous les étudiants... de même que les étudiants devraient savoir toutes les étapes pour afficher une page de http://linuxfr.org/ ...

              Perso, je programme en Java et en C et je ne me sers pratiquement jamais de ces trucs en C, si ce n'est pour émuler des fonctionnalités de langages objet (genre, les unions pour de l'héritage, les void* ... euh non merci...

              Les masquages/décalages de bits, ça m'arrive en Java et en C, mais ce n'est quand même pas ce qu'il y a de plus courant.

              Le fait est que bien penser un design, ça demande du temps de cerveau disponible... et perso, je préfère l'utiliser pour faire un belle architecture ou diminuer la complexité de mon algo que me prendre la tête à gérer une fuite de mémoire.

              De mon expérience, on passe au moins 25% du temps à corriger des bugs de mémoire en C, je dirai 1% dans le cas d'applications Java (oui, on peut aussi perdre de la mémoire en Java)... ce temps est du temps perdu.

              Je ne parle même pas de l'utilisation faible d'algorithmes efficaces dans la plupart des projets C par le manque de ré-utilisation de code, du coup, Hop, listes chaînes pour tout le monde (ou le contraire, des tableaux pour tout le monde)... des limitations de merde dans tous les sens (BUFFER_MAX_SZ : hop !)... bref, au final, mon code est le plus souvent bcp plus rapide en Java qu'en C, ce n'est pas une question de compétence, mais une question de temps passé réellement sur les algos.

              Alors oui, mettez deux génies dans une salle avec un temps infini, et oui, sans doute, au final le dev C aura un code plus rapide... à vrai dire, je m'en fout.

            • [^] # Re: Chacun son style

              Posté par  (site web personnel) . Évalué à 1.

              peut-être intéressant à savoir mais dans un marché français majoritairement limité au domaine de l'assurance et bancaire, c'est pas vraiment utile

              www.solutions-norenda.com

              • [^] # Re: Chacun son style

                Posté par  (site web personnel, Mastodon) . Évalué à 1.

                J'espère que tu ne te bases pas sur les annonces sur les sites d'emploi ? Parce qu'il est normal que les banques cherchent en continu : ils ne trouvent plus de développeurs Cobol ou Fortran :D

                • [^] # Re: Chacun son style

                  Posté par  (site web personnel) . Évalué à 2.

                  tu veux te baser sur quoi?

                  le nombre de pain vendu par la boulangerie du coin?

                  il est comme normal que les entreprises cherchent en continue, il y a du roulement partout et le marché de la ssii est très fort en france

                  www.solutions-norenda.com

                  • [^] # Re: Chacun son style

                    Posté par  (site web personnel, Mastodon) . Évalué à 2.

                    Tu confonds annonce et recherche réelle, c'est bien ce qui biaise le résultat. Et non, ce n'est pas normal qu'il y ait du roulement. Il y a quelque chose qui ne va pas dans le management s'il y a autant de turn over.

                    • [^] # Re: Chacun son style

                      Posté par  (site web personnel) . Évalué à 2.

                      a part la france, tu sais les gens perdent pas leur temps à mettre des annonces pour ne pas embaucher....

                      ta jamais pensé qu'une partie du roulement pouvait être du que le travail ne plaisait pas à l'employé?

                      www.solutions-norenda.com

                      • [^] # Re: Chacun son style

                        Posté par  . Évalué à 2.

                        c'est clair que faire du java toute la journée, ça fait pas rêver ... (troll inside :)

                    • [^] # Re: Chacun son style

                      Posté par  . Évalué à 1.

                      Pourtant il a raison. J'ai plusieurs fois regarde le marche du travail informatique en Suisse pour rentrer au pays et c'est triste a mourir.

                      J'ai un CV en beton arme, mais c'est con je trouves rien de correct:
                      - Soit c'est dans une banque/assurance a faire de la merde
                      - Soit c'est une petite/moyenne boite info qui va me diviser mon salaire par 2 avec une garantie de survie de la boite pas forcement tres elevee
                      - Soit c'est une SSII ou il faut mettre un costard et lecher le cul des clients et dire oui a toutes les conneries qu'ils demandent meme lorsque cela n'a aucun sens

                      C'est triste, mais les VRAIS jobs de developpeurs sur un produit un peu sur le long terme avec des conditions decentes c'est rare en Europe. Il y a Google(a Zurich) et quelque autres mais c'est tout.

                      • [^] # Re: Chacun son style

                        Posté par  (site web personnel) . Évalué à 4.

                        Si tu divises par 2 ton salaire en suisse combien tu dois gagner aux US ! :)

                        "La première sécurité est la liberté"

                        • [^] # Re: Chacun son style

                          Posté par  . Évalué à -4.

                          Meme pas malheureusement, a moins d'etre chef de projet ou bosser dans une banques les salaires de dev en Suisse volent pas super haut. C'est pas la pauvrete non plus, mais c'est sans rapport avec les USA.

        • [^] # Re: Chacun son style

          Posté par  . Évalué à 1.

          Mouais, enfin, avec le C, on a quand même très vite fait de sortir du cadre de l'algo pure avec l'arithmétique des pointeurs ou la galère des zones de mémoire à allouer et libérer à la main... Au final les langages comme java, ruby, etc. permettent de se concentrer sur ce qui est structure de code, maintenance et simplicité. Il sera toujours temps de revenir à la gestion fine de la mémoire dans le cas de l'embarqué ou de la très haute performance.

    • [^] # Re: Chacun son style

      Posté par  . Évalué à 1.

      Côté C#/.NET, que je connais peu, je n'entend rien arriver.
      .NET 4 : Task Parrallel Library, Parrallel LINQ
      http://sebastiencourtois.wordpress.com/2010/04/26/nouveauts-net-4-task-parallel-library-gestion-des-architectures-multicoresmultiprocesseurs/
      F# depuis .NET 2.0 : http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/

      De plus le CLR/DLR (le DLR date de .NET v4) est compatible avec des dizaines de langages à vue de nez.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Chacun son style

        Posté par  . Évalué à 0.

        Oups la citation (première fois, tout ça)

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Chacun son style

      Posté par  (site web personnel) . Évalué à 2.

      Côté C#/.NET, que je connais peu, je n'entend rien arriver.

      Côté .NET il y a des trucs arrivés pour faciliter la programmation concurrentiel : la TPL (Task Parallel Library), le couple async/await

      http://msdn.microsoft.com/en-us/magazine/cc163340.aspx
      http://msdn.microsoft.com/fr-fr/vstudio/async

    • [^] # Re: Chacun son style

      Posté par  . Évalué à 7.

      L'avenir du langage va se décider avec le Cloud

      Le temps est incertains par ici, tu sais si je dois prendre un parapluie pour sortir ce soir ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Chacun son style

        Posté par  . Évalué à 1.

        Et paf, au même moment où je lis ce commentaire, il se mets à pleuvoir une bonne nuée d'orage dans la vraie vie… C'est un signe !!!

        • [^] # Re: Chacun son style

          Posté par  . Évalué à 2.

          En plus on est le 8 la veille du 9 le chiffre sacré …

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Chacun son style

        Posté par  (site web personnel) . Évalué à 1.

        le truc qui permet au américain même si leur serveur est en europe d'accéder au donnée des clients sans les aviser? tout ça selon le patriot act...

        www.solutions-norenda.com

    • [^] # Re: Chacun son style

      Posté par  . Évalué à 1.

      Le parallélisme en C# est assez redoutable. Je conseille le visionnage de cette vidéo http://ecn.channel9.msdn.com/o9/ch9/5/9/8/8/9/4/ParallelProgrammingEndToEnd_2MB_ch9.wmv pour se rendre compte des possibilités.

      Il y a fourni avec des lockers plus ou moins spécifiques et pas mal foutus, tout comme les collections de données thread-safe (mais pas la observable collection, ceci dit l'implémenter n'est pas une sinécure).

      Personnellement j'en ai été très satisfait.

    • [^] # Re: Chacun son style

      Posté par  . Évalué à 3.

      Ce qui est intéressant, c'est que java revient à ses premiers amours (développement pour l'embarqué, avec Android que l'on peut classer dans les java-like) alors qu'il perd petit à petit du terrain sur le web (plus une seul applet java n'est communément utilisé), les grandes entreprises en sortent petit à petit (pour le remplacer quand c'est possible par l'équivalent en flash/html 5 quand c'est possible).

      Pour moi, le java a son intéret quand on veut privilégier la productivité par rapport au reste, le meme code en C++ est beaucoup plus long à développer. Par contre, pas un seul OS n'est écrit en java, quasiment tout ce qui est bas niveau est écrit en C/C++.

      Aujourd'hui je code essentiellement en C++ parce que le java m'énerve avec ces conso mémoire délirante (jenkins, eclipse affichent régulièrement plusieurs giga de ram utilisé), et visiblement les développeurs n'ont pas conscience ou la possibilité de limiter cette voracité.

      Déjà, java est déficient car il ne me propose pas d'opérateur "delete" quand je sais que ma variable est a jeté ici et maintenant et pas dans un futur plus ou moins proche, selon le bon vouloir du GC. Bref, c'est un vieux troll, mais il y a tellement de bonne choses en java (design pattern, interface, absence de pointer), que ce que je fais, c'est que je tente au maximum de les appliquer en C++.

      • [^] # Re: Chacun son style

        Posté par  . Évalué à 2.

        Déjà, java est déficient car il ne me propose pas d'opérateur "delete" quand je sais que ma variable est a jeté ici et maintenant et pas dans un futur plus ou moins proche, selon le bon vouloir du GC.

        Le GC ne jète pas les variables, il jète les objets.

      • [^] # Re: Chacun son style

        Posté par  . Évalué à 2.

        il y a tellement de bonne choses en java (design pattern, interface, absence de pointer), que ce que je fais, c'est que je tente au maximum de les appliquer en C++.

        Depuis quand tout cela est lié à Java ? C'est lié à des concepts objets. Je vois pas en quoi dans Java tu as quelque chose de plus pour créer des factory (par exemple) qu'en C++. Le principe des interfaces est très proches des classes abstraite du C++ (oui on peut par exemple embarquer du code dans les classes abstraites, ça peut être pratique, même si c'est peu commun).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Chacun son style

        Posté par  (site web personnel) . Évalué à 1.

        java (design pattern, interface, absence de pointer)

        Hahahaha très drole ! J'espère que ton post est ironique, sinon j'ai très peur .... En C++ effectivement on peut se passer de pointeurs, en Java par contre, tout est pointeur ... En ce qui concerne les interfaces, le concept d'interfaces en java n'est là que pour palier à l'absence du multihéritage que le C++ a, qui évite de se retrouver avec une difference entre MouseListener et MouseAdapter (par exemple) qui ne devraient n'être qu'une et unique classe !

        • [^] # Re: Chacun son style

          Posté par  (site web personnel) . Évalué à 1.

          En faîtes, en Java, tout est référence (ou presque). Il n'y a pas de pointeur.

          • [^] # Re: Chacun son style

            Posté par  . Évalué à 1.

            Cela pose les mêmes problèmes quand même.

            Si tu à un vieux pointeur que tu ne met pas à jour qui pointe vers un objet qui n'est plus utilisé (détruit quoi), puis que tu utilise ce pointeur, en C++ ton programme risque de planter, ça sera peut être visible avec valgrind (surtout avec ptrcheck), ou ça ne fera rien du tout.

            Avec Java tu est certain que ta vielle référence pointe sur un objet valide (mais pas le bon), donc tu ne verra rien, sauf peut être une fuite mémoire, mais ça les devs java sont habitués ...

            et ne parlons pas des NullPointerException, qui ont le même effet dans les deux langages.

            • [^] # Re: Chacun son style

              Posté par  . Évalué à 1.

              Mais comme pour les tableaux (entre le bête array accedé par [], le std::vector::[] ou encore std::vector::at), en C++, on a le choix. On peut tout à fait se passer des pointeurs hérités du C et n'utiliser que des smart pointers et avoir la garantie que si un objet est encore en mémoire, alors tu as encore quelque chose qui pointe dessus.

              et ne parlons pas des NullPointerException, qui ont le même effet dans les deux langages.

              Par contre là, on a pas le choix en C++ : il n'y a pas d'exception quand on tente de manipuler un pointeur (smart ou pas) nul. Pareil avec une division par zéro.

      • [^] # Re: Chacun son style

        Posté par  . Évalué à 7.

        java revient à ses premierspremières amours

        amour, orgue et délice sont masculins au singulier et féminins au pluriel.

    • [^] # Re: Chacun son style

      Posté par  (site web personnel) . Évalué à -1.

      bof pour le cloud, sachant que les données des cloud des entreprises américaines même si les machines sont en sol européenne peuvent être prise sans en aviser le client..... ça risque dans refroidir par mal

      oracle a déjà mentionné que jee 7 sera orienté "cloud"

      www.solutions-norenda.com

  • # Les développeurs Java

    Posté par  . Évalué à 10.

    J'aime beaucoup les développeurs Java (j'en suis, même si j'aime le c++), parce qu'ils ont tendance à détester le C++ (peut être à cause de mauvais souvenir ?).

    Quand je lis ça :
    > En outre, Java apporte une grande sécurité de fonctionnement : son architecture à base de Sandbox permet d'isoler les processus, contrairement à C++ où un débordement de pile est courant (le fait que Microsoft Windows soit programmé en C++ est la principale cause de sa porosité aux virus informatiques).

    ou ça :
    > doute quant à la pertinence de l'utilisation de C++ comme langage dominant, intérêt pour un langage qui reprend les avantages de C++ en éliminant ses inconvénients (cohérence, sécurité) ;

    Je trouve que tu as choisi le bon jour pour cette dépêche.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Les développeurs Java

      Posté par  (site web personnel) . Évalué à 3.

      Quand tu fais du multiplateforme Win/Macos/Linux, C++ c'est l'horreur, ne serait-ce que pour maintenir une plateforme de build correcte. Avec Java ou un langage interprété, tu économises des heures et des heures de boulot.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Les développeurs Java

        Posté par  . Évalué à 9.

        Quand tu fais du multiplateforme Win/Macos/Linux, C++ c'est l'horreur,

        Qt ?

        • [^] # Re: Les développeurs Java

          Posté par  . Évalué à -8.

          L'interface graphique n'est que la partie émergée de l'iceberg... En Java le "coeur" de l'appli est insensible à l'OS. En C++, c'est beaucoup plus compliqué à moins de n'utilise que la librairie standard (et encore...). En plus quand t'es en entreprise, et que t'as pas que du x86, c'est impossible d'avoir un truc portable et maintenable en C++.

        • [^] # Re: Les développeurs Java

          Posté par  (site web personnel) . Évalué à 4.

          Tu as trouvé une api, c'est bien, mais c'est pas ce que j'appelle une plateforme de build.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Les développeurs Java

        Posté par  . Évalué à 9.

        C'est amusant de répondre à coté, j'peux le faire moi aussi.

        Dans les avantages du C++, il y a entre autre la compatibilité avec le C, la performance et la méta-programmation. 3 avantages ignorés par Java.

        C'est aussi la première fois que j'entends dire (ou que je lis écrire) que Windows a (eu ?) des problèmes de sécurité à cause du C/C++. Alors qu'il existe d'autres systèmes très sûr en C et que la majorité s'accorde sur 2 point :

        • c'est la plateforme grand publique donc c'est la plus attaquée
        • il y a(vait ?) des problèmes de conceptions (notamment pas de séparation assez distinct et/ou utilisable) entre les droits admins et les droits utilisateurs

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Les développeurs Java

          Posté par  (site web personnel) . Évalué à 2.

          la méta-programmation. 3 avantages ignorés par Java.
          Euh, la méta-programmation ignoré de Java par rapport à C++, c'est une blague j'espère ?

          C'est aussi la première fois que j'entends dire (ou que je lis écrire) que Windows a (eu ?) des problèmes de sécurité à cause du C/C++. Alors qu'il existe d'autres systèmes très sûr en C

          ... qui ont exactement le même problème.

          Analyse les failles, que ce soit sous Windows ou sur le Kernel, tu vas voir le nombre de fois qu'il y a un problème de déréférencement de pointeur ou de débordement de tampon. Dire que c'est uniquement dû à la taille de la cible ou à un problème de conception est vraiment une façon étrange de chercher à innocenter le C++ à tous les coup.

          Microsoft a bien compris le problème en bossant sur Singularity, un OS basé non plus sur du C++ mais sur une VM issue de .NET.

          • [^] # Re: Les développeurs Java

            Posté par  . Évalué à 4.

            Analyse les failles, que ce soit sous Windows ou sur le Kernel, tu vas voir le nombre de fois qu'il y a un problème de déréférencement de pointeur ou de débordement de tampon. Dire que c'est uniquement dû à la taille de la cible ou à un problème de conception est vraiment une façon étrange de chercher à innocenter le C++ à tous les coup.

            Ça t'amuse de lire la moitié des commentaires avant de répondre ? Le fait de travailler en permanence avec un compte root, c'est le genre de faille monstrueuse.

            Pour ce qui est des sécurités de Java. Une exception ça doit être gérée si ça ne l'ai pas le problème est le même qu'un segfault et si le développeur a pris soin de gérer convenablement les exceptions il en aurais fais de même en C pour vérifier ce qu'il déréférence.

            Microsoft a bien compris le problème en bossant sur Singularity, un OS basé non plus sur du C++ mais sur une VM issue de .NET.

            Ce genre de projet (il en existe aussi pour Java), ne sont pas viable tant que la VM n'est pas gravé dans le silicium.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Les développeurs Java

              Posté par  (site web personnel) . Évalué à 5.

              Dans le cas d'un débordement d'indices de tableaux, une ArrayIndexOutOfBoundException (ou n'importe quelle autre exception) ne permet pas d'écriture arbitraire en mémoire alors que C/C++ ne garantit pas d'avoir une segfault. De même, un déréferencement de pointeur non-initialisé ne va pas forcément se traduire par une segfault (si tu n'as pas de chance et qu'en fait ton pointeur pointe sur quelque chose d'atteignable).

              Après, bien sûr que si on code de manière potable en C++ en s'interdisant les trucs vraiment dégeu, en évitant l'arithmétique de pointeurs et en utilisant une macro CHECK pour spécifier des contrats sur les méthodes et en lançant régulièrement valgrind et de l'analyse statique de code, on arrive à avoir quelque chose de sécurisé.

              C'est juste que Java est plus sécurisé par défaut que C++. De toute manière, même en ASM ou en brainfuck tu peux faire un programme sans failles, la question intéressante c'est que certains langages ont choisit d'imposer plus de sécurité par défaut. Ca a évidemment un coût et j'imagine que c'est la raison pour laquelle développer un kernel en Java n'a pas tellement de sens.

              • [^] # Re: Les développeurs Java

                Posté par  . Évalué à 2.

                De même, un déréferencement de pointeur non-initialisé ne va pas forcément se traduire par une segfault (si tu n'as pas de chance et qu'en fait ton pointeur pointe sur quelque chose d'atteignable).

                De ce que j'ai pu voir (je sais que ça ne fait pas partie de la norme) certains compilateurs initialisent eux même à 0.

                Je suis d'accord avec toi que Java est plus sécurisé par défaut, mais il ne faut pas croire qu'il est sécurisé. Quelqu'un qui n'y prend pas garde va bourrer de faille son code quelque soit le langage.

                Le problème a passer son temps à dire que Java est portable et sécurisé, c'est que c'est faux, il l'est plus que le C et le C++ par exemple, mais avoir un logiciel portable et sécurisé (indépendamment l'un de l'autre), ça passe d'abord par le ou les programmeurs.

                C'est pour ça que mettre en cause le langage dans d'éventuelles failles d'un code est farfelu (artisan, outil tout ça …).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2. Dernière modification le 09 juillet 2011 à 00:45.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Les développeurs Java

                    Posté par  (site web personnel) . Évalué à 1.

                    Allez savoir pourquoi sous Windows et Cygwin, ça s'initialisait tout le temps soit à NULL soit à zéro.

                    Parce que c'est plus rapide. Et c'est bien.
                    en C++, tu a le choix (soit tu utilises des objets à la Java et ce sera initialisé par le constructeur, soit tu définit la variable et tu la définit que si besoin, rapidité tout ça)

            • [^] # Re: Les développeurs Java

              Posté par  . Évalué à 0.

              Ce genre de projet (il en existe aussi pour Java), ne sont pas viable tant que la VM n'est pas gravé dans le silicium.

              On va dire que tu sous-estime serieusement ce qu'il est possible de faire avec une architecture appropriee...

              • [^] # Re: Les développeurs Java

                Posté par  . Évalué à 2.

                Ce genre de projet (il en existe aussi pour Java), ne sont pas viable tant que la VM n'est pas gravé dans le silicium.

                On va dire que tu sous-estime serieusement ce qu'il est possible de faire avec une architecture appropriee...

                Il y a un moment où il te faut une machine virtuelle. Soit elle est logicielle en langage machine (même si elle subit une ou plusieurs étapes de compilation), soit tu grave la machine virtuelle dans la CPU et le byte code peut s'exécuter directement dessus.

                Le premier cas (sans prendre en compte les éventuels problèmes de performance) c'est d'une lourdeur d'un point de vu architectural très dommageable : on empile ajoute encore une couche dans quelque chose qui en compte déjà beaucoup.

                Ce que je dis là n'est absolument pas défavorable à ce type d'OS. Ça existe déjà pour Java rien empêche que ça le devienne pour C# (du moins je suppose) et je suis persuadé que ce n'est pas un si gros obstacle que ça pour Microsoft (j'ai un prof qui tente de le faire pour Java et il a déjà beaucoup plus de mal).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Les développeurs Java

                  Posté par  . Évalué à 2.

                  Il y a un moment où il te faut une machine virtuelle. Soit elle est logicielle en langage machine (même si elle subit une ou plusieurs étapes de compilation), soit tu grave la machine virtuelle dans la CPU et le byte code peut s'exécuter directement dessus.

                  En fait... non, t'en as pas forcement besoin. cf. http://research.microsoft.com/en-us/um/people/larus/talks/cav08_invited_talk.pdf (cherches le mot Bartok)

                  Le code est verifie, puis compile en code natif.

                  • [^] # Re: Les développeurs Java

                    Posté par  . Évalué à 0.

                    C'est quoi la différence entre

                    elle [la VM] est logicielle en langage machine (même si elle subit une ou plusieurs étapes de compilation)

                    et

                    Le code est vérifie, puis compile en code natif.

                    ?

                    Plus tu ajoute d'étape (et de couches) moins la solution me semble pertinente, du point de vu performance comme de la maintenabilité.

                    Grosso modo la VM .Net émule une CPU pourquoi garder cette émulation si elle peut être évitée ? Je présume que .Net est comme JVM est qu'elle est restée compatible (même modèle d'exécution) depuis la première version jusqu'à maintenant (d'où le fais que Java reste en version 1.x). La bibliothèque standard et le ramasse miette ne font pas partie de la VM.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Les développeurs Java

                      Posté par  . Évalué à 1.

                      T'as pas compris, il n'y a pas de VM, le code est compile en natif et tourne directement sur le CPU.

                    • [^] # Re: Les développeurs Java

                      Posté par  (site web personnel) . Évalué à 4.

                      Plus tu ajoute d'étape (et de couches) moins la solution me semble pertinente, du point de vu performance comme de la maintenabilité.

                      Ce qui coûte en performance, ce n'est pas le fait d'ajouter de "couche", mais d'ajouter des services : GC, contrôle d'accès aux ressources, etc.

                      Grosso modo la VM .Net émule une CPU pourquoi garder cette émulation si elle peut être évitée ?

                      Il n'y a aucune forme d'émulation. la VM .NET est prévue dès le départ pour exposer un bytecode destiné à être compilé en code natif avant exécution, voir même avant déploiement.

                      Je présume que .Net est comme JVM est qu'elle est restée compatible (même modèle d'exécution) depuis la première version jusqu'à

                      Non elle a évoluée. Le CLR en est à la version 4.0.

                      La bibliothèque standard et le ramasse miette ne font pas partie de la VM.

                      Un sous-ensemble de la bibliothèque fait implicitement parti de la VM, et le GC est un service de la VM et en fait donc pleinement parti.

                      Ce que tu ne comprends pas, c'est ce qu'apporte une VM :
                      * une couche d'abstraction complète => portabilité. Pour un OS, c'est un gros atout.
                      * un modèle mémoire indépendant du hardware => possibilité d'ajouter des mécanismes de protection purement software, portable au passage, qui ne nécessite pas de faire appel aux ring hardware pour isoler les processus : paradoxalement il en résulte des performances bien meilleures qu'avec un OS classique basée suér les ring hardwares.
                      * un bytecode vérifiable avant exécution : pour un OS, pouvoir vérifier un programme avant de l'exécuter est un énorme atout niveau fiabilité et sécurité.

                      Il en résulte un OS beaucoup plus indépendant de la machine, avec un code beaucoup plus portable, plus simple, plus fiable et plus facile à maintenir.

                  • [^] # Re: Les développeurs Java

                    Posté par  . Évalué à -1.

                    Encore une fois je ne dis pas que c'est impossible, je dis que je doute de la pertinence de cette voie (celle qui consiste à utiliser la JVM ou .Net sans retirer la couche entre la VM et le matériel).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Les développeurs Java

              Posté par  (site web personnel) . Évalué à 2.

              Ça t'amuse de lire la moitié des commentaires avant de répondre ? Le fait de travailler en permanence avec un compte root, c'est le genre de faille monstrueuse.

              Y dit qu'il voit pas le rapport. Parlons des OS modernes si tu veux bien.

              Tu affirmes que c'est la première fois que tu entends que les problèmes de sécu sont liées au language. Bah moi je te renvoi aux nombreux rapports de failles, sous Linux ou Windows, et tu verras que beaucoup d'entre elle sont directement liées à l'utilisation d'un langage bas niveau.

              Et pourtant ce ne sont pas censé être des codeurs du dimanche qui codent un OS, que ce soit chez Microsoft ou les développeurs du Kernel Linux. Comme quoi il y a bien un problème fondamental avec ce type de langage : t'as beau être compétent, il est impossible de faire un programme sans bug. D'où l'idée d'avoir d'une VM qui ajoute une couche d'abstraction aux conneries du développeur pour s'assurer que 90% des bugs ne se transforment pas en failles potentielles.

              Java. Une exception ça doit être gérée si ça ne l'ai pas le problème est le même qu'un segfault et si le développeur a pris soin de gérer convenablement les exceptions il en aurais fais de même en C pour vérifier ce qu'il déréférence.

              T'as jamais codé c'est pas possible, comme si un déréférencement se traduisait systématiquement par un segfault...

              Et puis on s'en cogne total de la gestion de l'exception ou du segfault : par définition, elles ne sont censé apparaître que dans des cas exceptionnels, cad non-prévus par le développeur, et donc non gérées. On parle de sécurité, pas de s'assurer qu'un programme est correct : l'objectif est donc de s'assurer qu'en cas de bug, ce qui arrive tôt ou tard, le système s'assure que ca ne se transforme pas en faille de sécurité. la VM s'en assure pour certains types de bug (accès mémoire, accès ressources systèmes), là ou le C/C++ ouvre la porte grande ouverte à toutes les failles possibles.

              Ce genre de projet (il en existe aussi pour Java), ne sont pas viable tant que la VM n'est pas gravé dans le silicium.

              Affirmation gratuite. Tu peux argumenter ?

              • [^] # Re: Les développeurs Java

                Posté par  (site web personnel) . Évalué à 0.

                Je trouve ton commentaire très amusant. À ton avis, dans quel langage est écrite la JVM (les parties qui ne sont pas en Java) ? Indice : en C/C++.

                Et, pour être honnête, je fais plus confiance aux développeurs du kernel pour écrire du "bon" code C/C++ qu'aux types d'Oracle chargés de maintenir la JVM. Car oui, la JVM comporte aussi des bugs. Sauf que, quand mon programme Java plante à cause d'elle, je suis bien plus embêté que quand c'est causé par mon programme C/C++ (lui, je peux le déboguer et le modifier/recompiler sans être masochiste).

                D'ailleurs, un des avantages de Java que je relis souvent est que c'est portable. C'est vrai, mais le C est aussi un langage portable. Même plus portable que Java, car je peux compiler du code C sur une pléthorée d'architectures et de systèmes embarqués. Certes, même si écrire du C portable est plus difficile (car il faut y faire attention) que d'écrire du code Java portable, ça n'est pas impossible.

                • [^] # Re: Les développeurs Java

                  Posté par  (site web personnel) . Évalué à 2.

                  . À ton avis, dans quel langage est écrite la JVM (les parties qui ne sont pas en Java) ? Indice : en C/C++.

                  A ton avis, qui a écrit ce commentaire 1/2h avant toi :
                  http://linuxfr.org/nodes/86730/comments/1251702
                  :-p

                  Car oui, la JVM comporte aussi des bugs. Sauf que, quand mon programme Java plante à cause d'elle, je suis bien plus embêté

                  On parle pas de plantage mais de sécurité : il est fort probable que la JVM sera patchée plus vite que ton programme écrit dans ton coin.
                  Après c'est un problème différent, c'est le problème de dépendance envers un composant tiers : JVM, Qt, GTK,libxyz, etc.

                • [^] # Re: Les développeurs Java

                  Posté par  . Évalué à 2.

                  C'est vrai, mais le C est aussi un langage portable.

                  Et quand on essaye de porter le code dans une plate-forme où les pointeurs ne sont même pas foutus de tenir dans un long, paf le code.

                  • [^] # Re: Les développeurs Java

                    Posté par  . Évalué à -1.

                    Peux-tu être plus explicite ? Je pensais qu’il y avait des types spécifiques pour stocker des pointeurs, les fameux x*, et que le langage assurait que la taille de ses pointeurs était suffisamment grande pour la taille de la mémoire accessible au programme. Imagines la catastrophe si int *a = (int*)malloc(sizeof(int)); ne fonctionnait pas…

                    De plus il semblerait qu’un long peut avoir la taille d’un int, soit potentiellement la moitié de la taille de la mémoire accessible, car le premier est signé la seconde non. Un programme qui utiliserait les long pour stocker des pointeurs ne serait-il pas juste un programme buggé ? Autrement dit, rien dans la norme ne garantirait le résultat de long a = (long)malloc(sizeof(int)); construction que je n’ai jamais vu utilisée ni enseignée.

                    Ce qui rejoint la phrase qui suit celle que tu cites :

                    Certes, même si écrire du C portable est plus difficile (car il faut y faire attention) que d'écrire du code Java portable, ça n'est pas impossible.

                    • [^] # Re: Les développeurs Java

                      Posté par  (site web personnel) . Évalué à 3.

                      que le langage assurait que la taille de ses pointeurs était suffisamment grande pour la taille de la mémoire accessible au programme.

                      Le hic c'est que des petits malins utilisaient "long" pour stocker des pointeurs, en 32-bits pas de soucis, même taille donc erreur invisible (la connerie du C/C++ est effectivement de faire une "traduction" automatique entre un void* et un long).
                      Après, ben c'est aussi la faute du programmeur... (bon, maintenant, je ne sais pas pour GCC mais le compilo de Microsoft met un warning dans ce cas, ça se voit)

                      • [^] # Re: Les développeurs Java

                        Posté par  . Évalué à 2.

                        la connerie du C/C++ est effectivement de faire une "traduction" automatique entre un void* et un long

                        Pas en C++ (et ça fait un warning pas défaut avec GCC en C).

                        Étienne

                    • [^] # Re: Les développeurs Java

                      Posté par  . Évalué à 2.

                      Peux-tu être plus explicite ?

                      http://www.behindkde.org/node/895

                      • [^] # Re: Les développeurs Java

                        Posté par  . Évalué à -1.

                        des pointeurs dans un protocole c'est pas un peu comme l'eau dans le gaz ?

            • [^] # Re: Les développeurs Java

              Posté par  (site web personnel) . Évalué à 1.

              jnode pour ne pas le nommer...

              pour les cpu il y en a près d'une dizainne
              http://en.wikipedia.org/wiki/Java_processor

              www.solutions-norenda.com

        • [^] # Re: Les développeurs Java

          Posté par  (site web personnel) . Évalué à 7.

          Niveau performance, sur de gros programmes, un programmeur Java avec les bons outils de profiling réussira rapidement à avoir un logiciel plus rapide que son équivalent C/C++.

          Sur les micro-benchmarks, C et C++ resterons à mon avis toujours meilleurs car les performances découlent d'optimisations liées aux instructions processeurs utilisée.

          En revanche, sur un logiciel de plusieurs milliers de lignes (genre au hasard OpenConcerto :) ), en quelques minutes, avec jProfiler par exemple, le coder Java voit exactement:
          - où sont les hotspots à optimiser,
          - quand les threads sont en attentes,
          - ce qui est parallélisable
          et tout cela en ayant la hiérarchie des appels, les temps moyens, les nombres d'appels et j'en passe! Beauté de la chose: cela se fait sans recompiler ou modifier quoi que soit à l'application.

          Bref, l'outil étonne souvent, les pertes de performances sont rarement là où on les cherche. Ayant passé des heures à optimiser des codes assembleur, C, C++ et Java, je vois en java une excellente plateforme pour atteindre rapidement d'excellentes performance sur des logiciels de taille importante.

          Pour tout ceux qui n'aurait pas encore testé un outil comme jProfiler, faites un tour sur jOpenDocument section benchmark. Après quelques heures de profiling, nous avons optimisé la génération de documents OpenDocument: 17 ms pour créer un document (dont 12ms passées dans l'accès disque) quand une autre librairie (ODFDOM) à besoin de 126ms, ça parle tout de suite!

          • [^] # Re: Les développeurs Java

            Posté par  . Évalué à 1.

            En c++, avec un bon profiler, tu va dégommer tout profiler Java...pour la simple raison que ça fait 30 ans que ça existe en c++.....

            • [^] # Re: Les développeurs Java

              Posté par  . Évalué à 2.

              c'est un argument assez ridicule, ça fait 15 ans que ça existe avec Java...

              ...soit dès l'apparition du langage. comme pour C++

            • [^] # Re: Les développeurs Java

              Posté par  (site web personnel) . Évalué à 1.

              Si as en tête le nom d'un profiler C/C++ qui peut rivaliser, n'hésites pas car j'ai du passé à côté. (On ne pas tout connaître et tout tester!)
              J'imagine qu'il faudra tout de même recompiler l'appli... non?

        • [^] # Re: Les développeurs Java

          Posté par  (site web personnel) . Évalué à 2.

          Dans les avantages du C++, il y a entre autre la compatibilité avec le C, la performance et la méta-programmation. 3 avantages ignorés par Java.

          C et C++ sont des langages différents: il y a des programmes C qui ne sont pas des programmes C++ et vice-versa. La compatibilité est plutôt au niveau des compilateurs, qui supportent une alimentation variée.

          • [^] # Re: Les développeurs Java

            Posté par  . Évalué à 3.

            Exact mais ça fait partie de la norme donc du langage.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # et python ? :)

    Posté par  . Évalué à 3.

    Je ne suis pas un fan de java car je tombe pile dans les domaines où il est inefficace : la performance ou le traitement de donnée sans besoin d'interface (python est diablement efficace dans ces cas) mais l'article est très intéressant !
    Par contre, pour moduler tes propos, j'ai envie de dire que les cas où la performance est nécessaire (sans être un objectif) sont très nombreux et je connais beaucoup de logiciel qui ont fait le choix catastrophique de java : en voilà un pour la visualisation de graphe où on peut s'arracher les cheveux et qui montre bien que malgré son succès, java n'est pas le choix de l'utilisateur.

    • [^] # Re: et python ? :)

      Posté par  (site web personnel) . Évalué à 7.

      python n'est pas très rapide non plus à ce que je sache.

      • [^] # Re: et python ? :)

        Posté par  (site web personnel) . Évalué à 2.

        En Python, pour toutes tâche qui demande le la puissance, il y a des librairies bien intégrées en Python codées en C, C++, comme par exemple NumPy pour le calcul scientifique.

        Sinon il y a des solutions comme Cython pour accélérer les goulots d’étranglement des programme Python.

        À ma connaissance, les problèmes de perfs ne se situent "jamais" au niveau de l'interpréteur Python, ce qui consomme ce sont les accès aux bases de données, calculs…

        • [^] # Re: et python ? :)

          Posté par  . Évalué à 1.

          Il est possible de développer des parties en C et de les appeler depuis java.
          https://secure.wikimedia.org/wikipedia/fr/wiki/Java_Native_Interface
          Après, effectivement, je ne connais pas d'exemple, mais je ne me suis jamais intéressé au problème non plus.

          • [^] # Re: et python ? :)

            Posté par  (site web personnel) . Évalué à 2.

            Après, effectivement, je ne connais pas d'exemple, mais je ne me suis jamais intéressé au problème non plus.

            Quelques exemples utilisant JNI (le plus souvent il s'agit de wrapper pour s'interfacer avec des DLL) :
            - accès aux cartes à puce compatibles avec le standard ISO 7816
            - accès à la CryptoAPI sous Windows
            - cryptographie sur les courbes elliptiques (Java 7)
            - accès à la configuration système (par exemple pour obtenir la config du proxy)

          • [^] # Re: et python ? :)

            Posté par  (site web personnel) . Évalué à 1.

            Il est possible de développer des parties en C et de les appeler depuis java.
            https://secure.wikimedia.org/wikipedia/fr/wiki/Java_Native_Interface

            D'après mes lectures par curiosité:
            JNA : Appeler du C à partir de Java
            JNI: Appeler du Java à partir du C.

            Si ce n'est pas faux, les exemples cités par jcs ainsi que ta description sont JNA, pas JNI.

            Après, effectivement, je ne connais pas d'exemple,

            Perso, j'utilise JNA pour permettre à des développeurs Java d'utiliser ma librairie écrite en C++, c'est utile.
            JNI, ben j'imagine qu'il suffit d'avoir le problème inverse (avoir besoin d'un code Java alors que le reste de ton code est en autre chose)

            • [^] # Re: et python ? :)

              Posté par  . Évalué à 4.

              En fait JNI de faire l'interface entre le Java et le C, dans les deux sens.

              JNA c'est une surcouche à JNI qui évite d'avoir à écrire une DLL JNI spécialisée si on veut juste récupérer les exports d'une DLL existante. Avant JNA, on était obligé de faire une DLL JNI "glue" pour cela.

              Du coup ce que tu dis n'étais pas faux mais un peu incomplet (on na va plus utiliser très souvent utiliser JNI pour faire C -> Java mais JNA qui sera plus simple, sauf à avoir des besoins spécifiques)

              • [^] # Re: et python ? :)

                Posté par  (site web personnel) . Évalué à 1.

                Pour information il existe le projet bridj qui fait un peu la même chose que JNA tout en corrigeant ou améliorant certains points :
                - plus efficace que JNA
                - API plus "propre" (annotations, generics)
                - support pour C++, objective-C
                - etc

    • [^] # Re: et python ? :)

      Posté par  . Évalué à 2.

      la performance ou le traitement de donnée sans besoin d'interface (python est diablement efficace dans ces cas)

      Et perl c'est donc divin dans ce domaine ?

      Par contre, pour moduler tes propos, j'ai envie de dire que les cas où la performance est nécessaire (sans être un objectif) sont très nombreux et je connais beaucoup de logiciel qui ont fait le choix catastrophique de java : en voilà un pour la visualisation de graphe où on peut s'arracher les cheveux et qui montre bien que malgré son succès, java n'est pas le choix de l'utilisateur.

      Souvent c'est le programme qui est mal écris plus que le langage qui pose problème que ce soit d'un point de vu purement algorithmique/organisation du programme ou que ce soit la mauvaise connaissance/utilisation du langage.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: et python ? :)

      Posté par  (site web personnel) . Évalué à 8.

      depuis quand python est performant?

      www.solutions-norenda.com

      • [^] # Re: et python ? :)

        Posté par  (site web personnel) . Évalué à 6.

        Depuis qu'il utilise des modules dédiés pour les calculs, écrits en C ;-)

        Certains outils en Python (+C & Co) ont été cités ici:
        https://linuxfr.org/news/petite-actu-des-outils-d%E2%80%99analyse-num%C3%A9rique

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

        • [^] # Re: et python ? :)

          Posté par  (site web personnel) . Évalué à 1.

          a moins que ton application ne fasse que des calculs... tu auras pas de gain

          www.solutions-norenda.com

          • [^] # Re: et python ? :)

            Posté par  (site web personnel) . Évalué à 2.

            Il n'y a pas que les packages scientifiques qui sont compilés. Une bonne partie des bases de Python est écrite en C (conteneurs, traitements sur les chaînes...), de même que pas mal d'outils tiers qui sont généralement des wrappers autour de librairies existantes.

            Là où ça pêche, c'est quand tu as de gros traitements itératifs avec plein de petites opérations interprétées. Et... sur le multithread avec le problème du lock global.

            Bref, dans certains cas c'est pas tellement plus lent que du C/C++ à l'exécution, mais beaucoup plus rapide à l'écriture. Dans d'autres les perfs s'écroulent.
            Il faut l'utiliser à bon escient, éventuellement mettre en C une partie qui serait critique au niveau temps, ou voir des outils comme ShedSkin.

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

            • [^] # Re: et python ? :)

              Posté par  . Évalué à -1.

              ahah, je ne disais pas que python était performant... pour ça je pensais à C.
              Pour ma part je le conseille cependant dans mes projets de développement plutôt que java. Car python est basé sur des routines C optimisés et il y a certaines astuces en python qui permettent de faire du code très rapide.
              Enfin je fais pour ma part du python - mpi et je ne crois pas que mpj (pour java) ne rencontre le même succès sur les calculateurs...

              • [^] # Re: et python ? :)

                Posté par  (site web personnel) . Évalué à 5.

                Et tu crois que la VM Java elle est codée en Java ou en C/C++ ?
                Et tu crois qu'aucune bibliothèque Java de calcul n'est optimisée avec du code écrit en C/C++ ?
                Et tu crois que le code Java est généralement interprété ou traduit en code natif comme le C avant exécution ?

                Franchement faut arrêter les conneries, dans 90% des cas le Python est attrocement lent. Java n'est pas une foudre de guerre, loin de là, mais c'est pas du tout comparable.

                • [^] # Re: et python ? :)

                  Posté par  (site web personnel) . Évalué à 0.

                  Franchement faut arrêter les conneries, dans 90% des cas le Python est atrocement lent.

                  Je n'ai jamais rencontré ce problème… mais peut être que je n'ai pas les même contrainte que toi.

            • [^] # Re: et python ? :)

              Posté par  (site web personnel) . Évalué à 2.

              tiens, en:ShedSkin devrait avoir ses paquets fedora/debian d'après http://shed-skin.blogspot.com/2011/02/shed-skin-071-help-needed.html (shedskin 0.8.1 est dans fedora depuis juin, pas vu dans debian :/)

              peut-être l'occasion de faire une dépêche sur LinuxFr pour ceux motivés ;-) voire de faire un point sur les implémentations de python comme en 2006

              idem pour en:cytoscape cité plus haut, dont LinuxFr n'a jamais parlé alors qu'il y a un tag visualisation ;-)

      • [^] # Re: et python ? :)

        Posté par  . Évalué à 3.

        Il faut maintenant regarder du côté de PyPy si on a besoin de performance pure du langage (ce qui est rarement le cas). Les résultats sont considérables dans certains domaines et ça continue à progresser sans arrêt.
        Sur un programme de calcul d'itinéraire on a eu un facteur supérieur à 10 sans changer une ligne de code !
        Ce qui est marrant dans ce projet c'est qu'au départ le programme était écrit en C, il était trop lent et trop complexe, il a été réécrit en Python pour servir de prototype avec d'autres algorithmes. Résultat le prototype est allé 10x plus vite qu'en C car la facilité de programmation à permis de se concentrer sur l'algo, on l'a gardé comme ça en prod pour faciliter la maintenance (qui est finalement nulle). On a été tenté de le transcrire en Java mais des tests sur le même genre d'algo n'ont montré qu'un gain très faible pour une complexité bien supérieure.

        http://speed.pypy.org/

        • [^] # Re: et python ? :)

          Posté par  (site web personnel) . Évalué à 2.

          L'histoire ne dit pas si en C correct (avec le même algo qu'en Python), ce ne serait pas 10x plus rapide et donc intéressant...

          • [^] # Re: et python ? :)

            Posté par  (site web personnel) . Évalué à 4.

            A savoir qu'une équipe travaille à virer le plus possible le C de la machine Parrot pour en écrire un maximum en Parrot. Donc au final dans la même veine que Pypy.

    • [^] # Re: et python ? :)

      Posté par  . Évalué à 10.

      Python a l'avantage d'être plus facile à coder que Java.
      Il des types de base plus pratiques (list, dict, ...) et est beaucoup plus expressif.

      Écrire ceci :

      mydict = {'a': 1}

      est moins fatigant qu'écrire cela :

      HashMap<String, Integer> myMap = new HashMap<String, Integer>();
myMap.put("a", 1);

      • [^] # Re: et python ? :)

        Posté par  (site web personnel) . Évalué à 3.

        Java et Python ne couvrent pas (tous) les mêmes cas d'utilisation. Python n'est pas compilé et si ce n'est pas un problème pour des petits à moyen projet, c'est un gros problème pour des gros projets. La compilation permet de vérifier les interfaces, d'avoir une erreur de compile quand un petit malin a changé une interface. Ca permet d'éviter un certain nombre (pas tous) de problèmes en amont alors qu'avec Python ça va péter lors de l'exécution, ce qui est vraiment lourd quand ton programme prend 10 minutes à se lancer (distribué sur plusieurs machines, toussa).

        • [^] # Re: et python ? :)

          Posté par  (site web personnel) . Évalué à 1.

          La compilation permet de vérifier les interfaces, d'avoir une erreur de compile quand un petit malin a changé une interface.

          Pour cela, tu as les tests unitaires… qui sont biens plus efficaces que la vérification des types…

          • [^] # Re: et python ? :)

            Posté par  (site web personnel) . Évalué à 10.

            À condition de les écrire … :)

          • [^] # Re: et python ? :)

            Posté par  (site web personnel) . Évalué à 2.

            J'étais sûr que quelqu'un allait me répondre ça. Mais les tests unitaires ne te permettent pas de tester toutes les interfaces, parce qu'en général les interfaces complexes, tu les implémente via des mock. Donc même si ton interface a changé entre deux, il y a de grandes chances que ton mock continue à fonctionner.

            • [^] # Re: et python ? :)

              Posté par  (site web personnel) . Évalué à 2.

              Tu as peut être raison… je ne peux pas dire car je n'ai jamais rencontré ce type de problème.
              Tu dois sans doute travailler dans des environnement bien plus complexe que les miens.

              En tous les cas, pour ma part, les tests me permettent de découvrir 90% des erreurs, et j'ai pratiquement jamais d'erreur de typages.

              • [^] # Re: et python ? :)

                Posté par  . Évalué à 4.

                ton programme prend 10 minutes à se lancer

                Déjà là ça commence mal...

                Je me pose également une question existentielle. Pourquoi les développeurs donnent tant d'importance aux erreurs de typage lorsqu'ils en sont protégés et non ceux qui devraient en être les victimes ? Pour ma part, non plus, la seule fois que je me souvienne d'avoir été embêté avec des erreurs de typage c'est quand je suis passé en unicode. Mis à part ça je ne me souviens pas que ça m'ait posé de problème, quelqu'en soit le langage.

      • [^] # Re: et python ? :)

        Posté par  (site web personnel) . Évalué à 6.

        Moins fatiguant, mais ça n'est pas du tout la même chose.

        La version Java précise les types possibles et une implémentation de tableau associatif.

        En python un développeur peut venir derrière et pourrir ton programme avec un mydict[ 42] = "pouet".

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: et python ? :)

        Posté par  . Évalué à 1.

        Il y a le choix:

        • Passer par d'autres languages comme scala ou groovy
        • Ca n'est pas aussi terrible que ca en a l'air en java avec eclipse qui auto-complete les 3/4 des choses

        • [^] # Re: et python ? :)

          Posté par  (site web personnel) . Évalué à 1.

          Ou plus simplement à Python ou Ruby sur... la JVM...

          On a oublié Clojure aussi.

          • [^] # Re: et python ? :)

            Posté par  . Évalué à 4.

            Je crois bien plus en la pérennité de Scala et Groovy sur la JVM que Python, Ruby ou autre. D'ailleurs scala et groovy n'ont rien a envier à python ou ruby dans leur syntaxe et leur expressivité (surtout scala).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: et python ? :)

        Posté par  . Évalué à 2. 

        HashMap<String, Integer> myMap = new HashMap<String, Integer>();
myMap.put("a", 1);

        En Java on écrirais plutôt comme ça :

        Map<String, Integer> myMap = new HashMap<String, Integer>();
myMap.put("a", 1);

        et en Java 7 on écriras ça :

        Map<String, Integer> myMap = new HashMap<>();
myMap.put("a", 1);

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: et python ? :)

          Posté par  . Évalué à 2.

          voir comme ça:

          Map<String, Integer> myMap = new HashMap<>() {{
    put("a", 1); 
}};

          http://www.c2.com/cgi/wiki?DoubleBraceInitialization

          • [^] # Re: et python ? :)

            Posté par  . Évalué à 2.

            Ça c'est idiot, ça crée une sous-classe (anonyme) de HashMap sans raison, dont un fichier .class en plus à charger, qui va aller prendre un peu de mémoire dans la partie non-heap, si tu multiple ce genre de construction tu va consommer toute la mémoire non-heap (qui est beaucoup plus rarement libérée).

            • [^] # Re: et python ? :)

              Posté par  . Évalué à 2.

              à force de reprendre toutes les tares de C++, aussi... même celles qui volontairement laissées de côté au début

        • [^] # Re: et python ? :)

          Posté par  (site web personnel) . Évalué à 5.

          En Java 7 on écrira même :

          Map map = {"a" : 1};

          Cf http://code.joejag.com/2009/new-language-features-in-java-7/

          C'est tout de même dommage que c'est uniquement maintenant que ce genre de truc est simplifié. Java est un excellent langage mais des fois on se demande si les concepteurs de ce langage l'utilisent tellement des trucs simples à faire d'autres langages sont si chiants et verbeux à mettre en place en Java. Java 7 va changer la donne mais p*tain, il aura fallu attendre !

          Bon en même temps, au taf on fait encore du Java 1.4 alors pour moi ces "new features" ne sont qu'un rêve :(

          D'ailleurs pour avoir reçu une formation sur C# je dois dire bravo à Microsoft pour ce langage. J'ai aussi reçu une formation en ASP.Net et là par contre on retrouve Microsoft : des supers trucs biens pensés et des trucs immondes mélangés ensembles.

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

          • [^] # Re: et python ? :)

            Posté par  (site web personnel) . Évalué à 1.

            D'ailleurs pour avoir reçu une formation sur C# je dois dire bravo à Microsoft pour ce langage.

            C#, le langage où les valeurs par défaut d'une fonction (genre "int A(int x=2, int y=1)") sont apparues que récemment, euh... Non, pas bravo, "un peu" de retard par rapport à C++.

            • [^] # Re: et python ? :)

              Posté par  (site web personnel) . Évalué à 3.

              Faut voir que ça n'existe toujours pas en Java. Mais bon, c'est pas un truc très grave car ça se résout facilement en ajoutant : 

              int A(int x) {
     return A(x,1);
}
int A() {
     return A(2);
}

              L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

              • [^] # Re: et python ? :)

                Posté par  (site web personnel) . Évalué à 2.

                Oui, je fais cette bidouille. Mais ça me fait sourire qu'un simple truc de ce genre ne soit pas pris en compte "de base". Alors oui, C++ c'est verbeux, dangereux, etc... Mais ça a cette fonctionnalité :)

              • [^] # Re: et python ? :)

                Posté par  . Évalué à 3.

                c'est quand même pas mal dans les constructeurs pour savoir quel est la valeur par défaut de chaque argument de manière (assez lisible).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: et python ? :)

                  Posté par  . Évalué à 3.

                  Sans compter que ce bidouillage ne reproduit pas le comportement des valeurs par défaut. Du moins tel que je le connais sous Python : pouvoir faire des appels avec n’importe quel sous ensemble des mots-clefs disponibles et dans n’importe quel ordre.

                  f(d=0)
f(a=3, b=2)
f(b=1, c=5)
f(c=1, a=2)
...

                • [^] # Re: et python ? :)

                  Posté par  (site web personnel) . Évalué à 4.

                  Tout à fait, ça serait plus pratique.

                  Mais je parlais surtout d'autres trucs plus gênants où il est facile d'introduire des petits bugs si on le fait trop vite :
                  - La copie de fichier qui reste lourde à faire en Java (Cf http://edgblog.wordpress.com/2010/02/20/how-to-copy-a-file-in-java/ ). Sera enfin réglé en Java 7.
                  - La fermeture des connexions à une base de données qui est souvent male faite par les débutants. Sera réglé en Java 7 avec les AutoCloseable.
                  - Le switch/case sur les chaînes de caractères pas possible avant Java 7.
                  - Les types primitifs pas Objet. Plus ou moins réglé avec l'AutoBoxing mais qui comporte des surprises http://bexhuff.com/2006/11/java-1-5-autoboxing-wackyness
                  - ...

                  L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: et python ? :)

        Posté par  . Évalué à 0.

        Écrire ceci :

        mydict = {'a': 1}

        En fait, en C++, on doit pouvoir écrire :

        auto myMap = {{'a', 1}};

        A confirmer tout de même.

        • [^] # Re: et python ? :)

          Posté par  . Évalué à 3.

          J'ai comme un doute parce que je ne vois pas comment il va choisir les classes (par exemple pour la clef il doit choisir une classe qui possède une constructeur ne prenant qu'un caractère et pour la valeur une classe qui possède un constructeur ne prenant qu'un entier et ça il y en a plusieurs).

          auto comme son non l'indique c'est de la recherche automatique de type et pas de l'inférence (enfin je crois).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # J'aime Java car...

    Posté par  . Évalué à 6.

    ...mon employeur est très consommateur d'application Java faites par des équipes qui changent tout le temps, dispersés un peu partout en France et vers l'est du Globe, ce qui donne au final des applications bancales qui ont besoin d'être testées !!!

    Tada et comme je fais des tests et bien j'ai plein de boulot ce qui me permet d'avoir pleins de loisirs sympathiques grâce à mon salaire :-)

    Bon, ça pourrait marcher avec autre chose que Java (le langage est-il réellement la cause des développements livrés en retard et fonctionnellement à la rue ?) mais le vendredi c'est permis :-)

    Amis développeurs, continuez !

    @+

  • # Part de marché

    Posté par  (site web personnel) . Évalué à 2.

    En cinq ans, Java s'est imposé à presque 30% de part de marché, qui restera dans l'histoire une progression unique.

    c'est d'après TIOBE Programming Community Index ? qui se base sur le nombre de recherche fait sur un mot clé.....

    suffit d'aller sur les sites d'emploi des États-unis, Angleterre, France, Inde pour voir que Java domine largement le marché

    www.solutions-norenda.com

    • [^] # Re: Part de marché

      Posté par  . Évalué à -2.

      Sur les principaux projets open-source, Java est absent.

      • [^] # Re: Part de marché

        Posté par  . Évalué à 8.

        Et les fondation Apache/Eclipse c'est du poulet ?

        Au contraire, un nombre incroyable de projets open-source sont les références de fait dans écosystème Java. En vérité il est même plutôt rare d'utiliser des softs non open-source... Le marché de Java c'est les serveurs et les backend de site web.

        • [^] # Re: Part de marché

          Posté par  . Évalué à 4.

          Je suis tout à fait d'accord. D'ailleurs c'est pour ça que maven a autant de succès.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Part de marché

            Posté par  . Évalué à 5.

            Pas que Maven par ailleurs.
            Pour l'ecosysteme d'Apache Hadoop, la plupart des developpeurs principaux n'arretent pas de remercier Java car ces projets ne seraient pas aussi avances si Java n'avait pas ete utilises. La derniere fois que je l'ai entendu etait au Hadoop Summit l'autre jour.

            Cela me rappelle fortement l'article de GLMF sur l'industrialisation de Java. Choses pour lesquelles j'aimerai bien connaitre les equivalents C++ par curiosite.

            Meme si maven a ouvert la porte a pas mal de comportements degueulasses.

            • [^] # Re: Part de marché

              Posté par  (site web personnel) . Évalué à -2.

              Combien de programme Java utilise t'on sur une distribution classique GNU/Linux ?

              Dans mon laboratoire de recherche, il n'y a aucune application interne et critique en Java. Par exemple, il n'y a pas longtemps, j'ai mis en place un serveur DAP, il y avait le choix entre OpenDAP et PyDAP, je suis partis sur PyDAP car je ne souhaitais pas avoir un Tomcat et tous les fichiers XML qui vont avec. Idem, si j'avais un serveur jabber à mettre en place, je mettrais ejaberd en Erlang...

              Les seules applications Java qu'on utilise, ce sont les logiciels de comptabilité de l'université et du CNRS qui sont sur une base SAP. Question ergonomie, on m'a dis que c'est pas top et question coût pour le contribuable, je ne suis pas sur que ce genre de logiciel soit "rentable"...

              Je dirais donc que Java est une belle usine à gaz et une belle pompe à fric pour les SSII mais je ne suis pas sur que le monde tournerais différemment sans Java ;-)

              Ceci dis, avec les millions de lignes Java qui traînent sur le net et l'énergie humaine dépensée dessus, il est clair qu'il est inévitable d'utiliser Java de temps en temps et de plus en plus dans les années qui viennent.

              • [^] # Re: Part de marché

                Posté par  . Évalué à 3.

                C'est un troll c'est ca ? Ou tu essais de t'auto-convaincre que java n'est utilise par personne car tu ne l'utilises pas ?

                As-tu la moindre idee de ce qu'est Apache Hadoop ? Les gens derriere sont loin d'etre des rigolos.
                Peut-etre que dans ton cas tout cela ne s'applique pas, mais dans leur cas, java leur est extremement utile, non seulement pour la rapidite de developpement, mais tout les outils autour.

                Le python c'est sympa et semble te convenir, mais c'est loin d'etre aussi mature que java.
                Il y a bien une raison si les boites comme twitter passent de languages rigolos comme ruby a une infrastructure base sur la JVM.

                • [^] # Re: Part de marché

                  Posté par  . Évalué à 1.

                  C'est un troll c'est ca ? Ou tu essais de t'auto-convaincre que java n'est utilise par personne car tu ne l'utilises pas ?

                  As-tu la moindre idee de ce qu'est Apache Hadoop ? Les gens derriere sont loin d'etre des rigolos.
                  Peut-etre que dans ton cas tout cela ne s'applique pas, mais dans leur cas, java leur est extremement utile, non seulement pour la rapidite de developpement, mais tout les outils autour.

                  Le python c'est sympa et semble te convenir, mais c'est loin d'etre aussi mature que >java.
                  Il y a bien une raison si les boites comme twitter passent de languages rigolos comme ruby a une infrastructure base sur la JVM.

                  Pour moi l'avantage donné à Java est avant tout dû au « potentiel commercial » . En fait python n'est pas supporté par une entreprise comme Java a pu l'être ou l'est encore... « Langage rigolo » , j'ai l'impression que cela s'applique plus en fait à la taille et au nombre de gens qui sont derrière et soutiennent les améliorations du langage et de la JVM. Pour moi, Java c'est plutôt une façon de se cacher derrière le nombre d'utilisateurs et le nombre de développeurs plutôt que sur des réels avantages techniques.

                  À mon avis, une vraie façon de comparer deux langages devrait se baser sur les fonctionnalités de la librairie standard. Je pense que python est largement comparable à Java dans ce cas.

                  languages rigolos comme ruby
                  Les gens derriere sont loin d'etre des rigolos.

                  Avec des argumentations comme celle là, on n'est pas sorti de l'auberge. Pense aussi à travailler ton orthographe et à ajouter des accents dans ton texte.

                  Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

                  • [^] # Re: Part de marché

                    Posté par  . Évalué à 3.

                    Pour moi l'avantage donné à Java est avant tout dû au « potentiel commercial » . En fait
                    python n'est pas supporté par une entreprise comme Java a pu l'être ou l'est encore... «
                    Langage rigolo » , j'ai l'impression que cela s'applique plus en fait à la taille et au
                    nombre de gens qui sont derrière et soutiennent les améliorations du langage et de la
                    JVM. Pour moi, Java c'est plutôt une façon de se cacher derrière le nombre
                    d'utilisateurs et le nombre de développeurs plutôt que sur des réels avantages
                    techniques.

                    Bof, il y a des tas d'entreprises avec des interets financiers dans python.
                    Par ailleurs, le fait qu'il n'y ait qu'une boite derriere java est un desavantage face a python. Surtout quand on voit la direction dans laquelle Oracle semble se diriger.

                    À mon avis, une vraie façon de comparer deux langages devrait se baser sur les
                    fonctionnalités de la librairie standard. Je pense que python est largement comparable > à Java dans ce cas.

                    La bibliotheque standard n'est qu'un critere parmis d'autres. Mais meme sur la bibliotheque standard python ne peut pas se comparer face a java (au sense large).
                    Java est specifie et a toutes les bibliotheques necessaires pour tourner aussi bien sur des smartcards que dans le browser (je suis toujours impressione par http://jmonkeyengine.com/demo/webstart/ ). Ceci dit cela ne veut pas dire que python est pauvre (je pouvais meme coder en python sur mon vieux S60).

                    Avec des argumentations comme celle là, on n'est pas sorti de l'auberge.

                    Le message auquel je repondais n'etait pas vraiment argumente non plus :)

                    Pense aussi à travailler ton orthographe et à ajouter des accents dans ton texte.

                    J'y travaille, malheureusement le francais n'est plus ma langue premiere depuis un certain temps.

                    • [^] # Re: Part de marché

                      Posté par  . Évalué à 1.

                      J'y travaille, malheureusement le francais n'est plus ma langue premiere depuis un certain temps.

                      Oui je me disais que tu dois utiliser un clavier sans accent.
                      T'es pas obligé, si l'anglais te satisfait :p

                      Le message auquel je repondais n'etait pas vraiment argumente non plus :)

                      C'est ça le principe du troll. :p

                      Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

                • [^] # Re: Part de marché

                  Posté par  . Évalué à 4.

                  Il y a bien une raison si les boites comme twitter passent de languages rigolos comme ruby a une infrastructure base sur la JVM.

                  Seul une petite partie de Twitter est Scala (pas en Java d'ailleurs). Et Ruby peut très bien tourner sur une JVM. Il ne faut pas confondre JVM et Java.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Part de marché

                Posté par  . Évalué à 3.

                Tu n'utilise pas donc c'est pas utilisé dans le libre ? Le libre ce n'est que GNU/Linux ?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Part de marché

                  Posté par  . Évalué à 4.

                  selon certaines têtes de cul, ce n'est même que GNU. et encore, seulement la GPL v3 en attendant les suivantes

              • [^] # Re: Part de marché

                Posté par  . Évalué à 1.

                Les seules applications Java qu'on utilise, ce sont les logiciels de comptabilité de l'université et du CNRS qui sont sur une base SAP. Question ergonomie, on m'a dis que c'est pas top et question coût pour le contribuable, je ne suis pas sur que ce genre de logiciel soit "rentable"...

                Pour l'université, je ne sais pas, mais pour le CNRS, si c'est de XLAB que tu parles, c'est pas du Java, mais du Omnis. Quand à SAP, c'est du ABAP, pas Java.

                • [^] # Re: Part de marché

                  Posté par  (site web personnel) . Évalué à -1.

                  Je parlais de la partie centrale de la comptabilité CNRS, pas de la super application ayant un super installateur silencieux XLAB ;-)

                  J'avoue que de SAP, je n'ai vu que rapidement le client lourd et le client web qui tourne dans un bureau virtuel SUN. Dans le genre usine à gaz, le bureau virtuel en java de SUN est quelque chose, surtout pour n'utiliser au final que SIFAC...

                  En tout cas, merci, je découvre que SAP utilise son propre langage. Vu qu'Oracle a pris le contrôle de Java, ils sont peut être pas près de basculer !

        • [^] # Re: Part de marché

          Posté par  . Évalué à 1.

          Si je me souvient bien, le plus célèbre des projets apache, le serveur http n'est pas écrit en java. Eclipse, c'est normal que ce soit en java, c'est pour faire du java. Quand au site web, je croyais que c’était du LAMP qui était majoritaire.
          Que les programmeurs Java se servent du libre, c'est un fait que je ne nie pas. Mais c'est aussi le cas de beaucoup d'autres langages.
          Ce que je dit c'est que les principaux projets libres (les plus connues/utilisés) ne sont pas écrit en Java (sauf Eclipse). Si vous en connaissez merci de me le dire.

          • [^] # Re: Part de marché

            Posté par  (site web personnel) . Évalué à 1.

            Ce que je dit c'est que les principaux projets libres (les plus connues/utilisés) ne sont pas écrit en Java (sauf Eclipse)

            Problème de licence?

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Part de marché

            Posté par  . Évalué à 3.

            Eclipse, c'est normal que ce soit en java, c'est pour faire du java.

            argument idiot et surtout historiquement faux. à t'écouter, ça voudrait dire que Visual Basic était écrit en Visual Basic et Visual FoxPro était écrit en FoxPro. je me demande en quoi Visual Studio est écrit. en studio ou en Visual Studio ?

            historiquement la plupart des outils de dev (avec interface graphique, les IDE, les "studio", quoi) pour Java étaient des reprises d'outils existants, en général pour C/C++. c'est particulièrement criant sous Windows, avec par exemple Visual Café (Symantec), Visual J++ (Microsoft), VisualAge for Java (IBM), à chaque fois la généalogie n'est pas très dure à établir

            et c'était en grande partie (outre parce que AWT comme les premières JFC sentaient particulièrement des pieds) qu'il fallait vite prendre des parts de marché, donc autant prendre l'un des outils IDE/Studio qu'on éditait déjà, enlever deux trucs et rajouter trois machins, et pouf on colle Java dans le nom à la place du langage précédent, plutot que refaire entièrement un IDE à partir de rien.

            JBuilder (Borland) et Netbeans (Sun) sont arrivés un peu après (et Eclipse encore après), et pour la petite histoire on notera que Netbeans fut racheté par Sun plutot que d'être développé intra-muros. parce que les outils de développements de Sun étaient plutôt... calamiteux (Visual Workshop, Java Studio). les mauvaises langues rapprocheront ce détail de l'origine de OpenOffice (StarOffice) comme de la plupart des outils logiciels vendus par Sun. mais bref, c'est du passé maintenant.

            (si vous êtes sages, je vous parlerai un jour de Lotus Bean Machine. une horreur.)

    • [^] # Re: Part de marché

      Posté par  (Mastodon) . Évalué à 1.

      suffit d'aller sur les sites d'emploi des États-unis, Angleterre, France, Inde pour voir que Java domine largement le marché

      Turnover, toussa...

  • # Ce commentaire est Schrödingerement pro- et anti-java

    Posté par  . Évalué à 3.

    c,p,i,j,n,F=160,k,m;float a,x,y,S=0,V=0;main(){for(;F--;usleep(90000),F?puts("\x1b[49A"):0)for(S+=V+=(1-S)/50-V/32,j=0;j<144;j+=3,putchar(10))for(i=0;x=S*(i-77),i++<173;putchar(c[" ''\".$u$"]))for(c=0,n=3;n--;)for(y=S*(j+n-72),k=0,c^=(136*x*x+84*y*y<92033)<<n,p=6,m=0;m<8;k++["<[\\]O=IKNAL;KNRbF8EbGEROQ@BSXXtG!#t3!^"]/1.16-68>x*cos(a)+y*sin(a)?k=p,p="<AFJPTX"[m++]-50:k==p?c^=1<<n,m=8:0)a=(k["O:85!fI,wfO8!yZfO8!f*hXK3&fO;:O;#hP;\"i[by asloane"]-79)/14.64;}

  • # Déjà vendredi ?

    Posté par  . Évalué à 5.

    Jolie troll Java vs C++ !

    • [^] # Re: Déjà vendredi ?

      Posté par  (site web personnel) . Évalué à 4.

      Déjà vendredi ?

      heu... oui. Pourquoi, tu avais un doute ?

      • [^] # Re: Déjà vendredi ?

        Posté par  . Évalué à 9.

        Ahlala j'arrive après la bataille…

        pour la peine, j'en place une petite que personne ne remarquera:

        — Why all Java programmers live in Atlantis ?

        — Because it's below C level.

        Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

      • [^] # Re: Déjà vendredi ?

        Posté par  . Évalué à 1.

        Pour tout te dire, .... oui !

    • [^] # Re: Déjà vendredi ?

      Posté par  . Évalué à 2.

      oui joli troll.

      J'ai arrêté au très pompeux "Java est un des langages de programmation les plus auréolés de succès de ces quatre dernières décennies."

      Au moins l'intro à le mérite de faire comprendre que l'article ne risque pas d'être très objectif et d'éviter de perdre du temps à le lire.

      • [^] # Re: Déjà vendredi ?

        Posté par  . Évalué à 5.

        Oui mais quand on s'appelle Matthieu C on ne peut, a priori, que détester tout article traitant de Java, non ?

        :-D

      • [^] # Re: Déjà vendredi ?

        Posté par  (site web personnel) . Évalué à 7.

        C'est marrant, mais t'as mal compris le sens de la démonstration!

        Je fais partie de ceux qui sont absolument consterné par le succès de cette sombre m**** qu'est ce langage.

        Mais force est de remarque que Britney Spears, Céline Dion, MacDo et Java ont énormément de succès. C'est donc un phénomène à analyser.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # En vrac

    Posté par  (site web personnel) . Évalué à 4.

    C++ est un langage de programmation né en 1980. Au départ, il était conçu comme une
    amélioration du langage procédural C, dont il reprend les définitions. D'où son nom.

    Je rappelle le bogue premier du C++ puisque l'assertion suivante est vrai, tant en C, qu'en C++ !

    C++ < C

    Sinon, pas un mot sur OpenStep, la couche graphique très bien réalisé au dessus d'ObjectiveC. D'ailleurs, pas un mot sur l'ObjectiveC. Au début de java, OpenStep état à 50% à SUN avec qu'Apple ne prennent le virage MacOSX qui est la suite d'OpenStep. C'était quand même l'API la mieux fichus à l'époque et je ne sais pas s'il y en a une qui l'a dépassé.

    http://en.wikipedia.org/wiki/OpenStep

    A noter aussi un autre langage /a priori/ mieux fichus pour le web car les variables sont immutables, qui tournent aussi dans l'embarqué et qui est plus ancien que le java : Erlang.

    http://en.wikipedia.org/wiki/Erlang_(programming_language)

    A mon avis, java bénéficie de la syntaxe du C ce qui a aidé grandement a son adoption. J'ai l'impression que deux syntaxes ont plus de chance d'avoir une adoption massive par les programmeurs : C (C++, Java, ObjectiveC, C#... Perl, PHP...) et Fortran (Pascal, Basic, Ada... Bash...).

    • [^] # Re: En vrac

      Posté par  (site web personnel) . Évalué à 5.

      Je rappelle le bogue premier du C++ puisque l'assertion suivante est vrai, tant en C, qu'en C++ !

      C++ < C

      Tu veux dire C++ <= C ?

      • [^] # Re: En vrac

        Posté par  . Évalué à 2.

        Je pense pas, ce serait moins "étonnant".

        Si les expression sont évalué de gauche à droite, on a bien C++ < C . Cependant je ne vois pas en quoi c'est un bug?

        Prenons c = 2, on veux évaluer A < B avec A: c++ et B: c
        On évalue A : A = 2 puis incrémentation de c : c = 3
        On évalue B : B = 3
        évaluation de A < B : Vrai

      • [^] # Re: En vrac

        Posté par  . Évalué à -4.

        ça peut dépendre de l'ordre d'évaluation des expressions C++ et C qui peut varier d'un compilo à l'autre il me semble (je n'ai pas vérifié pour un opérateur de comparaison mais je sais que ça existe pour un appel de fonction)

      • [^] # Re: En vrac

        Posté par  (site web personnel) . Évalué à 1.

        Tu veux dire C++ <= C ?

        Non, C++ est vraiment < C
        Pourquoi?
        C++ veut dire "je prend le chiffre avec le quel je fais la comparaison, puis j'incrémente". Donc le C de gauche vaut C, le C de droite vaut C+1 (incrémenté par le ++ de gauche, la gauche est testé avant la droite)

        Par contre +CC n'est pas < C
        Car +CC veut dire "j'incrémente, puis je prend le chiffre avec le quel je fais la comparaison", donc le C de gauche vaut C+1, le C de droite vaut C+1.

        Subtilité certes, il faut "juste" savoir ce que veut dire "++" en C++, et on fait jamais ça en pratique. "C++; if (C<C)" c'est plus sûr, plus compréhensible.
        Oui, il y a des piège en C++, mais il y en a aussi en Java ou Python, juste pas les mêmes.

        ça peut dépendre de l'ordre d'évaluation des expressions C++ et C qui peut varier d'un compilo à l'autre

        Et puis quoi encore. C'est dans la norme C++, un compilo qui ne fait pas ce que tu la norme est un compilo buggué. Ce n'est pas un cas de résultat indéfini, au contraire, c'est un cas d'école très classique (dans le même style que le truc sur les float en PHP qu'on retrouve dans des tests à la con)

        • [^] # Re: En vrac

          Posté par  (site web personnel) . Évalué à 2.

          En fait, cela marche avec tous les langages qui ont l'opérateur de post incrémentation donc le résultat est le même en Perl...

          En pratique, la morale de l'histoire est qu'il ne faut jamais faire de test avec des fonctions qui ont des effets de bords. Je crois d'ailleurs que c'est une des règles qui se trouve le bouquin passionnant "De l'art de programmer en Perl" de Damian Conway.

        • [^] # Re: En vrac

          Posté par  (Mastodon) . Évalué à 3.

          Résultat identique avec gcc et g++ 4.6.1

          warning: operation on ‘c’ may be undefined [-Wsequence-point]

          Et quand on voit apparaître la notion de «sequence point», on sait que c'est le bordel. D'ailleurs, il me semble qu'elle va être clarifié parce que ça impacte la définition du modèle mémoire qui va (enfin) être défini pour le C. (voir aussi en:Sequence_point).

          • [^] # Re: En vrac

            Posté par  (site web personnel) . Évalué à 6.

            Comme quoi on en apprend tous les jours :
            " An often-cited example is the C expression i=i++, which apparently both assigns i its previous value and increments i. The final value of i is ambiguous, because, depending on the order of expression evaluation, the increment may occur before, after, or interleaved with the assignment. The definition of a particular language might specify one of the possible behaviors or simply say the behavior is undefined. In C and C++, evaluating such an expression yields undefined behavior.[2]"

            Moi qui était persuadé que l'ordre était défini dans la spec et donc que tous les compilateurs faisaient pareil... Bon, ben je saurai maintenant, lecture intéressante.

          • [^] # Re: En vrac

            Posté par  . Évalué à 2.

            Concernant le modèle mémoire de C, il ne faut pas s'attendre à des miracles. Quand on voit le modèle suivi par C++...

        • [^] # Re: En vrac

          Posté par  . Évalué à 4.

          Eeeeuh, tu es sûr de ton coup là ? Parce que tout ce que je vois, c'est une lvalue et une rvalue qui utilisent le même objet. Du coup, c'est un comportement indéfini, si je ne m'abuse (et le compilo peut faire ce qu'il veut, même décider d'aller commander un sandwich sur le net s'il veut).

  • # Article léger à la rédaction lourde

    Posté par  . Évalué à 4.

    Article intéressant par son sujet, l'histoire de Java. À la lecture, c'est plus un empilement d'anecdotes où on cherche vainement des aspects techniques en dehors du troll peu convaincant C++ versus Java.

    Cet article, genre ébauche Wikipédia, donne envie de le réécrire avec un style beaucoup moins lourd, sans les anecdotes inutiles, ni fautes de grammaire et en le complétant.

    Et où est passé Oracle, acteur récent et contesté mais majeur de l'histoire de Java ?

    Ce commentaire sévère n'a pas pour but de décourager mais de tous nous inciter encore et encore à écrire de bons articles... et moi en premier.

    • [^] # Re: Article léger à la rédaction lourde

      Posté par  (site web personnel) . Évalué à 5.

      Cet article a l'immense mérite d'exister. Si tu penses pouvoir mieux faire, surtout, fais-le !
      Ne t'en prive pas et ne nous en prive pas non plus !

    • [^] # Re: Article léger à la rédaction lourde

      Posté par  (site web personnel) . Évalué à 6.

      Cet article n'est pas "l'histoire de Java".

      Je cherche analyser les raisons environnementales, conjoncturelles et culturelles qui ont fait le succès de ce langage : Java est passé de rien à peut être 30% de part de marché en 5 ans, autrement dit de 20 développeurs à plusieurs centaines de miliers, c'est intéressant d'essayer de comprendre ce qui s'est passé.

      Par conséquent, je ne cherche pas d'arguments techniques, je me suis forcé à les oublier (et ça été dur).

      Je m'intéresse à la période 1995-2000, donc Oracle n'a rien à faire dans l'histoire.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Article léger à la rédaction lourde

        Posté par  . Évalué à 5.

        Je m'intéresse à la période 1995-2000, donc Oracle n'a rien à faire dans l'histoire.

        mais bravo, ça prouve une fois de plus que tu ne sais pas de quoi tu parles.

        Oracle fut un énorme sponsor de Java, avec ses Network Computers qui devaient remplacer les PCs / Windows / clients lourds : de tous petits ordis, presque des terminaux, pour faire tourner du Java dessus

        petit article de fond : http://www.wired.com/magazine/2009/12/fail_oracle/

        • [^] # Re: Article léger à la rédaction lourde

          Posté par  (site web personnel) . Évalué à 2.

          Certes, j'aurai du. On pourrai amender l'article avec ça.
          Mais je m'intéresse au succès d'un langage, en focalisant la fenêtre sur le comportement du créateur. C'est un choix.

          Autre choix, je ne parle pas du "succès" de java côté embarqué. Il a été important, mais je ne pense pas que c'est cela qui impliqué son hégémonie.
          Je veux dire par là que l'embarqué en Java n'est pas la niche qui a explosé.

          La niche qui a explosé c'est le web et le J2EE.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Article léger à la rédaction lourde

            Posté par  (site web personnel) . Évalué à 1.

            java dans l'embarqué c'est devenu de plus en plus courant,
            sun et maintenant oracle propose différente jvm arm: ARMv6, ARMv7, ARMv7, powerpc, x86, sparc

            certaine vm tourne sous linux, win et solaris

            on est passé d'un marché ou java était peu utilisé alors que maintenant c'est courant

            c'est dispo dans la majorité des téléphones, faut pas oublier les cartes

            faut pas aussi oublier les systèmes qui supporte qu'une partie de l'api java

            par exemple muvium propose des cartes depuis déjà plusieurs année, tout n'est pas supporté mais ça permet de développer beaucoup plus rapidement le tout avec

            il y en as plein d'autre tel que perc, aJile

            par exemple il y a peu, j'ai vu que le logiciel d'un compteur de billet dans une banque tournait sous java

            www.solutions-norenda.com

          • [^] # Re: Article léger à la rédaction lourde

            Posté par  . Évalué à 2.

            Je veux dire par là que l'embarqué en Java n'est pas la niche qui a explosé.

            c'est ben vrai, mais les promesses de Oracle à ce niveau ont eu un impact énorme, le reste de l'industrie non-Microsoft s'est bien fait berner^W^W^Wlaisser convaincre par cet éditeur géant et a cru aux discours et promesses de Sun.

            pour rappel, à l'époque, Sun n'était pas grand chose de plus qu'un éditeur d'UNIX parmi une vingtaine d'autres, il en restait encore plein (qui se souvient de Sequent ?) et on avait diverses plateformes comme RISC qui trainaient

            (allez, viens faire bisou à ma bague Java)

          • [^] # Java sur le web ???

            Posté par  . Évalué à 1.

            Je veux dire par là que l'embarqué en Java n'est pas la niche qui a explosé.

            Il y en a juste eu dans quasiment tous les téléphones portables à un moment (si ce n’est pas toujours le cas : je ne sais pas ce qu’il en est pour les Smartphones)...

            La niche qui a explosé c'est le web

            Ah ah ! Très drôle !
            Je n’ai même pas installé de plugin Java sur ma distrib et je n’ai pas vu la différence !
            Ce qui a eu du succès, sur le web, c’est Javascript, PHP, Flash (malheureusement)...
            Flash a pris la place qu’aurait dû prendre Java.
            Java sur le web, c’est ce que j’appelle un flop magistral, surtout par rapport aux ambitions affichées par Sun à une époque.

            Après en Intranet, peut-être que ça a eu du succès (je n’ai pas d’info d’ordre statistique à ce sujet), en tout cas, c’est bien placé pour ça : pour une application qui interagit avec les bases de données d’une entreprise ou organisme, on a le choix entre :
            – un client « lourd », avec lesquel on doit assurer la compatibilité avec tous les systèmes des machines clientes, le déploiement à chaque nouvelle version (pour chaque client), voire le déploiement de la bibliothèque cliente du SGBD à chaque nouvelle version de celui-ci ;
            – un client Java, pour lequel il suffit de déployer le plugin Java, une seule fois pour tous les clients (avec la contrainte qu’ils doivent tous fonctionner avec la même version).
            Il n’y a pas photo (ça n’a pourtant pas empêché certains de faire le premier choix, quelquefois pour un résultat tellement médiocre qu’on ne voit vraiment pas l’intérêt d’une application native pour arriver à ça).

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

            • [^] # Re: Java sur le web ???

              Posté par  . Évalué à 2.

              Il y a Java web start de pas mal.

              Mais je pense qu'il parlait de JEE (tout comme toi tu as parlé de PHP :) ).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Java sur le web ???

                Posté par  . Évalué à 1.

                Il y a Java web start de pas mal.

                ???
                Ne manquerait-il pas un mot ?

                Mais je pense qu'il parlait de JEE (tout comme toi tu as parlé de PHP :) ).

                Ouais, c’est sûrement pas mal utilisé en intranet (PHP aussi), mais un intranet, pour moi, ce n’est pas le web...
                Sinon, tu vois quoi, comme sites web un peu connus, qui utilisent encore Java (à part java.com...) ?

                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                • [^] # Re: Java sur le web ???

                  Posté par  . Évalué à 2.

                  Il y a Java web start de pas mal.

                  ???
                  Ne manquerait-il pas un mot ?

                  Oui excuse moi. Java web start est pas mal pour rendre accessible une application via le web.

                  Les pages du système de paiment de pixmania.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Java sur le web ???

                    Posté par  . Évalué à 2.

                    Les pages du système de paiment de pixmania sont en JEE.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Java sur le web ???

                  Posté par  (site web personnel) . Évalué à 1.

                  java sur le web tu veux dire quoi?

                  jsp, applet, jsf?

                  ebay fonctionne sur le serveur websphere, c'est quand même pas mal gros

                  www.solutions-norenda.com

                  • [^] # Re: Java sur le web ???

                    Posté par  . Évalué à 1.

                    java sur le web tu veux dire quoi?

                    C’est peut-être ça la bonne question.

                    ebay fonctionne sur le serveur websphere, c'est quand même pas mal gros

                    En gros, Java aurait réussi sur le web... côté serveur (ça se voit moins), faute d’avoir réussi côté client ?

                    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                    • [^] # Re: Java sur le web ???

                      Posté par  (site web personnel) . Évalué à 2.

                      côté client tu as pas grand chose, c'est majoritairement du html tout bête généré via du php, jsp, asp....

                      à part flash, côté client avec un plugin tu as pas grand chose qui a réussi

                      Silverlight, javafx, c'est pas encore ça

                      et le html 5, ça reste encore une blague

                      www.solutions-norenda.com

  • # Langage, lib et JVM

    Posté par  . Évalué à 9.

    Pour moi, Java (le langage) est une version industrielle du C++

    • java possède une spécification complète: tout est spécifié de la taille des types à la stratégie de chargement des modules, en passant par la gestion de la mémoire (initialisations) et les considérations sur l'éxécution concurrente.

    • java possède un meilleur rapport compléxité/puissance: l'ensemble des fonctionnalités fournies par le langage a été soigneusement sélectionné. La grammaire est cohérente. Pas étonnant dès lors qu'on ait des outils d'analyse statique et des IDEs un cran au dessus de ce dont dispose en C++ (firebug est un bon exemple de ce qu'on peut obtenir quand on a un langage analysable et complètement spécifié)

    C'est un langage robuste, cohérent, utilisable par des personnes de niveaux plus ou moins hétérogènes: un langage taillé pour les entreprises, suffisamment proche du C++ pout séduire la population des dév déjà présente à l'époque, sans toutes les incohérences et les manques qui caractérisent ce dernier.

    Java (le langage) est ce qu'aurait dû être le C++

    Ceci dit, en ce qui concerne java, son succès me semble essentiellement dû à deux autres facteurs:

    • l'existence ( C++ [:haha]), la richesse, et la haute qualité de sa bibliothèque standard. Je ne parle même pas de la documentation qui je le rappelle comprend les références (javadoc), les tutoriels, et les documents expliquant comment tel composant est censé être utilisé etc..

    • la JVM. Comme le langage, elle est spécifiée (modèle mémoire, execution concurrente etc..), elle est particulièrement performante vues les fonctionnalité qui doivent être supportées (là-bas au fond, arrêtez de râler sur le GC!). Elle a été faite avec Java en ligne de mire mais elle est en réalité indépendante du langage - seul le byte code compte. Depuis quelques temps, on voit d'ailleurs apparaître pas mal de petits nouveaux (scala, clojure, groovy etc..) A votre avis, pourquoi les concepteurs choisissent la JVM pour les implémenter? On rajoutera à cela que via la JVM, ces langages peuvent intéragir avec du code java, récupérant d'un coup l'accès à toutes les fonctionnalités offertes par la lib standard!

    Bref, Java a été un grand pas en avant du point de vue informatique industrielle (pour des petits/moyens projets avec des devs compétent, c'est moins remarquable), mais ce qui restera sera probablement c'est la JVM et la lib standard

    • [^] # Re: Langage, lib et JVM

      Posté par  (site web personnel) . Évalué à 10.

      Java (le langage) est ce qu'aurait dû être le C++

      Un langage incompatible qui coupe toute compatibilité avec son prédécesseur.
      Tellement fantastique qu'aucun logiciel de bureautique courant ne l'utilise (traitement de texte, tableur, lecteur de mail, retouche d'image, édition vidéo, navigateur, lecteur de musique/vidéo, gestionnaire de fichier...). Mais c'est sûrement parce que les développeurs sont masos, ou alors ils subissent le poids de l'existant, ce qui les empêche d'innover en créant un programme à partir de zéro. Ou alors parce que les gens ont la flemme d'installer une JVM. Ou alors ils ont peur d'Oracle.

      Java n'est meilleur que C++, et inversement. Chacun ses points forts, chacun ses domaines de prédilection.
      Longtemps développeur C++, je suis enchanté par toute ce que m'apporte Java pour le dev: environnement agréable, grosse facilité de débugage, système de build génial, etc... Ce n'est pas pour autant que je veux le voir à toutes les sauces sur mon bureau.

      Conclusion: un bon sujet pour un vendredi.

      • [^] # Re: Langage, lib et JVM

        Posté par  . Évalué à 3.

        Un langage incompatible qui coupe toute compatibilité avec son prédécesseur.

        Ce fut une des grandes réussites et un des fardeaux les plus lourds du C++: d'un côté, il put s'imposer par ce biais, de l'autre... je n'ai pas besoin de t'expliquer ce qu'est devenu ce langage (indice: un fouilli de fonctionalités alambiquées, favorisant l'apparition de gourus et de devs comprenant à moitié ce qu'ils font - ce qui est courant dans l'industrie). Java aussi paye un tribut à la compatibilité ascendante (qui a dit generics?). Je trouve cela tout à fait normal, mais comme il part sur des bases plus saines (le C++ avait montré ce qu'il ne fallait pas faire), ça se passe mieux.

        Tellement fantastique qu'aucun logiciel de bureautique courant ne l'utilise

        C'est tout à fait exact, C++ était là avant, ça serait stupide de tout réimplémenter, et de plus la jvm impose des contraintes qui font que ça n'est pas toujours pertinent de l'utiliser. Heureusement d'ailleurs, sinon cela signifierait que le couple java/jvm est la solution universelle!

        Ce n'est pas pour autant que je veux le voir à toutes les sauces sur mon bureau.

        Sur mon bureau, moi je veux juste des applications qui répondent à mon besoin avec les performances adéquates, quel que soit le langage utilisé pour les coder. Par contre, dans un contexte industriel (gros logiciels, équipes de programmeurs avec des niveaux hétérogènes), et sous réserve bien sûr que les contraintes imposées par la jvm soit acceptables, je n'hésite pas.

      • [^] # Re: Langage, lib et JVM

        Posté par  . Évalué à -1.

        aucun logiciel de bureautique courant ne l'utilise (traitement de texte,

        Et OpenOffice.org alors ?

        • [^] # Re: Langage, lib et JVM

          Posté par  . Évalué à 3.

          Seule une toute petite partie d'OpenOffice est en Java. La plupart du code, c'est du C++.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Langage, lib et JVM

          Posté par  . Évalué à 2.

          Je crois que certains chez LibreOffice aimeraient redéfinir/réduire les dépendances sur java. Ca n'est pas très clair si c'est parce que java c'est Oracle ou si c'est pour des raisons de performances (c'est probablement un peu pour les deux). Certains voudraient même remplacer toutes les boîtes de dialogues qui sont codées en java.
          En tout cas, ça montre bien que l'utilisation d'une JVM n'est pas toujours adéquate, par exemple quand on doit cohabitater avec du runtime externe...

      • [^] # Re: Langage, lib et JVM

        Posté par  . Évalué à 2.

        aucun logiciel de bureautique courant ne l'utilise (traitement de texte, tableur, lecteur de mail, retouche d'image, édition vidéo, navigateur, lecteur de musique/vidéo, gestionnaire de fichier...)

        En effet, peu importe les qualités et défauts de Java, C++ ou n'importe quel autre langage. Tout ce qui compte c'est de choisir celui qui est le mieux adapté au projet.

      • [^] # Re: Langage, lib et JVM

        Posté par  (site web personnel) . Évalué à 1.

        c'est surtout des domaines où c'est pas vraiment le type de programme qui se démarre au 2 semaines....

        suite bureautique: thinkfree
        retouche image: imagej
        édition vidéo: FORscene
        lecteur de musique: jlGui
        navigateur: Lobo
        explorateur de fichier: Java File Manager, Capivara, mucommander

        j'ai perdu le lien d'un site qui énumérait une panoplie de programme java dans différent domaine..... si quelqu'un en connait un...

        www.solutions-norenda.com

    • [^] # Re: Langage, lib et JVM

      Posté par  . Évalué à 1.

      java possède une spécification complète: tout est spécifié de la taille des types à la stratégie de chargement des modules, en passant par la gestion de la mémoire (initialisations) et les considérations sur l'éxécution concurrente.

      Qu'est ce qui n'est pas spécifié en c++? C'est une vrai question, je veux bien te croire, et ce serai intéressant d'avoir plus d'infos

      java possède un meilleur rapport compléxité/puissance: l'ensemble des fonctionnalités fournies par le langage a été soigneusement sélectionné. La grammaire est cohérente. Pas étonnant dès lors qu'on ait des outils d'analyse statique et des IDEs un cran au dessus de ce dont dispose en C++ (firebug est un bon exemple de ce qu'on peut obtenir quand on a un langage analysable et complètement spécifié)

      La je suis plus sceptique. Qu'est ce que la complexité d'un langage?
      Est ce que tu veux dire que entre java et C++ un est plus puissant que l'autre?
      Qu'est ce que la cohérence d'une grammaire?
      Qu'est ce que les analyseurs syntaxiques Java font de mieux et qu'est ce qui manque à la spec de C++ pour en faire autant? (cette dernière question rejoins le paragraphe précédent).
      Ça fait beaucoup de question mais c'est pour clarifier : tu balances pleins d'affirmations ambiguës qui veulent pas dire grand chose.

      • [^] # Re: Langage, lib et JVM

        Posté par  (site web personnel) . Évalué à 1.

        Qu'est ce qui n'est pas spécifié en c++? C'est une vrai question, je veux bien te croire, et ce serai intéressant d'avoir plus d'infos

        Example : un "int" c'est minimum 16 bits. la spec ne dit pas le maximum. Du coup, suivant l'OS (c'est plus lié à l'OS qu'au compilo), un int peut être 16 bits (sur les CPU 16 bits qu'on ne voit plus de nos jours), 32 bits (classique), ou 64 bits (sur certains OS 64 bits, mais pas tous). un "long" est minimum 32 bits, la spec ne dit pas de maximum, ça peut être 64 bits sur un OS 64 bit, ou... Pas.
        http://en.wikipedia.org/wiki/C_variable_types_and_declarations#Size
        http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models

        C'est une des conneries historiques du C, à trop vouloir être proche du CPU. Bon, ils ont corrigé le tir maintenant, la spec actuelle spécifie des int8_t, int16_t, int32_t, int64_t, mais tout les compilos ne sont pas à jour, et la fainéantise fait qu'on écrit plus facilement int que int32_t.

        (bon, j'espère que cette fois-ci, je n'aurai pas écrit une connerie sur la spec C...)

        • [^] # Re: Langage, lib et JVM

          Posté par  . Évalué à 3.

          un "int" c'est minimum 16 bits

          Il n'y a même pas forcément 16 bits d'information utile car la norme ne demande de pouvoir représenter que 65535 valeurs (complément à 1 etc.).

          C'est une des conneries historiques du C, à trop vouloir être proche du CPU.

          La connerie selon moi c'était de ne proposer que des types de taille indéterminée sans les types C99 (mais bon, imposer la taille ça demande déjà d'imposer le complément à 2, ou sinon ça devient très douteux). Avoir un type int qu'on peut utiliser quand on s'en fout de la taille exacte, ça me semble être une bonne idée.

        • [^] # Re: Langage, lib et JVM

          Posté par  . Évalué à 4.

          C'est une des conneries historiques du C, à trop vouloir être proche du CPU.

          C'est, à mon avis, une des raisons de son succès. Ça a permit d'avoir du C facilement sur presque n'importe quelle architecture.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Langage, lib et JVM

          Posté par  . Évalué à 1.

          pfft. regarde n'importe quel bout de code sérieux en C ou C++ depuis 20 ou 30 ans, on n'a pas attendu la fin du siècle pour se définir des types avec des longueurs explicites et des tests pour vérifier qu'ils se comportent correctement une fois compilés

          • [^] # Re: Langage, lib et JVM

            Posté par  (site web personnel) . Évalué à 3.

            En fait, toutes les critiques sur le langage C/C++ peuvent être enlevé en ajoutant du code (limits.h est ton ami), oui. Mais c'est mieux si c'est dans la spec.

            • [^] # Re: Langage, lib et JVM

              Posté par  . Évalué à 3.

              mouaif, alors faut dire que y'avait pas de spec, surtout, juste le K&R et ce que tu pouvais faire tourner sur ta plateforme (souvent bien pouilleux et buggé), puis une norme pondue très tard, en 89-90 et donc on reste juste 10 ans sans ces nouveaux types mieux normés

      • [^] # Re: Langage, lib et JVM

        Posté par  . Évalué à 1.

        Qu'est ce qui n'est pas spécifié en c++? C'est une vrai question, je veux bien te croire, et ce serai intéressant d'avoir plus d'infos

        Concernant cette question j'ai déjà donnés des exemples, d'ailleurs tu les cites toi-même dans ton post :-)

        La je suis plus sceptique. Qu'est ce que la complexité d'un langage?
        Est ce que tu veux dire que entre java et C++ un est plus puissant que l'autre?
        Qu'est ce que la cohérence d'une grammaire?
        Qu'est ce que les analyseurs syntaxiques Java font de mieux et qu'est ce qui manque à la spec de C++ pour en faire autant? (cette dernière question rejoins le paragraphe précédent).

        Complexité d'un langage: tu as souvent de bon indices en rerdant la taille sa spécification, de sa grammaire. Sans parler du nombre de possibilités offertes par un langage. Car il ne faut pas oublier que chaque fois que tu introduis de nouvelles constructions, il faut qu'il n'y ait pas de conflits avec les fonctionnalités existantes.

        Qu'est ce qui manque à la spec de C++ pour en faire autant?
        Hmm, url
        "C++ grammar is ambiguous, context-dependent and potentially requires infinite lookahead to resolve some ambiguities"

        tu balances pleins d'affirmations ambiguës qui veulent pas dire grand chose.

        Ca n'est pas parce que tu ne comprends pas ce que j'écris que ça ne veut rien dire ;-)

        • [^] # Re: Langage, lib et JVM

          Posté par  . Évalué à -1.

          Qu'est ce qui manque à la spec de C++ pour en faire autant?
          Hmm, url
          "C++ grammar is ambiguous, context-dependent and potentially requires infinite lookahead to resolve some ambiguities"

          Heu oui la grammaire du C++ est pourrie pour faire de l'analyse syntaxique en temps raisonnable. Rien à voir avec des manques dans la spec... (je dit pas qu'il n'y en a pas, juste que ça a rien à voir avec les propriétés de la grammaire. Demain je peux très bien créer un langage avec une grammaire générale en spécifiant tout ce que tu veux, tu l'analysera pas en temps raisonnable)

          Complexité d'un langage: tu as souvent de bon indices en rerdant la taille sa spécification, de sa grammaire. Sans parler du nombre de possibilités offertes par un langage. Car il ne faut pas oublier que chaque fois que tu introduis de nouvelles constructions, il faut qu'il n'y ait pas de conflits avec les fonctionnalités existantes.

          Ça m'indique toujours pas ce qu'est la complexité du langage, ni comment la quantifier.Je vais avoir du mal à déterminer un rapport complexité/puissance avec cette définition(qui sort d'ou?). Par ailleurs je vois pas pourquoi tu mets en relation la complexité et la puissance, surtout que la puissance de calcul de tous les langages de programmation Turing-complet est la même, donc ça sert à rien de la mettre dans ton ratio.
          (si c'est bien ce que tu veux dire par "puissance", encore un point à clarifier. Si tu parles de la puissance d’expressivité, elle est inférieur pour les grammaires hors-contexte par rapport au grammaires sous-contexte, et tu m'as montré que la grammaire du C++ était sous-contexte...)
          Sinon j'ai beau chercher je sais toujours pas ce qu'est la propriété de cohérence d'une grammaire (cela dit j'ai peut être mal cherché je ne suis pas expert des langages et grammaires formelles).

          Ca n'est pas parce que tu ne comprends pas ce que j'écris que ça ne veut rien dire

          Certes, mais la on dirait plutôt que tu utilises des mots avec le sens qu'ils t'inspirent plutôt qu'avec leur véritable définition ce qui donne un truc réellement incompréhensible.

          • [^] # Re: Langage, lib et JVM

            Posté par  . Évalué à 1.

            Mon propos porte sur des considérations pragmatiques, je ne discute pas sur des propriétés théoriques.

            Je m'explique: ca n'est donc pas la peine d'essayer de coller des définitions théoriques sur les termes que j'emplois comme tu t'escrimes à le faire, tu ne comprendras effectivement pas ce que j'écris (je n'utilise pas "complexité" au sens "complexité algorithmique", "complet" n'a rien à voir avec "NP-complet" ou autres choses, quant à "puissance" ça aurait dû te mettre sur la voie car je ne suis pas au courant d'une telle définition)

            Mon opinion est que d'un point de vue pragmatique Java possède un meilleur rapport complexité/puissance que C++ entre autres parce qu'il moins expressif (élimination des fonctionnalités ésothériques ou trop difficiles à maitriser) tout en répondant aux besoins de conception d'une application. Au risque de sembler lourd, je rappelle que je parle de qualités désirables dans un contexte industriel, pour lequel il faut tenir compte de certains paramètres que j'ai déjà mentionnés

      • [^] # Re: Langage, lib et JVM

        Posté par  (site web personnel) . Évalué à 2.

        Qu'est ce qui n'est pas spécifié en c++?

        Tout ce qui concerne les threads et les DLLs: ordre des accès en mémoire, initialisation des variables statiques, noms des fonctions générées par le compilo...

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Langage, lib et JVM

          Posté par  (site web personnel, Mastodon) . Évalué à 0.

          C'est quoi une DLL ? :o) Plus sérieusement, c'est le genre de fonctionnalité qui peut être soumis à débat dans la spécification d'un langage. Ainsi que les threads, les IPC, etc.

          L'initialisation des variables statiques est défini par la norme : au choix de l'implémentation :D La taille des types est définie, elle n'est pas bornée, c'est tout.

    • [^] # Re: Langage, lib et JVM

      Posté par  (site web personnel) . Évalué à 2.

      Merci, enfin un commentaire dans le sujet :-)

      Je pense que tu analyses très bien les déterminants techniques qui ont fait le succès de Java. Ce serait très intéressant d'intégrer ton analyse à cet article :-)
      Ce serait intéressant de le confronter à l'analyse de R.P. Gabriel, dont je parlerai un de ces jours.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Le développeur C++ a le temps de basher Java

    Posté par  (site web personnel) . Évalué à 2.

    Les temps de compilation interminables et les greps de logs de 3Go parce qu'il n'y a pas de pile d'appel correcte, ça laisse du temps pour troller!

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Popularité des langages

    Posté par  . Évalué à 1.

    Le site http://langpop.com/ présente des chiffres intéressants sur la popularité des langages.

    Pour compléter, n'oublions pas que java, pour des raisons qui m'échappent, a plus de succès en France que dans d'autres pays, en particulier aux USA où le C++ lui est largement préféré.

    • [^] # Re: Popularité des langages

      Posté par  . Évalué à 9.

      Pour compléter, n'oublions pas que java, pour des raisons qui m'échappent, a plus de succès en France que dans d'autres pays, en particulier aux USA où le C++ lui est largement préféré.

      Prédominance des SSII qui pratiquent le nivelage par le bas et l'uniformisation culturelle ?
      (juste une hypothèse... en tout cas je ne crois pas que l'explication soit technique)

      • [^] # Re: Popularité des langages

        Posté par  . Évalué à 4.

        Les SSII seraient donc plus présentes en France qu'aux États-Unis ?

        • [^] # Re: Popularité des langages

          Posté par  . Évalué à 9.

          Il me semble qu'en raison de la législation du travail c'est le cas. Quel est l’intérêt de passer par une SSII qui te fournie un développeur moyen grâce à un CV bidonné si tu peux embaucher toi-même et licencier quand tu as une baisse de charge ?

          Étienne

          • [^] # Re: Popularité des langages

            Posté par  . Évalué à 1.

            Parce que la plupart du temps ce n'est pas un développeur pour qui fait un logiciel, mais une équipe avec des métiers spécifiques (architecte, DBA, designer, etc) et que tu n'a pas envi de te coltiner la gestion de projet qui va avec, parce que si les SSII se font berné par des CV bidonnés je vois pas pourquoi, une entreprise qui n'y connait pas forcément grand chose s'en sortira mieux,…

            un développeur moyen grâce à un CV bidonné

            C'est vrai que tout le monde sait que 98% des développeurs ni connaissent rien, sont des bars cassés qui ne sont là que pour le fric, qui ne savent pas apprendre et passent leur temps à s'emmerder à corriger les erreurs qu'ils ont eux même fait, … Humm. Si tout le monde était aussi bon que moi … ؟

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Popularité des langages

              Posté par  (site web personnel) . Évalué à 9.

              si les SSII se font berné par des CV bidonnés je vois pas pourquoi, une entreprise qui n'y connait pas forcément grand chose s'en sortira mieux

              Euh non, ce sont les SSII qui bernent les entreprises en bidonnant des CVs, c'est même leur cœur de métier.

              • [^] # Re: Popularité des langages

                Posté par  . Évalué à 0.

                Tu sais qu'elles ne travaillent pas qu'en régit, elles peuvent aussi travailler au forfait.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Popularité des langages

            Posté par  . Évalué à 2.

            Il y a aussi l'intérêt que les lignes budgétaires ne sont pas les mêmes.
            Pour certains gros projets cela a un impact fort.

    • [^] # Re: Popularité des langages

      Posté par  (site web personnel) . Évalué à 3.

      totalement faux, n'importe quel site concernant la recherche d'emploi le prouve au usa

      www.solutions-norenda.com

  • # Logique

    Posté par  (site web personnel) . Évalué à 7.

    Si tout le temps et l'énergie qui ont été consacrés à ce troll – et tous les autres – avaient été mis à la réalisation d'un projet open-source comme HURD, on aurait déjà une version stable.

    • [^] # Re: Logique

      Posté par  . Évalué à 3.

      Si le projet est programmé de la même façon que les trolls sont pondus, on aurait une version qui ne ressemble à rien.

    • [^] # Re: Logique

      Posté par  . Évalué à 4.

      Et un HURD écrit en Java ?

      Je pense qu'on a un fort potentiel là...

  • # Fruste

    Posté par  . Évalué à 0.

    Attention : c'est le mot "Fruste" et pas "Frustre", et ce mot (je viens de l'apprendre) est lui-même utilisé à tort.

    Je recopie un bout de la définition de l'académie : C'est d'une façon tout à fait incorrecte que quelques-uns emploient ce mot dans le sens de Rude, inculte, grossier, qui est un contresens, et disent Manières frustes, un homme fruste, ce qui signifie en réalité le contraire de ce qu'on veut dire.

    • [^] # Re: Fruste

      Posté par  . Évalué à 3.

      Définition qui sort d’un dictionnaire de 1935, la huitième édition. Je suis sûr qu’avec un peu plus d’effort tu dois pouvoir ressortir un dictionnaire en vieux français et en déduire que son texte est incompréhensible :)

      Voici la définition qui nous intéresse, de la neuvième édition :
      3. Fig. Qui manque d'éducation, de finesse ; rude, inculte, mal dégrossi. Homme fruste. Des manières frustes. Langage fruste. À ne pas confondre avec Rustre, qui est sans doute à l'origine de ce sens, et a même inspiré la forme fautive Frustre.

      La forme fautive est devenue courante et acceptée. Bienvenue en 2011 :)

      Personnellement je ne vois pas en quoi la forme est fautive, la définition de la huitième correspond bien à l’image que j’ai d’un homme frustre (avec un léger glissement de sens peut-être). Ou alors on considère comme fautives toute métaphore et image… /o\

  • # heu ...

    Posté par  . Évalué à 3.

    dépêche globalement intéressante, mais :

    La POO a le potentiel d'être beaucoup moins complexe que la programmation procédurale, car plus proche de l'expérience humaine qui manipule des objets dans sa vie quotidienne,

    je suis le seul à trouver que les deux affirmations dans cet extrait sont très discutables ?

    Certes, on utilise le même mot, mais les objets qu'on manipule dans la vie me semblent avoir un rapport assez lointain avec les objets en POO. Il ne faut pas non plus oublier que les langages objet donnent principalement des facilités syntaxiques pour mettre en oeuvre une certaine forme de modularité, mais ne sont pas les supports exclusives d'une approche modulaire type objet.

    Quant à la complexité, bon ... pattern visitor ?

    • [^] # Re: heu ...

      Posté par  (site web personnel) . Évalué à 2.

      Ceci est un appeau à Troll
      Cela dit, Alan Key, lorsqu'il a inventé SmallTalk avait clairement cette idée en tête (la flemme de chercher des sources, je vais me coucher).

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: heu ...

        Posté par  . Évalué à 2.

        Ceci est un appeau à Troll

        pour la dernière phrase, peut-être un peu, mais sur le reste non.

        J'ai en fait raté d'autres éléments de la phrase que je soulignais, l'implication "plus près de l'expérience humaine" => "potentiellement moins complexe que l'approche procédurale". En dehors du fait que le lien logique ne me parait pas établi, le mot "potentiel" laisse en fait beaucoup de marge d'interprétation.

        A mon sens, l'approche objet est une autre façon d'aborder ce qu'on appelait "modularité" auparavant. Évidemment, il n'est pas question de remettre en cause l'intérêt de la modularisation dans la conception et le développement, mais d'interroger l'affirmation selon laquelle la POO serait moins complexe que l'approche procédurale. En fait, la question est de savoir dans quelle mesure le "potentiel" cité ci dessus est réalisé.
        Franchement, au vu des questions fleurissant dans les forums sur les problématiques purement objet, il me semble qu'on peut se poser la question.
        On notera aussi que par rapport au C++ (qui reste un langage emblématique de la POO), Java a supprimé certains concepts et en a simplifié d'autres. Quelles sont les raisons de ces choix conceptuels ? Il me semble que c'était la trop grande complexité de certains concepts, ce qui tendrait à indiquer que l'approche objet est pas si évidente que ça.

        L'approche objet est utile, voire même agréable dans certains cas, mais, à mon avis, la qualité de l'architecture du code et de la modélisation de structures/base de données/objets dépendent plus des qualités d'abstractions des concepteurs/développeurs que des facilités des différents langages. Pour le dire autrement, le langage vient dans un second temps et permet l'implémentation plus ou moins rapide de telle ou telle approche, mais n'est pas un élément déterminant : un bon langage ne débouche pas forcément sur des bons programmes, une bonne approche ne fait pas forcément des bons développeurs. (oui, bon, là, j'enfonce un peu des portes ouvertes ... :)

        • [^] # Re: heu ...

          Posté par  . Évalué à 2.

          Franchement, au vu des questions fleurissant dans les forums sur les problématiques purement objet, il me semble qu'on peut se poser la question.

          Est-ce ces questions fleurissement à propos des "problématiques purement objet", ou leur implémentation dans des langages lourdingues type Java/C++ ?

          C++ (qui reste un langage emblématique de la POO)

          Heu, pas vraiment, C++ est un hybride entre C et le début d'un langage orienté objet, c'est surtout un fourre-tout incroyable de paradigmes de programmation dont aucun ne semble implémenté de façon aboutie.

          Ensuite, l'« approche objet » n'est pas quelque chose de codé dans le marbre, la programmation est avant tout une discipline pragmatique et chaque langage (ou plutôt son concepteur :-)) fait le choix des primitives fournies au programmeur en fonction d'objectifs concrets.

          la qualité de l'architecture du code et de la modélisation de structures/base de données/objets dépendent plus des qualités d'abstractions des concepteurs/développeurs que des facilités des différents langages

          On peut certes discuter des contributions relatives des différents facteurs que tu cites, mais cela ne revient pas à prouver que le choix d'un langage n'a pas d'importance.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.