IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Pourquoi le langage C++ demeure incontournable 35 ans après sa sortie ?


Sujet :

C++

  1. #41
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    On a bien mieux depuis l'ère des BASIC (avec laquelle j'ai débuté) : Pascal, Ada, voire Python si tu ne veux pas imposer de phase de compilation qui vérifie les erreurs de typage.
    Je n'ai jamais dit que Basic est le seul langage parfait pour débuter, je l'ai juste cité comme un langage plutôt bon comparé à des langage trop techniques comme le C/C++ ou la plupart des problèmes des débutants seront autant sur les mécaniques du langage que sur l'algorithmie.

    C'est vrai que je ne les ai pas cité mais Pascal et Ada sont aussi de bon langages d'apprentissage (je connais peu Python), même si a titre personnel je trouve Ada inutilement lourd quand on veux se concentrer sur l’algorithmie.

  2. #42
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Salut,
    Citation Envoyé par DonQuiche Voir le message
    J'ignorais cela et c'est une excellente nouvelle, je te remercie. Le jour où ça sortira j'aurais peut-être envie de refaire du c++ (aujourd'hui je vois ça comme la croix et la bannière à chaque fois que je dois m'y remettre).
    je suis d'accord que c'est caché à l'utilisateur, mais, à ton sens, que fait l'instruction import de java?

    Cela se fait au niveau de la JVM, mais, il n'y a rien à faire, cette instruction ne fait pas grand chose d'autre que ce que fait la directive préprocesseur #include au final, même si je t'accorde que c'est enrobé de manière à ce que l'utilisateur d'une classe n'ait pas **trop** à s'en inquiéter
    Je sais parfaitement ce qu'il en est et ça reste de la gestion manuelle selon moi, bien qu'allégée : tu dois polluer ton code par des annotations mémoire systématiques, tu continues à te retrouver avec des fuites mémoire difficiles à comprendre, et il n'est pas rare du tout de devoir faire des changements profonds, notamment quand le dominateur d'un objet change (par exemple parce que tu as soudain besoin de persister ton objet plus longtemps que prévu, au-delà de la durée de vie de son précédent dominateur).
    Pas si tu utilise correctement le RAII et que tu veilles à utiliser les classes RAIIsantes pour tes pointeurs

    Une incrémentation atomique (pour un shared_ptr) est loin d'être gratuite. Et ça ne va pas aller en s’améliorant avec la multiplication du degré de parallélisme du matériel. Mais c'est un point de détail dans la mesure où la solution bas niveau reste disponible.
    Et, à ton avis, que fait le garbage collector de java, à part compter des références

    La grosse différence entre java et C++ est que, au moins, tu as le choix de payer le cout de ce comptage de référence ou non, selon tes besoins, alors qu'il t'est imposé en java
    Dans les quelques cas où ça répond à ton besoin, oui.
    Si ce n'est que, si ta conception est bonne, tu devrais beaucoup plus souvent utiliser des unique_ptr que des shared_ptr.

    A mon sens, il est beaucoup plus sain de se dire que, quoi qu'il arrive, il n'y a jamais qu'un et un seul objet qui, à un instant T, peut décider de détruire une ressource -- quitte à transférer de temps en temps cette responsabilité -- plutôt que de se dire que cette décision doit être collégiale.

    Il y a, bien sur, des cas dans lesquels tu ne peux éviter le recours au shared_ptr, mais, à titre personnel, je ressent toujours ces situations comme un échec conceptuel, car je préfère de loin utiliser les unique_ptr, et que, je préfère encore purement et simplement éviter le recours aux pointeurs à chaque fois que faire se peut
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #43
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Salut,
    je suis d'accord que c'est caché à l'utilisateur, mais, à ton sens, que fait l'instruction import de java?

    Cela se fait au niveau de la JVM, mais, il n'y a rien à faire, cette instruction ne fait pas grand chose d'autre que ce que fait la directive préprocesseur #include au final, même si je t'accorde que c'est enrobé de manière à ce que l'utilisateur d'une classe n'ait pas **trop** à s'en inquiéter
    Sauf que en Java le compilateur va chercher les meta-données nécessaire dans le fichier compilé. C'est beaucoup plus rapide et plus propre qu'une inclusion de code source avec tous les problèmes qui en découlent.

    Citation Envoyé par koala01 Voir le message
    Pas si tu utilise correctement le RAII et que tu veilles à utiliser les classes RAIIsantes pour tes pointeurs
    Bref ça n'est pas aussi magiquement évident que les gourou du C++ veulent faire croire.
    En C++ même avec les outils de gestion dite "automatique" de la mémoire, il faut quand même faire bien plus attention à ce que l'on fait qu'avec des langages entièrement gérés par GC.

    Citation Envoyé par koala01 Voir le message
    Et, à ton avis, que fait le garbage collector de java, à part compter des références
    Renseigne toi tu verras qu'il fait bien plus. Notamment il permet de collecter les cycle ce qu'un shared_ptr ne fera pas de base.

    Citation Envoyé par koala01 Voir le message
    La grosse différence entre java et C++ est que, au moins, tu as le choix de payer le cout de ce comptage de référence ou non, selon tes besoins, alors qu'il t'est imposé en java
    Sur ce point là par contre je suis on ne peux plus d'accord.

  4. #44
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par koala01 Voir le message
    je suis d'accord que c'est caché à l'utilisateur, mais, à ton sens, que fait l'instruction import de java?
    Ça n'est pas du tout comparable avec une inclusion. L'inclusion agit au niveau du préprocesseur lui-même, a un coût significatif et prend en argument un fichier. Une directive import n'agit que lors de l'analyse sémantique, a un coût négligeable, et prend en argument un espace sémantique. C'est le jour et la nuit.

    Pas si tu utilise correctement le RAII et que tu veilles à utiliser les classes RAIIsantes pour tes pointeurs
    Tu ne m'as pas compris : en utilisant exclusivement les smart pointeurs, si le dominateur de ton objet change tu peux avoir besoin de transformer des shared_ptr en weak_ptr. Et dans d'autres cas de figure tu devras transformer des unique_ptr en shared_ptr ou weak_ptr.

    Si ce n'est que, si ta conception est bonne, tu devrais beaucoup plus souvent utiliser des unique_ptr que des shared_ptr.
    Je trouve cette affirmation très cavalière. Je ne pense pas que ce soit une question de qualité de la conception. Au mieux tu peux déformer ta conception idéale pour privilégier des unique_ptr.

    Et, à ton avis, que fait le garbage collector de java, à part compter des références
    Justement, non, peu de ramasse-miettes modernes fonctionnent par comptage de références. Je t'invite à chercher "mark'n sweep".

    Un GC typique ne nécessite pas de compteurs atomiques et se débarrasse de tout besoin de synchronisation en stoppant un thread le temps d'en collecter les racines (relevé des registres et de la pile d'appels) ou d'en modifier les adresses après un compactage.

    Contrairement aux idées reçues cela requiert le plus souvent moins de cycles CPU qu'un comptage de références atomiques grâce à plusieurs avantages :
    * Absence de synchronisation. Une incrémentation atomique est une opération lourde.
    * Allocations très rapides (compactage O(n) régulier au lieu de la gestion au fil de l'eau d'un tas)
    * Contiguïté des allocations (mais invalidation périodique des caches CPU lors du compactage).
    * Parallélisation. Et les nouveaux APU à mémoire unifiée devraient permettre d'utiliser efficacement le GPU pour cette tâche.

    En revanche cela impose des arrêts intermittents et une consommation mémoire accrue, et je connais trop peu les algorithmes concurrents pour me prononcer sur impressionnabilité de la solution.

    Notez que je ne cite tout cela qu'à but pédagogique. Mon but n'a jamais été de faire un énième comparatif C#/Java/C++, chacun ayant ses forces et ses faiblesses. J'avais simplement relevé un pont de détail sur les performances des smart pointers.

  5. #45
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Citation Envoyé par Uther Voir le message
    Bref ça n'est pas aussi magiquement évident que les gourou du C++ veulent faire croire.
    En C++ même avec les outils de gestion dite "automatique" de la mémoire, il faut quand même faire bien plus attention à ce que l'on fait qu'avec des langages entièrement gérés par GC.
    Oui et non. Certes il reste les problèmes de cycles. Mais je me souviens d'un temps où l'on conseillait de faire des "var=null;" dans les blocs finally en Java -- à tord ou à raison, je n'ai jamais su. Et les GC ne résolvent pas les problèmes des autres ressources. On en revient au dispose-pattern. Bref, même avec les GC il reste des questions à se poser.
    En C++, la situation va se résumer à aucun pointeur brut, et pas de delete. Après, il est sûr qu'il faut savoir choisir entre unique_ptr, shared_ptr et weak_ptr.

    Maintenant, je suis tombé il y a peu sur une présentation qui disait en substance que les shared_ptr ne valaient pas mieux que les variables globales. Dit autrement, une bonne conception requiert d'éviter de tout partager dans tous les sens et de ne se poser aucune question.

    Dans tous les cas, cela n'a rien de manuel en C++. Et non on ne veut surtout pas du manuel. Cela ne résiste pas aux exceptions.

    Sinon, Effectivement, en situation MT, les GC peuvent donner de meilleures performances que les shared_ptr<> (que l'on commence donc à décrier en C++ comme je le disais à l'instant).
    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. Et de toutes façons, ma BAL sur dvpz est pleine...

  6. #46
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Tu ne m'as pas compris : en utilisant exclusivement les smart pointeurs, si le dominateur de ton objet change tu peux avoir besoin de transformer des shared_ptr en weak_ptr. Et dans d'autres cas de figure tu devras transformer des unique_ptr en shared_ptr ou weak_ptr.
    Passer de weak_ptr à shared_ptr, et inversement, c'est "normal" à partir du moment ou tout utilisateur d'un pointeur partagé n'a pas forcément droit au chapitre lorsqu'il s'agit de décider de libérer la mémoire allouée à ce pointeur.

    Par contre, décider de transformer un unique_ptr en shared_ptr (ou en weak_ptr) est une aberration sans nom : par essence, il n'y a qu'un et un seul objet responsable de la durée de vie du pointeur maintenu par un unique_ptr. Si tu dois changer cet aspect des choses, c'est que tu t'es fourvoyé dans ta conception lorsque tu as décidé d'utiliser un unique_ptr ;-)
    Je trouve cette affirmation très cavalière. Je ne pense pas que ce soit une question de qualité de la conception. Au mieux tu peux déformer ta conception idéale pour privilégier des unique_ptr.
    Et pourtant, si tu lis bien, j'ai bien indiqué qu'il y a des cas où tu n'as effectivement pas le choix et où tu ne peux pas éviter le fait que plusieurs objets décident collégialement de la durée de vie d'un pointeur.

    Cela n'empêche que, en dehors de ces cas bien particuliers, il est relativement aberrant d'accepter la simple idée que plusieurs objets puissent en venir à décider collégialement de la durée de vie d'une ressource, car, d'une manière ou d'une autre, cela signifie au mieux que le SRP n'est pas respecté par au moins quelques une des classes qui interviennent dans la décision.
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #47
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    J'en viens à préciser un point intéressant de l'import Java.

    Le compilateur vérifie l'existence de la cible. Mais l'import est encore écrit tel quel dans le bytecode.

    En effet, les fichier .class contiennent une section de constantes, parmi lesquelles se trouvent les noms des types utilisés.
    C'est le class loader du runtime qui devra faire les imports.
    C'est pour cette raison précise que les classes doivent être écrites dans des fichiers à leur nom, et que les packages sont les dossiers.

    La différence est de taille: le code n'est pas immédiatement disponible.
    Il faut finir la compilation (JIT) pendant l'exécution, ou au mieux, à son début.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  8. #48
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Sinon, Effectivement, en situation MT, les GC peuvent donner de meilleures performances que les shared_ptr<> (que l'on commence donc à décrier en C++ comme je le disais à l'instant).
    De base, un contexte où des threads exécutés en parallèle se partagent la responsabilité de ressources allouées dynamiquement, ça sent gravement le pâté (et bon courage pour certifier un tel algo).

  9. #49
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Sinon, Effectivement, en situation MT, les GC peuvent donner de meilleures performances que les shared_ptr<> (que l'on commence donc à décrier en C++ comme je le disais à l'instant).
    Le coût de synchronisation des incrémentations atomiques se paie que tu aies un ou plusieurs threads ; ça ne change rien parce que le compilateur ne peut pas deviner ça. A la rigueur la contention peut accroître le coût (sur certaines architectures) mais c'est un cas particulier.

    Au passage ce choix d'un comptage de références est un peu étonnant pour un langage aussi portable que le C++ : ça fonctionne bien sur x86 (et ARM ?) mais sur certaines architectures les incrémentations atomiques n'existent pas et sur d'autres elles sont prohibitives, comme par exemple les clusters ou les interconnexions de cache en anneau. Du coup ça incite les dévs à écrire un code peu portable alors qu'ils n'avaient pas de problème de synchronisation à la base parce que leurs objets ne sont pas partagés.

    Citation Envoyé par KsassPeuk Voir le message
    De base, un contexte où des threads exécutés en parallèle se partagent la responsabilité de ressources allouées dynamiquement, ça sent gravement le pâté (et bon courage pour certifier un tel algo).
    Ben justement non, avec un GC ça ne sent pas du tout le pâté. Un bon contre-exemple c'est une architecture où l'on partage entre threads des données immuables dont la libération est déterminée par le GC. C'est typiquement une architecture très parallélisable et robuste, et simple à vérifier.

    Et le GC est un excellent allié pour la manipuler de telles structures immuables et effacer automatiquement les parties qui ne sont plus accessibles. Pour faire la même chose avec des smart pointers tu as intérêt à bien réfléchir au problème en amont et ajouter des vérifications à l'exécution, et de toute façon ce sera via des shared_ptr en payant le prix fort, avec partage de lignes de cache en écriture entre les threads (les compteurs).

    Citation Envoyé par leternel Voir le message
    Le compilateur vérifie l'existence de la cible. Mais l'import est encore écrit tel quel dans le bytecode.

    En effet, les fichier .class contiennent une section de constantes, parmi lesquelles se trouvent les noms des types utilisés.
    C'est le class loader du runtime qui devra faire les imports.
    Ce sont deux choses différentes : oui c'est la JVM qui lie les types à partir de leur chaîne à la compilation JIT mais l'import n'est pas un processus de liaison, c'est le processus d'exposition des espaces sémantiques. Or je ne connais pas Java mais je ne crois pas que ces imports soit enregistrés dans le bytecode.

  10. #50
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    Pour en avoir décompilé (et désobfuscé) manuellement plus qu'à mon goût, si, on les retrouve.

    pour être précis, on se retrouve avec des instructions telles que :

    typecheck local_var[7] is constante_57
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  11. #51
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    C'est bien ce que je dis, ce ne sont pas des imports d'espaces de noms, simplement des références aux types. Le JVM n'importe pas d'espaces de noms, elle opère simplement la liaison des types à partir des chaines fournies. Les imports relèvent de l'analyse sémantique du code source, là c'est simplement du late binding.

  12. #52
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    452
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Afghanistan

    Informations forums :
    Inscription : Juin 2003
    Messages : 452
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut .............
    En général , les gens qui donne l'absence de garbage collector comme un point fort du langage C++ ne savent pas comment fonctionne un garbage collector.
    Celui de java est l'un des plus évolué, il peut fonctionner en parallèle sans pratiquement geler la machine virtuelle.
    Le garbage est un sécurité suplémentaire.

    En plus ceux qui dise qu'on peut le faire en C++ il me font bien rire allez donc parcourir la pile d'execution , déplacer les objets entre une jeune génération et une vieille génération, enfin faire le travail complexe d'un GC dans le langage lui même , seul la technic du compteur de référence peut être facilement réalisable.


    Il y une chose importante aussi , c pas parce qu' un langage comme COBOL ou C++ est beaucoup utilisé dans la finance ou autre qu'il est le langage le plus adapté pour ce domaine.
    Bcp sur ce forum n'ont pas l’expérience professionnel pour savoir que dans le monde de l'entreprise on ne réécrit pas un programme qui fonctionne correctement dans un langage qui pourrait être plus adapté.
    Si en entreprise un programme en C++ ou en COBOL fonctionne bien il ne sera jamais réécrit en java même si celui-ci serait plus adapté, ça coûte trop chère et c une question de bon sens.


    J'ai toujours remarqué que les pros C++ était des intégristes de leur langage, C++ était le meilleur dans langage avant et au début de java c sur mais les temps change, comme on a bien cru que C# allé remplacé java.

    Peut être un jour java trouvera un meilleur concurrent mais pas aujourd'hui..................

  13. #53
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Citation Envoyé par super_navide Voir le message
    J'ai toujours remarqué que les pros C++ était des intégristes de leur langage, C++ était le meilleur dans langage avant et au début de java c sur mais les temps change, comme on a bien cru que C# allé remplacé java.
    Et finalement c'est python ...
    (J'en profite on est encore Vendredi).

    Le truc est que là, c'est parti d'un troll qui ne connaissait pas le C++. Après, pour les langages, chacun a ses préférences. Imagine que l'on débarde en disant le GC de Java est trop pourri : il ne gère pas les cycles, et en plus la SortedList standard dérive de List. C'était vrai. En Java 1. Dire que l'on gère la mémoire à la main en C++, c'est tout aussi ridicule depuis 15ans -- à la différence que même dans eux qui utilisent le C++, nombreux sont ceux à le faire (à la main), et presque aussi nombreux sont ceux qui croient que c'est bien, et qui préfèrent continuer ainsi plutôt que de remettre en question leurs bases C et d'apprendre à utiliser le C++.
    Il ne faut pas être surpris quand certains s'en agacent et partent au quart de tour.
    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. Et de toutes façons, ma BAL sur dvpz est pleine...

  14. #54
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par super_navide Voir le message
    En général , les gens qui donne l'absence de garbage collector comme un point fort du langage C++ ne savent pas comment fonctionne un garbage collector.
    Celui de java est l'un des plus évolué, il peut fonctionner en parallèle sans pratiquement geler la machine virtuelle.
    Le garbage est un sécurité suplémentaire.
    Un des principaux problèmes d'un GC est que pour qu'il marche sans se voir, il faut disposer de plus de mémoire que nécessaire. J'avais vu une étude sur le GC Java où ils disaient qu'en gros (pas les bons chiffres, juste les ordres de grandeur), quand tu as 6 fois plus de mémoie que nécessaire, le GC ne se voit pas en terme de perfs (mais son gel de thread le rend quand même inutilisable pour du temps réel). Quand tu as 2 fois plus de mémoire, l'impact est visible mais faible, quelques %. Moins que ça, l'impact augmente en flèche.

    Le fait de geler la VM semble assez important pour que par exemple Apple ait supprimé le GC d'objective C et refuse d'en mettre en swift.
    Citation Envoyé par super_navide Voir le message
    En plus ceux qui dise qu'on peut le faire en C++ il me font bien rire allez donc parcourir la pile d'execution , déplacer les objets entre une jeune génération et une vieille génération, enfin faire le travail complexe d'un GC dans le langage lui même , seul la technic du compteur de référence peut être facilement réalisable.
    Il existe pourtant des GC génériques en C++. Je ne dis pas que c'est trivial à mettre en place. Et généralement, ce sont des GC qui ne déplacent pas les objets en mémoire, et n'évitent donc pas forcément la fragmentation.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  15. #55
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    452
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Afghanistan

    Informations forums :
    Inscription : Juin 2003
    Messages : 452
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut ....
    Le point faible de C++ par rapport à java est le byte code qui représente une abstraction de l'assembleur.
    Cette abstraction ne permet pour l'instant de ne pas avoir les même performance que le C++ mais les écarts diminue.
    Il y a quelque année on disait qu'aucun jeux videos ne serait fait en java à cause du GC qui gèle la VM, Mincraft est en java .....!!!!!


    La prochaine version de java qui inclura le type values écrasera C++ et probablement la VM sera réécrite en Java puis le byte code compiler pour la machine cible et la boucle sera bouclée le tous java............

    la seul chose qui restera pour le C++ encore longtemps est l'écriture d'un OS et de ses drivers, mais pour combien de temps !!!!
    on pourrais imaginer des instructions du byte code java pour gérer directement le materiel mais bon la je vois pas l'intéret..........

  16. #56
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par super_navide Voir le message
    Oui C++ est très performant mais au prix d'une complexité importante dans le temps java prendra le dessus mais C++ restera comme le COBOL.
    Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.
    Et qu'est-ce qui empêche de programmer une carte graphique en C++ ? Tu mélanges langage de programmation et cible de compilation... Il y a déjà des bibliothèques/extensions C++ pour gérer la carte graphique (ArrayBuildingBlocks d'Inter, C++Amp de Microsoft, et probablement plein d'autres), même si ça reste un domaine à évolutions rapides. Et pour information, parmi les gens qui travaillent sur les évolutions du C++ pour le parallélisme, il y a des gens de chez NVidia. Ce n'est certainement pas sans une bonne raison...
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  17. #57
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    452
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Afghanistan

    Informations forums :
    Inscription : Juin 2003
    Messages : 452
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    Et qu'est-ce qui empêche de programmer une carte graphique en C++ ? Tu mélanges langage de programmation et cible de compilation... Il y a déjà des bibliothèques/extensions C++ pour gérer la carte graphique (ArrayBuildingBlocks d'Inter, C++Amp de Microsoft, et probablement plein d'autres), même si ça reste un domaine à évolutions rapides. Et pour information, parmi les gens qui travaillent sur les évolutions du C++ pour le parallélisme, il y a des gens de chez NVidia. Ce n'est certainement pas sans une bonne raison...
    Oui je suis d'accord on pourrait imaginer faire tourner du C++ directement sur une carte graphique tous comme du Java.
    Moi je parle du langage de shader inspirer du C qui tourne sur la carte graphique.
    Celui-ci est simple ne fait d'allocation dynamique et est vraiment simple d'utilisation.

    L'avenir c java plus l'utilisation de langage de type "language shader"

    Je rappelle que qu'un programme passe 80% de son temps dans 20% du code et généralement ce code peut être écrit en C.

    Le seul langage incontournable est le C ou un C like comme le langage des shaders si on veut vraiment de la performance.

  18. #58
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    452
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Afghanistan

    Informations forums :
    Inscription : Juin 2003
    Messages : 452
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Ça n'est pas du tout comparable avec une inclusion. L'inclusion agit au niveau du préprocesseur lui-même, a un coût significatif et prend en argument un fichier. Une directive import n'agit que lors de l'analyse sémantique, a un coût négligeable, et prend en argument un espace sémantique. C'est le jour et la nuit.


    Tu ne m'as pas compris : en utilisant exclusivement les smart pointeurs, si le dominateur de ton objet change tu peux avoir besoin de transformer des shared_ptr en weak_ptr. Et dans d'autres cas de figure tu devras transformer des unique_ptr en shared_ptr ou weak_ptr.


    Je trouve cette affirmation très cavalière. Je ne pense pas que ce soit une question de qualité de la conception. Au mieux tu peux déformer ta conception idéale pour privilégier des unique_ptr.


    Justement, non, peu de ramasse-miettes modernes fonctionnent par comptage de références. Je t'invite à chercher "mark'n sweep".

    Un GC typique ne nécessite pas de compteurs atomiques et se débarrasse de tout besoin de synchronisation en stoppant un thread le temps d'en collecter les racines (relevé des registres et de la pile d'appels) ou d'en modifier les adresses après un compactage.

    Contrairement aux idées reçues cela requiert le plus souvent moins de cycles CPU qu'un comptage de références atomiques grâce à plusieurs avantages :
    * Absence de synchronisation. Une incrémentation atomique est une opération lourde.
    * Allocations très rapides (compactage O(n) régulier au lieu de la gestion au fil de l'eau d'un tas)
    * Contiguïté des allocations (mais invalidation périodique des caches CPU lors du compactage).
    * Parallélisation. Et les nouveaux APU à mémoire unifiée devraient permettre d'utiliser efficacement le GPU pour cette tâche.

    En revanche cela impose des arrêts intermittents et une consommation mémoire accrue, et je connais trop peu les algorithmes concurrents pour me prononcer sur impressionnabilité de la solution.

    Notez que je ne cite tout cela qu'à but pédagogique. Mon but n'a jamais été de faire un énième comparatif C#/Java/C++, chacun ayant ses forces et ses faiblesses. J'avais simplement relevé un pont de détail sur les performances des smart pointers.

    La récupération de la mémoire par un mark and sweep est tres tres tres couteux.

    Car il revient a parcourir toute la pile et les variables globales pour marquer les objets accessible, rendez vous compte des performance sur des millions d'objet avec des lien dans tous les sens.
    Aujourd'hui les garbage collector fonctionne avec un system de génération et un mark and sweep modifié fonctionnant sur les jeune générations( ils s'arrète quand il tombe sur des objets trop vieux )
    Il n'y a aucun intérêt à parcourir de vieux objet qui sont la depuis longtemps en mémoire.

    Mon explication est encore loin de la réalité car le mark and weep peut je croix maintenant ce faire sans en parallel sans geler la machine virtuel.

  19. #59
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par super_navide Voir le message
    Oui je suis d'accord on pourrait imaginer faire tourner du C++ directement sur une carte graphique tous comme du Java.
    Moi je parle du langage de shader inspirer du C qui tourne sur la carte graphique.
    Celui-ci est simple ne fait d'allocation dynamique et est vraiment simple d'utilisation.

    L'avenir c java plus l'utilisation de langage de type "language shader"

    Je rappelle que qu'un programme passe 80% de son temps dans 20% du code et généralement ce code peut être écrit en C.

    Le seul langage incontournable est le C ou un C like comme le langage des shaders si on veut vraiment de la performance.
    Le C a été (est) utilisé pour les GPU parce que ceux-ci étaient (sont) primitifs. Il s'agissait de grosses usines vectorielles s'effondrant au premier branchement venu, dépourvu de mémoire virtuelle ou de mécanismes de protection, avec une synchronisation inexistante ou bancale, seulement capables de recevoir passivement des ordres du CPU et tout juste aptes à signaler la fin du boulot au CPU. On leur envoyait un gros paquet de données via un bus PCIe bien lent et un passage en kernel mode, puis on récupérait quelques microsecondes plus tard un gros paquet de données via un bus PCIe bien lent.

    Ça c'était (c'est) le GPU de grand-papa. Ce qui est en train d'apparaître maintenant, notamment chez AMD (mais les autres suivent, y compris les éditeurs logiciels), ce sont des coeurs GPU intégrés au CPU, toujours vectoriels mais beaucoup pus généralistes, ayant résolu à peu près tous les points mentionnés ci-dessus. Ne reste plus que l'absence de pile d'appels, ce qui sera sans doute résolu dans une ou deux générations.

    Donc oui on va faire de plus en plus appel au GPU, mais ce ne sera certainement pas avec du C.
    * D'abord parce que personne ou presque n'a envie de programmer en C : peu productif, risqué, etc.
    * Ensuite parce qu'écrire ton code dans deux langages, ça veut dire écrire plein de plomberie pour faire cohabiter les deux et beaucoup de redondance.
    * Enfin parce que beaucoup d'algorithmes perdent de leur intérêt si tu dois préalablement transformer tes données d'un format vers un autre, et vice-versa au retour.

    Sceptique ? Jette un coup d'oeil au projet Sumatra. C'est un gros effort d'AMD et d'autres pour programmer le GPU directement en Java (avec bien sûr des limitations concernant les parties à exécuter sur le GPU mais pas tant que ça).

    Plus généralement tout ce problème s'inscrit dans la perspective du calcul hétérogène dans le nuage: autrement dit la capacité à exploiter des architectures spécifiques dans le nuage, tout en payant la plus petite taxe de virtualisation possible. Un acteur comme Microsoft mise pour ça sur un bytecode dont certaines propriétés (isolation mémoire, absence de deadlock avec l'extérieur, etc) sont prouvables (de façon à lever la taxe) et qui aura pour cibles de compilation tant des CPU que des GPU ou autres. Si ce bytecode sera vraisemblablement de plus bas niveau que celui de dotnet, je doute qu'on puisse y compiler efficacement du C. D'ailleurs MS développe un langage de plus haut niveau et plus sécurisé que le C mais d'assez bas niveau pour être dédié à la programmation système tout en tournant sur ce bytecode ; il serait destiné aux pilotes de péirphériques et au coeur du système.

    Citation Envoyé par super_navide Voir le message
    La récupération de la mémoire par un mark and sweep est tres tres tres couteux.
    Non. Mais coûteux, oui, tout comme l'ensemble shared_ptr + weak_ptr + allocateur par tas. Souvent moins en fait.

    Car il revient a parcourir toute la pile et les variables globales pour marquer les objets accessible, rendez vous compte des performance sur des millions d'objet avec des lien dans tous les sens.
    Non, pas des millions d'objets. D'abord parce qu'on n'a pas à visiter les anciens objets (génération 2 - il faudra seulement visiter les pages mémoire modifiées) ni les objets inaccessibles. Ensuite parce que la pile d'appels est en général assez compacte. Enfin parce que c'est un problème mémory-bound mais que les nouveaux objets sont tous dans le cache L3 ou inférieur.

    Mon explication est encore loin de la réalité car le mark and weep peut je croix maintenant ce faire sans en parallel sans geler la machine virtuel.
    Des algos de ce genre existent, oui, mais ils obligent à utiliser des formes de synchronisation à tel ou tel moment et ne sont donc pas forcément plus intéressants. Comme d'hab il n'y a pas de magie. A ma connaissance (mais je ne suis pas spécialiste) il est généralement plus rapide d'arrêter les threads (voire de les arrêter indépendamment pour les serveurs webs) mais de ne faire que le strict minimum à ce moment-là et reporter le reste de la charge à plus tard.

  20. #60
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    452
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Afghanistan

    Informations forums :
    Inscription : Juin 2003
    Messages : 452
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut Pas confondre GPU et multi coeur
    Citation Envoyé par DonQuiche Voir le message
    Le C a été (est) utilisé pour les GPU parce que ceux-ci étaient (sont) primitifs. Il s'agissait de grosses usines vectorielles s'effondrant au premier branchement venu, dépourvu de mémoire virtuelle ou de mécanismes de protection, avec une synchronisation inexistante ou bancale, seulement capables de recevoir passivement des ordres du CPU et tout juste aptes à signaler la fin du boulot au CPU. On leur envoyait un gros paquet de données via un bus PCIe bien lent et un passage en kernel mode, puis on récupérait quelques microsecondes plus tard un gros paquet de données via un bus PCIe bien lent.

    Ça c'était (c'est) le GPU de grand-papa. Ce qui est en train d'apparaître maintenant, notamment chez AMD (mais les autres suivent, y compris les éditeurs logiciels), ce sont des coeurs GPU intégrés au CPU, toujours vectoriels mais beaucoup pus généralistes, ayant résolu à peu près tous les points mentionnés ci-dessus. Ne reste plus que l'absence de pile d'appels, ce qui sera sans doute résolu dans une ou deux générations.

    Donc oui on va faire de plus en plus appel au GPU, mais ce ne sera certainement pas avec du C.
    * D'abord parce que personne ou presque n'a envie de programmer en C : peu productif, risqué, etc.
    * Ensuite parce qu'écrire ton code dans deux langages, ça veut dire écrire plein de plomberie pour faire cohabiter les deux et beaucoup de redondance.
    * Enfin parce que beaucoup d'algorithmes perdent de leur intérêt si tu dois préalablement transformer tes données d'un format vers un autre, et vice-versa au retour.

    Sceptique ? Jette un coup d'oeil au projet Sumatra. C'est un gros effort d'AMD et d'autres pour programmer le GPU directement en Java (avec bien sûr des limitations concernant les parties à exécuter sur le GPU mais pas tant que ça).

    Plus généralement tout ce problème s'inscrit dans la perspective du calcul hétérogène dans le nuage: autrement dit la capacité à exploiter des architectures spécifiques dans le nuage, tout en payant la plus petite taxe de virtualisation possible. Un acteur comme Microsoft mise pour ça sur un bytecode dont certaines propriétés (isolation mémoire, absence de deadlock avec l'extérieur, etc) sont prouvables (de façon à lever la taxe) et qui aura pour cibles de compilation tant des CPU que des GPU ou autres. Si ce bytecode sera vraisemblablement de plus bas niveau que celui de dotnet, je doute qu'on puisse y compiler efficacement du C. D'ailleurs MS développe un langage de plus haut niveau et plus sécurisé que le C mais d'assez bas niveau pour être dédié à la programmation système tout en tournant sur ce bytecode ; il serait destiné aux pilotes de péirphériques et au coeur du système.


    Non. Mais coûteux, oui, tout comme l'ensemble shared_ptr + weak_ptr + allocateur par tas. Souvent moins en fait.


    Non, pas des millions d'objets. D'abord parce qu'on n'a pas à visiter les anciens objets (génération 2 - il faudra seulement visiter les pages mémoire modifiées) ni les objets inaccessibles. Ensuite parce que la pile d'appels est en général assez compacte. Enfin parce que c'est un problème mémory-bound mais que les nouveaux objets sont tous dans le cache L3 ou inférieur.


    Des algos de ce genre existent, oui, mais ils obligent à utiliser des formes de synchronisation à tel ou tel moment et ne sont donc pas forcément plus intéressants. Comme d'hab il n'y a pas de magie. A ma connaissance (mais je ne suis pas spécialiste) il est généralement plus rapide d'arrêter les threads (voire de les arrêter indépendamment pour les serveurs webs) mais de ne faire que le strict minimum à ce moment-là et reporter le reste de la charge à plus tard.

    La tu confond largement multi-coeur et GPU.

    Le premier c avoir N processeur et en java ou autre utiliser des threads et des sémaphores ou autre objet de synchronisation.
    Pour certain problème c la seul solution pour d'autre il y a bcp plus puissant car sans utilisation de mécanisme de synchronisation de thread, cette solution est utilisé avec les shaders.
    Pour les shaders tu N unité de calcul qui vont fonctionner de façon indépendante .
    Quand un vertex shader travail sur un vertex il ne peut pas interagir avec un autre vertex shader en cour d'execution et c la ou est le gain car il y a pas de synchronisation.

    Ce concept de parallélisation a un nom mais je m'en souvient pas.
    En gros on a une tache A de préparation N tache en parallèle totalement indépendante et une tache B qui s’exécute une fois que tout est terminé, pour produire un resultat.
    Ce genre de concept est par exemple idéal pour le tri fusion.

    tache A séparation de la liste en deux.
    tache en parallèle tri des deux liste (c du récursif )
    tache B fusions des deux liste.


    Ce genre de parallélisation nécessite un langage spécifique, en java c possible mais on ne peut pas garantir la non interaction des taches parallèles.
    En plus l'architecture matériel qui permet ce genre de fonctionnement est bcp est plus simple qu'un multi coeur ce qui permet pour un même prix d'avoir bcp plus d'unité de calcul.

Discussions similaires

  1. [Opinion]Que pensez vous du .net framework 10 ans après?
    Par Hinault Romaric dans le forum Général Dotnet
    Réponses: 177
    Dernier message: 02/09/2010, 15h32
  2. Réponses: 15
    Dernier message: 08/10/2009, 10h24
  3. Réponses: 2
    Dernier message: 09/03/2009, 14h14
  4. problème de positionnement 4 ans après.
    Par Ekimasu dans le forum Balisage (X)HTML et validation W3C
    Réponses: 1
    Dernier message: 30/03/2008, 17h00
  5. Pourquoi le langage D alors qu'il existe Ada ?
    Par Hibou57 dans le forum Ada
    Réponses: 3
    Dernier message: 21/02/2007, 21h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo