Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 94 sur 95 PremièrePremière ... 4484909192939495 DernièreDernière
Affichage des résultats 1 861 à 1 880 sur 1887

Discussion: [Débat] C++ vs Java

  1. #1861
    Membre confirmé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 288
    Points
    288

    Par défaut

    Citation Envoyé par Luc Hermitte Voir le message
    La main-mise à laquelle je faisais allusion o. Un des meilleurs en termes d'optimisation même pour le C++. Est-ce que s'engager vers la voie C++ aurait été faire le jeu de microsoft ? Je n'en suis pas sûr.
    La question, il faut la poser a James Gosling (http://en.wikipedia.org/wiki/Oak_%28...ng_language%29) qui a inventé un nouveau langage parce que le C++ ne répondait pas a ses besoins. Ne pas oublier que le C++ n'est que la conséquence des besoins de l'époque de POO dont l'approche existait bien avant lui (et je m'y étais essayé en C ...). Force est de constater que le C++ n'a pas satisfait les attentes de l'époque, sinon, Java n'aurait jamais existé.

  2. #1862
    Expert Confirmé Sénior
    Avatar de Luc Hermitte
    Homme Profil pro Luc Hermitte
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    4 700
    Détails du profil
    Informations personnelles :
    Nom : Homme Luc Hermitte
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 4 700
    Points : 6 992
    Points
    6 992

    Par défaut

    Je ne parle pas d'une personne qui pond un nouveau langage (il y en a à la pelle, et ça tous les jours), mais d'une société qui investit de façon conséquente dans un nouveau langage et non dans le procédé de standardisation d'un langage international d'une certaine façon (comme le I de ISO l'indique).
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média.

  3. #1863
    Membre confirmé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 288
    Points
    288

    Par défaut

    Citation Envoyé par Luc Hermitte Voir le message
    Je ne parle pas d'une personne qui pond un nouveau langage (il y en a à la pelle, et ça tous les jours), mais d'une société qui investit de façon conséquente dans un nouveau langage et non dans le procédé de standardisation d'un langage international d'une certaine façon (comme le I de ISO l'indique).
    Tu m'as mal lu ou alors je me suis mal exprimé. J'écrivais que les raisons qui ont fait que l'équipe de Sun a travaillé sur une autre approche avaient du sens au delà de leur simple projet. Oak a d'ailleurs été abandonné, mais repris pour un autre projet chez Sun autour du web, ce n'est qu'à ce moment là que les "dirigeants" de Sun (qui se trouvaient être aussi très techniques ...) ont vu le potentiel de la technologie et décidé de la pousser.

    J'ai évalué pour la première fois Java, il venait de passer en 1.0.2 (), donc dans les années 96/97 je suppose, je peux te dire qu'a l'époque c'était bien timide et même "gadget". C'est bien parce que Java a eu du succès, trouvant application au delà des plans initiaux de Sun qu'il est devenu ce qu'il est et que Sun a investi de plus en plus.

  4. #1864
    Membre Expert Avatar de alexrtz
    Inscrit en
    juin 2003
    Messages
    635
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : juin 2003
    Messages : 635
    Points : 1 047
    Points
    1 047

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    quand ça n'était pas l'ouvrir tout simplement : Linus Torwald a créé Linux parce que de 93 à 95 m$ ne livrait que des machines soudées, où on ne pouvait accèder à rien de l'interne
    Linus Torvalds a commencé à écrire Freax (qui deviendra Linux) en 1991 comme un passe-temps pour comprendre comment fonctionnait sa machine.

    Il a effectivement acheté une machine en pièces détachées mais il faisait déjà tourner un OS dessus (Minix).
    "Je suis incapable d'expliquer ce qui se passa ensuite : je lâchai quelque chose, quelque chose à quoi je m'agrippais depuis toujours sans m'en rendre compte. Je m'enfonçais dans une obscurité chaude, moelleuse et protectrice, tandis qu'un loup montait la garde par mes propres yeux."

  5. #1865
    Modérateur
    Avatar de Nemek
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 068
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 068
    Points : 4 211
    Points
    4 211

    Par défaut

    Le JCP a tout de même son gros effet pervers : le lobbying.

    Jusqu'à récemment, il n'était constitué que d'industriel qui crééait surtout des JSRs pour mettre en avant leur propre produit. Car il y a une chose qui très forte mais qui créé tout le lobbying, toute JSR doit être accompagnée d'une implémentation.
    On en veut pour preuve le problème avec Jigsaw/OSGi, Closure/Lamba Expression/etc, ou même l'API de cache de Red Hat...

    Ensuite avoir un comité de pilotage implique une forte lenteur des changements puisqu'il faut que la moitié des membres aillent dans le même sens. Le langage n'évolue pas énormément, malgré toute l'envie qu'il y a de toute part (utilisateurs, JUG leaders, industriels, etc.). On voit bien de nouvelles fonctionnalités s'ajouter mais peu de choses en place qui évolue.

    Un autre point noir pour Java et une des fameuses règles qui finira sûrement par tuer Java si elle n'est pas brisée d'ici les 2-3 prochaines versions majeurs : la rétrocompatibilité binaire. La règle qui tue tout, comme avoir des génériques uniquement "compile-time". Aucun intérêt puisque la compatibilité de l'API n'est pas garantie.

    Concernant l'investissement de Sun dans Java, il ne faut pas oublié qu'une part importante des développeurs et des technologies intégrés dans Java ne sont pas de Sun mais d'Apache, IBM, Xerox, Red Hat et autres.


    Aujourd'hui la seule force de Java c'est d'avoir été là et relativement bon avec une courbe d'apprentissage très rapide au moment de la bulle Internet. Tout comme COBOL dans les années 70-80. Franchement, il y a un paquet de langage que je préfère à Java. Cependant Java n'a aucune niche, donc il est voué à mourir s'il ne se met pas au niveau de langage plus évolué. Ou alors l'avenir se jouera sur des langages alternatifs comme Groovy et Scala. Comme C# l'a été pour la plateforme Microsoft en remplacement de VB et C++.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  6. #1866
    Expert Confirmé Avatar de jabbounet
    Homme Profil pro frederic frances
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 905
    Détails du profil
    Informations personnelles :
    Nom : Homme frederic frances
    Âge : 38

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 905
    Points : 2 681
    Points
    2 681

    Par défaut

    En parlant de jsr, a une époque j'ai bossé sur la validation d'une implémentation faite par un client de la jsr-043 (il y'a 2 ans environ), nous n'avions pas accès au code juste à l'api ainsi que la doc de l'api.

    Cette jsr en particulier c'est un beau paquet de nouille, (je ne sais pas si les autres jsr sont comme ça, il y'en a certainement qui sont claire et bien faite)

    par exemple à certains endroit il y'a de jolies contradictions sur les comportements de l'api qui font que le système pouvait selon les interprétation se retrouver dans des états différent pour un même use case (selon l'interprétation de l'importance de certaines règles par rapport à d'autres).

    je ne compte pas non plus les points trop vagues qui fait que parfois ou ne peut pas savoir ce que fait l'api, par exemple dans certaines fonctionnalités type conférence/renvoi d'appel, il n'etait simplement pas possible de savoir ce qu'il se passe pour l'appel si le correspondant n’était pas joignable....

    je pense que pour toute normalisation, quelque soit le langage, il est important d'avoir de bon comité de relecture et de bien suivre les cycles de type auteur/lecteur, d'avoir des gens avec un peu de bouteille dans le domaine et de vérifier que les chose sont réalisable sans ambiguïtés (ce n'est pas forcément simple, mais bon)
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  7. #1867
    Membre confirmé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 288
    Points
    288

    Par défaut

    Citation Envoyé par Nemek Voir le message
    Le JCP a tout de même son gros effet pervers : le lobbying.
    Il en a un autre, celui de nous pondre des usines a gaz, d'où les échecs relatifs des EJB par exemple (vs les ORM). On peut constater que la dynamique initiale de Java qui se voulait "simple" ait pris sérieusement du plomb dans l'aile.

    Citation Envoyé par Nemek Voir le message
    Aujourd'hui la seule force de Java c'est d'avoir été là et relativement bon avec une courbe d'apprentissage très rapide au moment de la bulle Internet.
    Pas d'accord :-), d'où mon commentaire plus haut, il avait des caractéristiques ou au minimum des objectifs qui répondaient aux besoins de l'internet client et serveur: sécurité, portabilité ... portabilité qui couvraient des besoins bien plus riches que les autres langages de l'époque (UI, couche http par exemple)

    Citation Envoyé par Nemek Voir le message
    ... Java n'a aucune niche, donc il est voué à mourir s'il ne se met pas au niveau ...
    Pas tout a fait d'accord ... je ne pense pas que Java, pas plus que le C aujourd'hui par exemple, disparaisse. Par contre, tout comme le C, il sera utilisé pour des besoins précis, ceux proches de l'architecture web par exemple.

    Ca rejoint finalement ce que tu dis, dans quelques temps, on aura a disposition un ensemble d'outils, de composants ... codés "en usine" en java (ou autre!) que l'on utilisera avec d'autres langages "de glue". Plus l'informatique avance et plus elle devient un métier d'assemblage que de construction "from scratch" suivant une évolution similaire a celle qu'a pu connaître l'électronique il y a quelques années où on fait d'abord son marché de composants plus que de concevoir son typo et aller acheter du perchlorure de fer

  8. #1868
    Modérateur
    Avatar de Nemek
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 068
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 068
    Points : 4 211
    Points
    4 211

    Par défaut

    Citation Envoyé par jabbounet Voir le message
    je pense que pour toute normalisation, quelque soit le langage, il est important d'avoir de bon comité de relecture et de bien suivre les cycles de type auteur/lecteur, d'avoir des gens avec un peu de bouteille dans le domaine et de vérifier que les chose sont réalisable sans ambiguïtés (ce n'est pas forcément simple, mais bon)
    Je ne sais pas si c'était le cas à l'époque de cette activité mais en tout cas désormais tout le monde peut être relecteur / critique / auteur / etc sur une JSR. Le problème c'est qu'il faut arriver avant la finalisation du draft. Sinon je ne sais pas s'il est possible à n'importe qui d'initialiser une nouvelle version mais tu peux toujours proposer ;-)

    Citation Envoyé par rimram31 Voir le message
    Il en a un autre, celui de nous pondre des usines a gaz, d'où les échecs relatifs des EJB par exemple (vs les ORM). On peut constater que la dynamique initiale de Java qui se voulait "simple" ait pris sérieusement du plomb dans l'aile.
    Les EJBs s'améliorent de version en version. Cependant je n'ai jamais trop pratiqué mais je me souvient bien d'un TP où on a passé 4h à essayer de créer un descripteur de déploiement avec l'interface Swing ... Un cauchemar.

    Citation Envoyé par rimram31 Voir le message
    Pas d'accord :-), d'où mon commentaire plus haut, il avait des caractéristiques ou au minimum des objectifs qui répondaient aux besoins de l'internet client et serveur: sécurité, portabilité ... portabilité qui couvraient des besoins bien plus riches que les autres langages de l'époque (UI, couche http par exemple)
    Je vois pas trop en quoi avoir une couche serveur (HTTP, FTP ou n'importe quoi) de portable soit un réel avantage stratégique. Les serveurs sont toujours installés sur des environnements similaires voir exactement identiques.
    En revanche, j'admet que d'avoir une API standard aide bien. C'est d'ailleurs le premier truc qui m'avait attiré vers Java. Mais ca rejoint l'idée de la "coube d'apprentissage", tu apprends le langage et son API et "tu sais tout".
    Pour le "à l'époque", je ne saurais dire, j'ai commencé à apprendre Java qu'en 2003. Et n'ai commencé à l'utiliser de manière industrielle qu'en 2008 pour de l'embarqué et en 2009 pour du web.

    Citation Envoyé par rimram31 Voir le message
    Pas tout a fait d'accord ... je ne pense pas que Java, pas plus que le C aujourd'hui par exemple, disparaisse. Par contre, tout comme le C, il sera utilisé pour des besoins précis, ceux proches de l'architecture web par exemple.
    Disparaître non mais mourir si, tout comme le COBOL.
    En gros il sera remplacé au fur et à mesure par une autre technologie, type Ruby. Java n'offre vraiment rien de particulier.

    Aujourd'hui Java ne doit sa vie qu'à la masse de projet en maintenance, qui fait que la compétence est fortement maintenue et donc également indispensable pour les nouveaux projets. C'est un cercle vertueux mais qui finira sûrement pas s'éteindre si on ne met pas de nouvelles bûches dans le feu.
    C'est pourquoi je crois que l'avenir de Java se joue dans les langages alternatifs (particulièrement Scala) et une rupture de la rétrocompatibilité (genre Java 9 incompatible avec les précédentes mais Java 10 compatible avec la précédente).
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  9. #1869
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    Citation Envoyé par Nemek Voir le message
    En revanche, j'admet que d'avoir une API standard aide bien. C'est d'ailleurs le premier truc qui m'avait attiré vers Java. Mais ca rejoint l'idée de la "coube d'apprentissage", tu apprends le langage et son API et "tu sais tout".
    C'est surtout que c'était le but initial

    Au départ, comme déjà mentionné, ce n'était pas fait pour faire autre chose que des API standards, pour pallier au refus par M$ d'implémenter X11...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  10. #1870
    Membre confirmé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 288
    Points
    288

    Par défaut

    Citation Envoyé par Nemek Voir le message
    ... Je vois pas trop en quoi avoir une couche serveur (HTTP, FTP ou n'importe quoi) de portable soit un réel avantage stratégique...
    Ben il faut regarder ce qu'offrait un JDK, je ne sais pas aujourd'hui, mais au début des années 2000, avoir l'équivalent dans une autre techno demandait d'y ajouter une bonne douzaine de librairies supplémentaires qui n'auraient pas été les mêmes selon les environnements: ici HP, là bas Sun, encore ailleurs IBM ou tartampion ... et tout ça parfois pour gérer une simple liste. Tu y ajoutes le JSDK pour le serveur web, JDBC, le support du multi threading et tu avais "tout ce dont on peut avoir besoin" pour faire du développement serveur. Je me souviens avoir codé un serveur multi clients à l'époque en moins d'une journée, inimaginable a l'époque dans un autre langage.

    Je m'aperçois d'ailleurs, ne faisant plus trop de java, que c'est encore le cas aujourd'hui dans d'autres technos où tu as dix mille façons différentes de faire la même chose et qui marchent pas toujours selon l'environnement.

  11. #1871
    Membre régulier
    Profil pro Laurent Duroisin
    Inscrit en
    janvier 2010
    Messages
    311
    Détails du profil
    Informations personnelles :
    Nom : Laurent Duroisin

    Informations forums :
    Inscription : janvier 2010
    Messages : 311
    Points : 90
    Points
    90

    Par défaut

    Bah maintenant les choses ont changé, il est devenu plus facile de développez des applications en c++ avec une base de donnée grâce à certains framework comme par exemple Qt, mais c'est sûr que ça ne dépassera pas des technologies comme par exemple JEE qui dans le cadre du développement web nous facilite grandement la tâche.

    Cependant j'ai toujours trouvé le c++ meilleur dans le développement de jeux vidéos, grâce à sa flexibilité.

    En java j'ai souvent eu affaire à des conflit entre la jvm et différentes applis. (Je parle surtout au niveau des accès concurrents)

    De plus le java est un language de programmation plus lent. (même si ça a tendance à devenir de moins en moins important aujourd'hui vu la puissance des machines actuelle il faut quand même souligner l'impossibilité de faire des fonctions inline en java, l'impossibilité d'utiliser des pointeurs, l'obligation d'utiliser des mutex à certains endroit et ce genre de chose)

    Bref le langage java est plutôt un langage utilisé pour les applications qui ne requiers pas d'avoir des performances énormes..., et puis bon après avoir développé des applications opengl en java et en c++, je trouve que c'est quand même moins galère de le faire en c++.

    De plus avec les nouveaux idiomes inclus dans la nouvelle norme du standard c++11, la gestion de la mémoire devient de plus en plus facile.

    Donc je suis plutôt du côté du langage c++. (Plus flexible, plus rapide, et devenu beaucoup plus simple à appréhender grâce aux nouvelles librairies multiplateformes et au nouveau standard c++11)

    Je trouve que c'est devenu plus simple encore que le langage java.

  12. #1872
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 211
    Points : 19 183
    Points
    19 183

    Par défaut

    Citation Envoyé par Lolilolight Voir le message
    il faut quand même souligner l'impossibilité de faire des fonctions inline en java
    Il n'y a pas de mot-clef inline, mais cela ne veut pas dire que les méthodes ne sont pas inliné !
    Au contraire c'est gérer automatiquement par la JVM !
    Peut-être même plus qu'en C++ car la JVM peut même inliner des méthodes virtuelles (quitte à revenir en arrière si besoin).


    Citation Envoyé par Lolilolight Voir le message
    l'impossibilité d'utiliser des pointeurs
    A quel niveau ? Pour de l’arithmétique de pointeur ?
    Parce que pour le reste il n'y a pas de grosse différence entre un pointeur et une référence (si ce n'est que cette dernière est sécurisé).

    Citation Envoyé par Lolilolight Voir le message
    l'obligation d'utiliser des mutex à certains endroit et ce genre de chose
    C'est à dire ?

    Citation Envoyé par Lolilolight Voir le message
    Bref le langage java est plutôt un langage utilisé pour les applications qui ne requiers pas d'avoir des performances énormes...
    Cela dépend de ce que tu entends par performances.
    Si c'est du rendu graphique (3D, jeux-vidéo), le C++ garde de gros avantages notamment grâce à des types de données plus adapté et de bien meilleurs librairies.

    Après pour des performances brutes sur des traitements de données, les problèmes viennent plus souvent de l'algo que du language...


    a++

  13. #1873
    Membre régulier
    Profil pro Laurent Duroisin
    Inscrit en
    janvier 2010
    Messages
    311
    Détails du profil
    Informations personnelles :
    Nom : Laurent Duroisin

    Informations forums :
    Inscription : janvier 2010
    Messages : 311
    Points : 90
    Points
    90

    Par défaut

    Il n'y a pas de mot-clef inline, mais cela ne veut pas dire que les méthodes ne sont pas inliné !
    Au contraire c'est gérer automatiquement par la JVM !
    Peut-être même plus qu'en C++ car la JVM peut même inliner des méthodes virtuelles (quitte à revenir en arrière si besoin).
    Oui mais bon je trouve que c'est plutôt au développeur de décider quand une méthode doit être inline ou pas. (Moi je préfère le décider par moi même en tout cas et puis seul les accesseurs sont inline en général.

    A quel niveau ? Pour de l’arithmétique de pointeur ?
    Parce que pour le reste il n'y a pas de grosse différence entre un pointeur et une référence (si ce n'est que cette dernière est sécurisé).
    Oui je parlais à ce niveau là.

    C'est à dire ?
    Certaines classes ne sont pas thread safe en java, je prend l'exemple de la classe ArrayList, il faut donc parfois savoir bien maîtriser la programmation multi-thread quand on code en java. (Car les appis graphiques de java utilisent des threads.)

    Cela dépend de ce que tu entends par performances.
    Si c'est du rendu graphique (3D, jeux-vidéo), le C++ garde de gros avantages notamment grâce à des types de données plus adapté et de bien meilleurs librairies.

    Après pour des performances brutes sur des traitements de données, les problèmes viennent plus souvent de l'algo que du language..
    Non je parlais du rendu graphique 3D jeux vidéo. (Je trouves que le c++ est beaucoup plus simple pour faire ça)
    Maintenant si le java peut être aussi rapide pour le traitement de données tant mieux mais je me suis arrêté en java à ce niveau là car j'ai trouvé que le c++ était beaucoup plus simple pour le rendu 3D jeux vidéo.

  14. #1874
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 211
    Points : 19 183
    Points
    19 183

    Par défaut

    Citation Envoyé par Lolilolight Voir le message
    Oui mais bon je trouve que c'est plutôt au développeur de décider quand une méthode doit être inline ou pas. (Moi je préfère le décider par moi même en tout cas et puis seul les accesseurs sont inline en général.
    Sauf que le mot-clef inline n'est qu'une suggestion faite au compilateur, et que ce dernier n'est pas obligé de le respecter.
    De plus et sauf erreur de ma part, le compilateur C/C++ se permet également d'inliner des méthodes malgré l'absence du mot-clef...

    Donc cela ne change pas grand chose (mis à part que le C++ ne peut pas inliner autant de méthode que la JVM).



    Citation Envoyé par Lolilolight Voir le message
    Oui je parlais à ce niveau là.
    Tu utilises souvent l’arithmétique de pointeurs ? C'est le genre de truc bien casse-gueule quand même...
    Perso ce n'est pas le truc qui m'a manqué en passant à Java, et je ne le mettrais certainement pas en avant !
    Surtout que le C++ peut gérer des références !


    Citation Envoyé par Lolilolight Voir le message
    Certaines classes ne sont pas thread safe en java, je prend l'exemple de la classe ArrayList, il faut donc parfois savoir bien maîtriser la programmation multi-thread quand on code en java. (Car les appis graphiques de java utilisent des threads.)
    Et c'est la même chose en C++ : std::list n'est pas thread-safe non plus, et nécessite donc une synchronisation...
    Et la majorité des frameworks graphiques fonctionnent de la même manière que Swing (un thread pour l'affichage, et d'autre pour les traitements lourds).

    De plus l'API Java possèdent plusieurs collections thread-safe, si besoin...


    Citation Envoyé par Lolilolight Voir le message
    Non je parlais du rendu graphique 3D jeux vidéo. (Je trouves que le c++ est beaucoup plus simple pour faire ça)
    Maintenant si le java peut être aussi rapide pour le traitement de données tant mieux mais je me suis arrêté en java à ce niveau là car j'ai trouvé que le c++ était beaucoup plus simple pour le rendu 3D jeux vidéo.
    Je n'ai aucune connaissance du développement 3D donc je ne pourrais rien dire, cela reste un domaine très spécifique.


    a++

  15. #1875
    Expert Confirmé Sénior
    Avatar de Luc Hermitte
    Homme Profil pro Luc Hermitte
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    4 700
    Détails du profil
    Informations personnelles :
    Nom : Homme Luc Hermitte
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 4 700
    Points : 6 992
    Points
    6 992

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Tu utilises souvent l’arithmétique de pointeurs ? C'est le genre de truc bien casse-gueule quand même...
    Perso ce n'est pas le truc qui m'a manqué en passant à Java, et je ne le mettrais certainement pas en avant !
    Surtout que le C++ peut gérer des références !
    Disons qu'aujourd'hui on ne la considère que comme un cas particulier du parcours de plages d'éléments itérables. Ce qui nous permet de passer des pointeurs à tous les algorithmes standards présents dans <algorithm> & cie.

    Pour inline, il est possible d'inliner des fonctions virtuelles dans certains cas particuliers dans mes souvenirs. Le JIT était un des objectifs annoncés avec LLVM (je n'ai jamais regardé ce qu'il en était vraiment). Et concernant l'inlining des fonctions virtuelles à noter aussi que dans le cas général, c'est déporté au processeur à qui on laisse faire des prédictions de branchements. C'est le sens de cet article/billet/expérience paru il y a peu: http://bannalia.blogspot.fr/2014/05/...llections.html (C'est de la bidouille, mais bon)
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média.

  16. #1876
    Membre régulier
    Profil pro Laurent Duroisin
    Inscrit en
    janvier 2010
    Messages
    311
    Détails du profil
    Informations personnelles :
    Nom : Laurent Duroisin

    Informations forums :
    Inscription : janvier 2010
    Messages : 311
    Points : 90
    Points
    90

    Par défaut

    Tu utilises souvent l’arithmétique de pointeurs ? C'est le genre de truc bien casse-gueule quand même...
    Perso ce n'est pas le truc qui m'a manqué en passant à Java, et je ne le mettrais certainement pas en avant !
    Surtout que le C++ peut gérer des références !
    Comme il a été dis dans la réponse ci-dessus, l'arithmétique des pointeurs est très pratique pour itérer tout les éléments (ou bien une plage d'éléments) d'une liste, ajouter une plage d'éléments dans une autre liste, etc..., et c'est aussi très pratique avec opengl pour afficher et mettre à jour une plage de sommets de manière optimisée à l'aide des VBO à l'aide de fonctions tel que memcpy. (Là je parle plutôt dans le rendu de jeux 3D.)
    Il suffit de récupérer la position du vbo en mémoire et le tour est joué.
    Donc oui j'utilise l'arithmétique des pointeurs mais dans ces cas là elle reste relativement simple à utiliser.

    Mais il n'y a pas que ça, là ou les pointeurs deviennent vraiment utile c'est lorsque l'on utilise des pointeurs de fonctions. (Par exemple pour développer un système de commandes c'est à dire appeler une fonction plus tard en lui passant des paramètres lorsqu'un événement quelconque est généré, ou encore lorsqu'on doit appeler une fonction toutes les x secondes)

    En java, si je me rappelle bien, on est obligé de passer par des classes ou bien par des interfaces de la jvm pour faire tout cela. (Ce qui complique parfois les choses lorsque l'on veut créer des commandes plus "personnalisée".)

    Et c'est la même chose en C++ : std::list n'est pas thread-safe non plus, et nécessite donc une synchronisation...
    Et la majorité des frameworks graphiques fonctionnent de la même manière que Swing (un thread pour l'affichage, et d'autre pour les traitements lourds).

    De plus l'API Java possèdent plusieurs collections thread-safe, si besoin...
    En java une connaissance supplémentaire est nécessaire, car JOGL utilise des threads pour l'affichage, de plus il me semble que les collections thread safe sont un peu dépassée, en tout cas on m'a toujours conseillé les ArrayList plutôt que les Vector qui contiennent moins de méthodes intéressantes)

    En c++11 j'ai réussi à gérer les accès concurrant avec un thread qui effectue les traitements lourd et un autre qui effectue l'affichage sans trop de soucis. (Avec un simple std::condition_variable, std::unique_lock et std::thread)

    En java, je n'y arrivais pas et j'ai vite abandonné, car cela nécessitait une connaissance plus approfondie de la jvm que je n'avait pas (méthodes wait et notify sur les objets, le mot clé synchronized, le fonctionnement de l'EDT (l'event dispatch thread), le fonctionnement de JOGL, etc...), ça me lançait toujours une pluie d'exceptions à l'exécution. (Je ne savais pas du tout ou et comment utiliser les primitives de synchronisation fournies par la jvm, maintenant j'y arriverai peut être hein mais, ça ne vaudra jamais les std::timed_mutex ainsi que les std::condition_variable du c++11)

    De plus en c++ avec opengl on n'est pas obligé d'utiliser plusieurs thread si cela n'est pas utile et les accès concurrents sont parfois difficile à déboguer, surtout pour un débutant, surtout si on ne comprend pas ce qui se passe derrière les coulissent et qu'on n'a pas besoin d'un tel design car on doit développer une petite appli.

    Bref pour moi le c++ avec ses différentes librairies à toujours été plus pratique.

    La ou le java excelle vraiment c'est plutôt dans le domaine du développement web et d'internet. (D'ailleurs c'est la raison pour laquelle ce langage a été crée. (le 1er projet de télécommandation d'appareil électro ménagé à distance n'ayant pas fonctionné)

    Le java tout comme son voisin le VB.Net requiers d'avoir un très bon niveau, je me souviens avoir passé des tests pour suivre des formations en java ou bien en .net orienté sharepoint, je ne les ai pas réussi donc je n'ai jamais pu suivre de formations.

  17. #1877
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 211
    Points : 19 183
    Points
    19 183

    Par défaut

    Citation Envoyé par Lolilolight Voir le message
    Mais il n'y a pas que ça, là ou les pointeurs deviennent vraiment utile c'est lorsque l'on utilise des pointeurs de fonctions. (Par exemple pour développer un système de commandes c'est à dire appeler une fonction plus tard en lui passant des paramètres lorsqu'un événement quelconque est généré, ou encore lorsqu'on doit appeler une fonction toutes les x secondes)

    En java, si je me rappelle bien, on est obligé de passer par des classes ou bien par des interfaces de la jvm pour faire tout cela. (Ce qui complique parfois les choses lorsque l'on veut créer des commandes plus "personnalisée".)
    Oui on passe par une interface. Mais je ne vois pas en quoi cela complique les choses.

    A la rigueur c'est verbeux dans le code, mais cela s'est nettement amélioré avec les lambdas et références de méthodes...



    Citation Envoyé par Lolilolight Voir le message
    En java une connaissance supplémentaire est nécessaire, car JOGL utilise des threads pour l'affichage, de plus il me semble que les collections thread safe sont un peu dépassée, en tout cas on m'a toujours conseillé les ArrayList plutôt que les Vector qui contiennent moins de méthodes intéressantes)
    Vector est bel et bien une antiquité.
    Son problème est justement sa synchronisation qui est inutile dans 99% des cas du fait se l'utilisation mono-threadé, et une API pas très clair.

    Mais il y a bien d'autres collections thread-safe, adaptés à plusieurs besoins spécifique (de tête les Collections.synchronizedList(), BlockingQueue, ConcurrentQueue, CopyOnWriteArrayList, ect.)

    Je ne connais pas les équivalent en C++, mais Java est très bien fournit de ce coté là !

    Citation Envoyé par Lolilolight Voir le message
    En c++11 j'ai réussi à gérer les accès concurrant avec un thread qui effectue les traitements lourd et un autre qui effectue l'affichage sans trop de soucis. (Avec un simple std::condition_variable, std::unique_lock et std::thread)

    En java, je n'y arrivais pas et j'ai vite abandonné, car cela nécessitait une connaissance plus approfondie de la jvm que je n'avait pas (méthodes wait et notify sur les objets, le mot clé synchronized, le fonctionnement de l'EDT (l'event dispatch thread), le fonctionnement de JOGL, etc...), ça me lançait toujours une pluie d'exceptions à l'exécution. (Je ne savais pas du tout ou et comment utiliser les primitives de synchronisation fournies par la jvm, maintenant j'y arriverai peut être hein mais, ça ne vaudra jamais les std::timed_mutex ainsi que les std::condition_variable du c++11)
    La différence vient plutôt de ton niveau en Java qui semble inférieur à celui du C++.
    Apparemment tu maitrises les accès concurrents en C++ mais pas en Java...
    Il n'y a rien de mal à cela, mais du coup la comparaison est faussé...


    Je ne connais pas ces std:timed_mutex ou std::condition_variable, mais une lecture vite fait sur cppreference me fait penser aux Lock et aux wait/notify de Java...
    Les noms des méthodes sont quasi les mêmes !


    Citation Envoyé par Lolilolight Voir le message
    De plus en c++ avec opengl on n'est pas obligé d'utiliser plusieurs thread si cela n'est pas utile et les accès concurrents sont parfois difficile à déboguer, surtout pour un débutant, surtout si on ne comprend pas ce qui se passe derrière les coulissent et qu'on n'a pas besoin d'un tel design car on doit développer une petite appli.
    Je ne vois pas pourquoi ce serait différent dans l'OpenGL de Java...


    Citation Envoyé par Lolilolight Voir le message
    Le java tout comme son voisin le VB.Net requiers d'avoir un très bon niveau, je me souviens avoir passé des tests pour suivre des formations en java ou bien en .net orienté sharepoint, je ne les ai pas réussi donc je n'ai jamais pu suivre de formations.
    Je ne vois pas en quoi VB.NET serait voisin de Java !?
    Quand au bon niveau, c'est également le cas en C++ hein ! Surtout que ce dernier incorpore une multitude de concept...


    a++

  18. #1878
    Membre régulier
    Profil pro Laurent Duroisin
    Inscrit en
    janvier 2010
    Messages
    311
    Détails du profil
    Informations personnelles :
    Nom : Laurent Duroisin

    Informations forums :
    Inscription : janvier 2010
    Messages : 311
    Points : 90
    Points
    90

    Par défaut

    Oui on passe par une interface. Mais je ne vois pas en quoi cela complique les choses.

    A la rigueur c'est verbeux dans le code, mais cela s'est nettement amélioré avec les lambdas et références de méthodes...
    Référence de méthodes, ha bon ?
    Ca doit être nouveau ça, car cela n'existait pas encore à l'époque.

    La différence vient plutôt de ton niveau en Java qui semble inférieur à celui du C++.
    Oui peut être.

    Je ne vois pas en quoi VB.NET serait voisin de Java !?
    Contrairement au c++, VB.NET et JAVA permettent de faire du développement internet.

    Microsoft et sun s'étaient même associé à un certain moment.

  19. #1879
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 211
    Points : 19 183
    Points
    19 183

    Par défaut

    Citation Envoyé par Lolilolight Voir le message
    Référence de méthodes, ha bon ?
    Ca doit être nouveau ça, car cela n'existait pas encore à l'époque.
    Oui c'est tout récent (Java 8).

    Mais l'utilisation d'une interface en remplacement d'un pointeur de fonction fait amplement l'affaire même sans cela (c'est juste un peu plus long à écrire).


    Citation Envoyé par Lolilolight Voir le message
    Contrairement au c++, VB.NET et JAVA permettent de faire du développement internet.
    Mouais enfin c'est un peu tiré par les cheveux quand même. Ces deux langages sont quand même très éloigné.
    A la rigueur tu m'aurais dit C# qui a une approche assez similaire (même si là encore il y a également beaucoup de différence)


    Citation Envoyé par Lolilolight Voir le message
    Microsoft et sun s'étaient même associé à un certain moment.
    Ils n'étaient pas vraiment associé...
    Microsoft avait juste une licence Java (comme d'autres tel que Apple ou IBM).

    Mais Microsoft a tenté de dénaturer Java en y incorporant des librairies non-standard spécifique à Windows, ce qui a finit en procès (et "tuer" les applets par la même occasion).


    a++

  20. #1880
    Membre régulier
    Profil pro Laurent Duroisin
    Inscrit en
    janvier 2010
    Messages
    311
    Détails du profil
    Informations personnelles :
    Nom : Laurent Duroisin

    Informations forums :
    Inscription : janvier 2010
    Messages : 311
    Points : 90
    Points
    90

    Par défaut

    Ok, ok, plus rien ne m'étonne en ce qui concerne microsoft.

    A+.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •