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

Débats sur le développement - Le Best Of Discussion :

Pour ou Contre le Garbage Collector ?


Sujet :

Débats sur le développement - Le Best Of

  1. #41
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par davcha
    J'ai l'impression que deneb se concentre beaucoup sur la question de savoir ce que permet un GC que ne permet pas une gestion manuelle de la mémoire.

    A priori, le débat me semble un peu creu, dans la mesure où les langages dignes de ce nom sont turning complet.

    La question n'est donc pas de savoir ce qui peut ou ne peut pas être fait, mais plutôt si le GC ou la gestion manuelle de la mémoire permettent de programmer plus "proprement", efficacement.
    Encore que "proprement"... Ce terme est suffisamment vague pour que quelqu'un vienne dire que l'utilisation d'un GC n'est pas propre ou inversement que la gestion manuelle de la mémoire peut devenir une usine à gaz, sans pour autant amener d'arguments valables.

    Personnellement, je programme principalement en C# et C++.
    Je trouve le GC du C# très intéressant, car il augmente ma productivité. Et quand j'ai des parties de code où la gestion de la mémoire est critique (que ce soit pour des questions de perf ou de minimalisations d'utilisation mémoire), je passe en C++, où je gère la mémoire directement, sans GC.

    Je vois pas tellement le problème en fait. Il y a des cas où le GC est super, d'autres où une gestion manuelle est préférable...
    Voila un avis que je partage parfaitement...
    Le pb c'est qu'en Java c'est GC obligatoire.
    Ou alors on inclue des lib natives, mais ça pose beaucoup d'autres problèmes.

  2. #42
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par adiGuba
    Je te renvoit ta remarque, puisque le code exact et complet est le suivant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
        /**
         * Initializes a newly created <code>String</code> object so that it
         * represents the same sequence of characters as the argument; in other
         * words, the newly created string is a copy of the argument string. Unless 
         * an explicit copy of <code>original</code> is needed, use of this 
         * constructor is unnecessary since Strings are immutable. 
         *
         * @param   original   a <code>String</code>.
         */
        public String(String original) {
        int size = original.count;
        char[] originalValue = original.value;
        char[] v;
          if (originalValue.length > size) {         // The array representing the String is bigger than the new
             // String itself.  Perhaps this constructor is being called
             // in order to trim the baggage, so make a copy of the array.
            v = new char[size];
             System.arraycopy(originalValue, original.offset, v, 0, size);
         } else {         // The array representing the String is the same
             // size as the String, so no point in making a copy.
            v = originalValue;
         }
        this.offset = 0;
        this.count = size;
        this.value = v;
        }
    Il y a bien une copie du tableau de char représentant la String
    Relis bien...dans un cas il copie, dans l'autre il pointe sur la tableau d'origine...
    Encore plus fun
    Citation Envoyé par adiGuba
    Ce constructeur (à la C++) alloue encore plus de mémoire inutilement...
    Si cela ne te sastifait pas, c'est que ce serait trop dur à gérer sans GC...
    L'économie n'existe pas seulement en ce qui concerne les String puisqu'il existe d'autre classe immuable.
    C'est vrai que c'est totalement inutile... c'est d'ailleurs indiqué dans la doc !
    Si tu as des chances de chargé plusieurs fois les mêmes chaines, tu peux économiser la mémoire en utilisant la méthode intern() qui utilise un cache de String...

    Ensuite l'économie de l'immuabilité vient [...]
    T'inquiètes j'ai bien compris l'objectif des immuables, même si je n'adhère pas au concept.
    Citation Envoyé par adiGuba
    En C++ le moindre passage d'objet à une méthode implique une copie de l'objet. A moins de passer via les références, mais dans ce cas il faudrait faire une copie explicite pour éviter qu'un attribut ne soit modifié en dehors de la classe...
    A toi de gérer au cas par cas...C'est vrai qu'on se pose souvent la question : valeur/référence...au début

    Citation Envoyé par adiGuba
    Les classes immuables sont une notion importante de Java, et peu présente en C++. Cela fait un approche relativement différente de la conception des objets...
    Exact...dommage qu'on ne puisse pas profiter du meilleur des deux mondes.

  3. #43
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Points : 1 539
    Points
    1 539
    Par défaut
    Citation Envoyé par deneb
    Le pb c'est qu'en Java c'est GC obligatoire.
    Là, ça fait un bel argument en faveur du C#, par rapport à Java du coup.

  4. #44
    Membre à l'essai
    Inscrit en
    Juillet 2006
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : Juillet 2006
    Messages : 15
    Points : 20
    Points
    20
    Par défaut
    Citation Envoyé par deneb
    Mais non, j'ai des pb liés au GC alors que je considère qu'il ne m'apporte rien.

    Justement je bosse sur des appli serveur où le temps pris par le GC est pénalisant.
    Et bien si le GC n'apporte rien au type de programme que tu fais, ne l'utilises pas

    Tu ne vois pas l'interêt dans le cas d'une application client ?

    Citation Envoyé par deneb
    T'inquiètes j'ai bien compris l'objectif des immuables, même si je n'adhère pas au concept.
    Là ou les immuables sont pratiques c'est quand on souhaite passer un objet en paramètres à une fonction.
    Il arrive souvent qu'on ne puisse pas se permettre de lui passer son objet.
    On peut passer une copie mais c'est couteux une instanciation, surtout dans une boucle !

    Un objet immuable est parfait pour cela.
    Et c'est comme ça que je les utilises.

  5. #45
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Dans un langage qui ne supporte pas la const-correctness, les types immuables facilitent grandement la tâche en effet. Leur inconvénient, c'est que les types référence immuables nécessitent un GC pour être utilisables sans se prendre la tête avec les fuites.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  6. #46
    mat.M
    Invité(e)
    Par défaut
    Citation Envoyé par deneb

    J'ai aussi utilisé un GC en C++ dans mon jeune temps et la conclusion fut la même...merdique, inutile, gaspillage de ressources et pire que tout : source de memory leak !!!
    Le GC peut être un avantage mais aussi un inconvénient ; la mémoire est fragmentée inutilement donc perte de performances possibles.

    Citation Envoyé par adiGuba
    Le problème est un peu différent : Java et le GC utilise une zone mémoire nommé heap. Par défaut elle vaut 2 Mo et ne peut utiliser au maximum que 64 Mo. Si une application utilise plus de 64Mo on obtiendra une exception même si le système d'exploitation possèdent encore plein de mémoire libre (il faut spécifier une taille maximum plus grande au lancement de l'application pour résoudre cela) ! C'est une notion spécifique à Java et non pas au GC.
    Du coup si une application doit utiliser beaucoup de données (64 Mo ce n'est pas énorme de nos jours) elle se retrouve vite à l'étroit...
    C'est quelque chose que je ne savais pas; quel est l'intérêt de programmer avec un langage qui ne permet pas d'allouer + de 64Mo ?
    Comment tu fais si par exemple tu veux faire du traitement d'image sur des grosses images ?
    Faut-il se cantonner aux API toutes faites du SDK de la JVM ( io.graphics ) ?

  7. #47
    mat.M
    Invité(e)
    Par défaut
    Citation Envoyé par deneb
    Par contre pour le GC, je vois pas.
    Habitués à laisser le GC gérer la mémoire, les devs ne s'en occupent pas, il la gaspillent. Résultat, je dois acheter plus de RAM pour mes serveurs. Perte de fric.
    C'est certain que tout ce qui est architecture Java ou .NET cela demande plus de ressources matérielles donc crédits supplémentaires à allouer pour acheter des machines plus puissantes.
    Rien qu'à voir la taille du framework .NET....

  8. #48
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    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 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par mat.M
    C'est quelque chose que je ne savais pas; quel est l'intérêt de programmer avec un langage qui ne permet pas d'allouer + de 64Mo ?
    Comment tu fais si par exemple tu veux faire du traitement d'image sur des grosses images ?
    C'est la valeur maximum par défaut ! Tu peux très simplement augmenter cette valeur avec l'option -Xmx de java lorsque tu lances ton application...

    a++

  9. #49
    mat.M
    Invité(e)
    Par défaut
    ok merci du renseignement

  10. #50
    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 Médinoc
    Dans un langage qui ne supporte pas la const-correctness, les types immuables facilitent grandement la tâche en effet. Leur inconvénient, c'est que les types référence immuables nécessitent un GC pour être utilisables sans se prendre la tête avec les fuites.
    Ils permettent aussi d'esquiver le Copy-On-Write (aka COW) si je ne m'abuse. Côté implémentaton, un pointeur intelligent à comptage de référence (que l'on doit pouvoir rendre atomiques) est très bien tant que tu n'as pas de cycles entre plusieurs objets non mutables.
    Mais, ne se retrouve-t-on pas à faire un fois deux à maintenir une version modifiable et une non-modifiable ?
    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...

  11. #51
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    C'est vrai qu'on voit rarement une classe String sans la classe StringBuffer(java) ou StringBuilder(.Net) qui va avec. Il est clair que le second inconvénient des types immuables est qu'il faut en créer un nouveau à chaque modification, et une allocation mémoire, c'est pas trop ce qu'il y a de plus rapide...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  12. #52
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    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 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Médinoc
    C'est vrai qu'on voit rarement une classe String sans la classe StringBuffer(java) ou StringBuilder(.Net) qui va avec. Il est clair que le second inconvénient des types immuables est qu'il faut en créer un nouveau à chaque modification, et une allocation mémoire, c'est pas trop ce qu'il y a de plus rapide...
    C'est pourquoi il y a les classes StringBuffer et StringBuilder (au passage : les deux existent sous Java 5.0 - l'une étant thread-safe ). Si tu dois faire plusieurs modifications sur une String, cela permet d'éviter d'effectuer plusieurs allocations...

    En même temps, je pense qu'il est quand même préférable de ne faire une allocation qu'à chaque modification, plutôt que pour chaque utilisation.


    Prenons le cas d'une String qui sera utilisé dans 5 classes, dont une utilisera une version modifié (on dira en minuscule).

    Avec un GC et le pattern immuable : tu n'auras alloué que 2 instances de String (voir une seule si la String est déjà en minuscule).
    Sans GC et avec des classes muables, tu devras allouer une instance par classe, pour éviter les modifications depuis l'extérieur. Tu auras donc 5 allocations au minimum...



    La plupart des problèmes avec le GC viennent de méconnaissance de son principe, et de la notion d'immuabilité...

    L'exemple le plus frappant est l'utilisation de l'opérateur + sur les chaines, qui crée une nouvelle instance de String, et qui peut être catastrophique s'il est utilisé dans une boucle. Exemple avec le code suivant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
            int max = 50000;
            long t0,t1;
            
            t0 = System.currentTimeMillis();
            String string1 = "";
            for (int i=0; i<max; i++) {
                string1 += "a";
            }
            t1 = System.currentTimeMillis();
            System.out.println("String1 : " + string1.length() + " caractères en " + (t1-t0) + " ms...");
            
            
            
            t0 = System.currentTimeMillis();
            StringBuffer buffer = new StringBuffer();
            for (int i=0; i<max; i++) {
                buffer.append("a");
            }
            String string2 = buffer.toString();
            t1 = System.currentTimeMillis();
            System.out.println("String1 : " + string2.length() + " caractères en " + (t1-t0) + " ms...");
    Qui donne une grosse différence comme résultat :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    String1 : 50000 caractères en 18312 ms...
    String2 : 50000 caractères en 16 ms...
    Puisque dans le premier cas le GC alloue un grand nombre d'objet temporaire de manière implicite...
    En effet pour créer une chaine de 50000 char (soit 100Ko en mémoire puisque les char en java sont sur 2 octets), le GC aura en fait allouer plus d'1 milliard de char, soit plus de 2Go de mémoire...

    Ca fait mal

  13. #53
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Sans GC et avec des classes muables, tu devras allouer une instance par classe, pour éviter les modifications depuis l'extérieur. Tu auras donc 5 allocations au minimum...
    Sans GC ni const-correctness... C'est pourquoi en C++, avec des std::string parfaitement modifiables, on arrive à n'allouer que deux strings également (mais c'est un poil plus long, car il faut d'abord copier la string et modifier la copie : En java, on peut faire la modification à la volée lors de la copie).

    Pour le reste, je suis d'accord.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  14. #54
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    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 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Médinoc
    Sans GC ni const-correctness... C'est pourquoi en C++, avec des std::string parfaitement modifiables, on arrive à n'allouer que deux strings également (mais c'est un poil plus long, car il faut d'abord copier la string et modifier la copie : En java, on peut faire la modification à la volée lors de la copie).
    Pas tout à fait : le const-correctness est très bien pour passer des paramètres à une méthode sans qu'il ne soit modifié et sans devoir en créer une nouvelle instance...

    Mais s'il s'agit d'attribut de classe, il faut alors en faire une copie pour éviter que l'attribut ne soit modifier en dehors de la classe, par exemple avec le code C++ suivant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    std::string id = "azerty";
    MyClass instance(id);
    std::transform( id.begin(), id.end(), id.begin(), toupper );
    Si on ne copie pas id dans son contructeur de MyClass, on modifie sa valeur sans utiliser d'accesseur et on peut casser l'intégrité de l'objet... donc const ne sert à rien dans ce cas.


    Maintenant, je ne pense pas qu'il y ai de grosse différence entre les deux, et que cela ne doti se voir que dans les cas extrêmes. Toutefois le GC facilite grandement les choses...

    a++

  15. #55
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Je n'ai pas testé, mais je vois une faille d'ici : Si tu as une référence const vers l'objet (ou un objet const), id.begin() te renverra un const_iterator, donc std::transform ne pourra pas modifier la chaîne...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  16. #56
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    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 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Médinoc
    Je n'ai pas testé, mais je vois une faille d'ici : Si tu as une référence const vers l'objet (ou un objet const), id.begin() te renverra un const_iterator, donc std::transform ne pourra pas modifier la chaîne...
    Si j'avais déclaré ceci oui :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    const std:string id = "azerty";
    Mais pas si le const est utilisé dans le paramètre du constructeur seulement :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    MyClass::MyClass (const std::string& id) {
        ...
    }
    id ne pourrait pas être modifié à l'intérieur de la classe MyClass, mais cela reste possible en dehors de la classe, d'où le problème...

    a++

    PS : en même temps mes souvenirs de C++ ne sont plus très bon donc je peux très bien me tromper...

  17. #57
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Ah pardon, c'est moi qui n'avais pas compris ton précédent post
    Oui, pour ce genre de choses, l'objet a tout intéret à contenir une copie.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  18. #58
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    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 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Médinoc
    Ah pardon, c'est moi qui n'avais pas compris ton précédent post
    Ok sur le coup tu m'a un peu mis le doute quand même

    Citation Envoyé par Médinoc
    Oui, pour ce genre de choses, l'objet a tout intéret à contenir une copie.
    De ce point de vue là on a deux philosophies différentes :
    • Sans GC on fait des copies préventives.
    • Avec un GC ET des classes immuables, on ne fait la copie que lorsque c'est néccessaire.
    a++

  19. #59
    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 adiGuba
    Avec un GC et le pattern immuable : tu n'auras alloué que 2 instances de String (voir une seule si la String est déjà en minuscule).
    Sans GC et avec des classes muables, tu devras allouer une instance par classe, pour éviter les modifications depuis l'extérieur. Tu auras donc 5 allocations au minimum...
    Ce que tu appelles pattern immuable est parfaitement applicable sans GC. Un simple comptage de références suffit.

    Citation Envoyé par adiGuba
    L'exemple le plus frappant est l'utilisation de l'opérateur + sur les chaines, qui crée une nouvelle instance de String, et qui peut être catastrophique s'il est utilisé dans une boucle. Exemple avec le code suivant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    string1 += "a";
     ....
    buffer.append("a");
    C'est donc pour ça que j'avais des codes C++ illisibles truffés d'append()... Des codeurs étaient passés par la case java.


    Citation Envoyé par adiGuba
    Citation Envoyé par Medinoc
    Je n'ai pas testé, mais je vois une faille d'ici : Si tu as une référence const vers l'objet (ou un objet const), id.begin() te renverra un const_iterator, donc std::transform ne pourra pas modifier la chaîne...
    Si j'avais déclaré ceci oui :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    const std::string id = "azerty";
    À peu près 70% de mes chaines, et 85% de mes autres données vivant sur la pile sont déclarées const. C'est sûr, c'est un peu plus long à écrire. Mais cela apporte d'autres avantages en termes d'expressivité.

    Citation Envoyé par adiGuba
    Mais pas si le const est utilisé dans le paramètre du constructeur seulement :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    MyClass::MyClass (const std::string& id) { ... }
    id ne pourrait pas être modifié à l'intérieur de la classe MyClass, mais cela reste possible en dehors de la classe, d'où le problème...
    (Tiens, j'ai lu ça il n'y a pas longtemps)
    C'est un faux problème. D'abord, il n'intervient que dans deux cas et si on oublie un détail important.
    - si on est dans un environnement thréadé et que le paramètre réel peut évoluer dans un autre thread -- si on se fait piéger par ça, alors l'appli a très certainement des problèmes plus sérieux de la famille des lecteurs/écrivains
    - si on stocke une référence sur ce qui arrive depuis le constructeur d'un objet qui va vivre plus longtemps que la chaîne reçue.
    - quand on oublie que les chaines ont avant tout une sémantique de valeur en C++

    Avec un GC ET des classes immuables, on ne fait la copie que lorsque c'est néccessaire.
    Le GC est ici un détail d'implémentation. Les classes immuables dont tu parles non besoin que d'une seule chose : un moyen de partager la zone mémoire où sont stockées les données (caractères pour les chaînes). Je vois au moins trois moyens d'y parvenir :
    - GC, certes
    - comptage de références
    - zone mémoire qui a une durée de vie bien plus importante que les données "immuables". Une implémentation typique qui est vieille au moins comme le C, ce sont les chaînes constantes litérales.
    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...

  20. #60
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 584
    Points : 1 374
    Points
    1 374
    Par défaut
    Rapidement, quelques mauvais souvenirs de C++ :
    - mauvaise allocation : taille d'un objet dépassant sa taille allouée. Conséquence : l'objet débordait sur un autre pour fonctionner. Du coup l'objet en partie écrasée ne fonctionnait plus bien. On a cherché pendant des heures ce qui n'allait pas dans notre code sur ce sacré objet (une simple boîte aux lettres) avant de comprendre. Erreur que je préfère éviter à l'avenir !
    - pile augmentant sans cesse, tuant toute mon appli et pénalisant sacrément mon OS..

    Ce ne fut que sur des programmes simples... Je ne parle pas du dépassement de pile, qui certes ne m'est jamais arrivé mais m'a l'air fort fréquent et porte ouverte à bien des attaques...

    Mauvais souvenirs en Java :
    - taille de la heap trop faible. Conséquent : des erreurs "OutOfMemory" (facile à capter non ?). Correction : augmenter la heap et basta.

    Maintenant c'est clairement une simple expérience, mais bon...

    Par ailleurs, si on parle beaucoup des inconvénients du GC, on ne parle pas assez de ces avantages, qui sont notamment une gestion optimisée de la mémoire permettant des gains notables, et ce en 2 temps : lors de la compilation, les objets peuvent être réorganisés pour de meilleures perfs, lors de l'éxécution au lieu de bosser au niveau "unitaire" d'un objet le GC peut bosser avec des blocs d'objets, ce qui est bien plus rapide.

    Au final, perso, je ne suis pas développeur "expert" et pourtant je fais du dev. Autour de moi, il y a bien un expert (et encore, il est plus architecte), mais sinon il n'y a que des jeunes développeurs (donc non experts). Du coup je pense qu'un GC a toute sa place : on limite vachement les risques en perdant très peu (voir rien : temps de dév plus cours, pas de prise de tête...). Et c'est d'un intérêt certain dans un programme professionnel.
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

Discussions similaires

  1. Garbage collector en C++, pour ou contre ?
    Par Klaim dans le forum C++
    Réponses: 70
    Dernier message: 05/08/2010, 15h03
  2. Le Garbage collector est-il fait pour cela ?
    Par macRiaz dans le forum Android
    Réponses: 16
    Dernier message: 24/02/2010, 01h01
  3. Réponses: 12
    Dernier message: 29/06/2009, 08h20
  4. Réponses: 1
    Dernier message: 03/06/2009, 01h25

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