Question de conception

Version imprimable

09/09/2010, 02h00
lezebulon

Question de conception

Bonjour j'ai (encore) une question de C++, mais là c'est plus de la conception.

Pour simplifier, j'ai pour mon programme une classe A qui est représentée par une image, qui varie selon les argument passés au constructeur. Je cherche à ne pas "stocker" l'image dans mon objet afin que si plusieurs objets A utilisent la même image, il n'y ait qu'une seule image en mémoire dans le programme.

Comment faire? J'ai plusieurs idées mais je suis pas sûr de comprendre ce qui va se passer concrètement si je les essaie :aie::

- A priori l'idéal ça serait que j'envoie le nom de fichier de l'image dans le constructeur de A, et qu'il stocke le fichier en mémoire si il n'y est pas, et puis ensuite que de toute façon il pointe dessus par attribut. Le prob : comment je vais pouvoir gérer tout ça vu que je serai dans mon constructeur ?

- Une autre possibilité ça serait que je créé mes images par avance, et que je les envoie par référence au constructeur de A, qui lui stocke juste un pointeur... mais ça va vite être lourd à écrire et c'est pas vraiment possible à automatiser, enfin c'est pas top de devoir créer plein d'objets annexes que je vais plus ou moins paumer après et jamais m'en servir directement

- D'autre part quand je vais effacer mes éléments de la classe A, il faudrait aussi que je puisse libérer la mémoire que prend les images associées...

Bref je vois pas trop comment faire ça "proprement"... une idée?
09/09/2010, 08h38
jabbounet

pourquoi ne pas utiliser une classe dédiée qui stockerai les images dans un tableau, ou une table de hachage, et qui contrôlerai l'unicité de ces images.

Ensuite chaque classe A qui a besoin d'une image irai la demander à cette classe dédiée.
09/09/2010, 11h04
Aleph69

Bonjour,

Citation:

Envoyé par lezebulon

- A priori l'idéal ça serait que j'envoie le nom de fichier de l'image dans le constructeur de A, et qu'il stocke le fichier en mémoire si il n'y est pas, et puis ensuite que de toute façon il pointe dessus par attribut. Le prob : comment je vais pouvoir gérer tout ça vu que je serai dans mon constructeur ?

Pour cette approche, une solution possible consiste à doter ta classe A d'un conteneur global (avec le mot-clé static).
Comme cela, ton conteneur sera partagé par toutes tes instances.

Citation:

Envoyé par lezebulon

- Une autre possibilité ça serait que je créé mes images par avance, et que je les envoie par référence au constructeur de A, qui lui stocke juste un pointeur... mais ça va vite être lourd à écrire et c'est pas vraiment possible à automatiser, enfin c'est pas top de devoir créer plein d'objets annexes que je vais plus ou moins paumer après et jamais m'en servir directement

Effectivement, ça me paraît moins efficace que ta précédente solution.

Citation:

Envoyé par lezebulon

- D'autre part quand je vais effacer mes éléments de la classe A, il faudrait aussi que je puisse libérer la mémoire que prend les images associées...

Tu auras juste à ôter de ton conteneur l'image donnée par ton instance.
Attention, cela libérera la mémoire pour toutes les instances en même temps.
09/09/2010, 13h04
poukill

LA solution : un shared_ptr.
Comme ça tu n'as qu'une seule instance, c'est partagé de manière safe, et tu n'as pas de questions à te poser, ça se libère tout seul ! :ccool:
09/09/2010, 13h18
Aleph69

Bonjour,

Citation:

Envoyé par poukill

LA solution : un shared_ptr.

Pour information, ça se trouve dans boost ces petites bêtes là. :mrgreen:

Et un petit exemple d'utilisation dans la faq pour pouvoir démarrer.
09/09/2010, 14h43
poukill

C'est aussi dans le nouveau standard : std::tr1::shared_ptr
09/09/2010, 14h47
Aleph69

Ah d'accord, je n'étais pas au courant.
C'est celui de boost ou tout a été refait?
09/09/2010, 18h13
Flob90

Et surment dans std:: directement slon ton compilo et les options de compilation (header memory).

Les pointeurs intelligents sont un concept, la norme présice l'interface et les différents comportements, la facon dont ils doivent être implémentés n'est pas normalisé (comme pour tout le standard). Regardes le dernier draft si tu veus connaitre l'interface (très semblable si ce n'est identique à celle de boost/loki et autre).
09/09/2010, 18h16
Goten

Citation:

Envoyé par Aleph69

Ah d'accord, je n'étais pas au courant.
C'est celui de boost ou tout a été refait?

C'est implémentation dépendant, comme tout les composants de la STL. Mais par exemple la STL de gcc utilise celui de boost en effet oui ;).
09/09/2010, 18h20
Aleph69

Il n'y a pas d'implémentation standard du standard?! 8O

Et il y a des grosses différences connues entre les diverses implémentations?

EDIT : tiens d'ailleurs je pense à un truc.
Quand je suis passé de gcc à visual, mon bout de code manipulant NAN et INFINITY avec std::numerical_limits ne compilait plus sous visual.
Je me demande si ça ne vient pas de ça. :koi:
09/09/2010, 19h17
Goten

Citation:

Envoyé par Aleph69

Il n'y a pas d'implémentation standard du standard?! 8O

Bien sur que non, le standard spécifie des interfaces et des conditions (complexité etc).

Citation:

Et il y a des grosses différences connues entre les diverses implémentations?

Au niveau de la vitesse? non pas trop en général.
Au niveau du respect : un peu plus oui.

Citation:

EDIT : tiens d'ailleurs je pense à un truc.
Quand je suis passé de gcc à visual, mon bout de code manipulant NAN et INFINITY avec std::numerical_limits ne compilait plus sous visual.
Je me demande si ça ne vient pas de ça. :koi:

NaN n'existe pas en C++
09/09/2010, 19h24
Aleph69

Citation:

Envoyé par Goten

Au niveau du respect : un peu plus oui.

Tu as des exemples en tête.

Citation:

Envoyé par Goten

NaN n'existe pas en C++

Oui, ça je l'ai appris à mes dépends... ^^
Mais avec la distribution MinGW (installation auto avec g++ 3.4 je crois), je peux t'assurer que NAN est défini.
09/09/2010, 19h42
lezebulon

Vous pouvez m'expliquer le truc avec un shared_ptr??
Je vais quand même être obligé de créer une classe spéciale qui s'occupe de la création des images non?
Enfin admettons que je créé mon shared_ptr , il créé donc mes objets en mémoire (où ?) mais je suis toujours obligé de garder en mémoire un référence sur cet objet, si je veux ré-intanscier mon objet A avec des images déjà utilisées
09/09/2010, 22h02
Chessmaster1966

Pour confirmer et faire simple, le mieux c'est d'utiliser le mot clé "static" pour le conteneur de ton image. Ainsi fait, cette ressource sera partagée par tous les objets et quand le dernier objet sera détruit cette ressource sera forcément détruite !!!

Beaucoup se complique la vie en voulant faire des trucs tordus alors qu'il existe ce qu'il faut dans le language il faut simplement le connaître précisément !!!
09/09/2010, 22h11
Aleph69

Bonsoir,

Citation:

Envoyé par Chessmaster1966

Beaucoup se complique la vie en voulant faire des trucs tordus alors qu'il existe ce qu'il faut dans le language il faut simplement le connaître précisément !!!

Moi aussi j'aurais naturellement fait un conteneur statique mais c'est vrai qu'avec shared_ptr il va gagner en temps de développement et en fiabilité, notamment au niveau de la gestion de la mémoire.
09/09/2010, 22h17
Aleph69

Citation:

Envoyé par lezebulon

Vous pouvez m'expliquer le truc avec un shared_ptr??
Je vais quand même être obligé de créer une classe spéciale qui s'occupe de la création des images non?
Enfin admettons que je créé mon shared_ptr , il créé donc mes objets en mémoire (où ?) mais je suis toujours obligé de garder en mémoire un référence sur cet objet, si je veux ré-intanscier mon objet A avec des images déjà utilisées

Tiens, regarde ce tutoriel.

Tu pourras notamment y lire l'intérêt pour toi :

Citation:

Le modèle derrière ce pointeur est celui où plusieurs pointeurs permettent l'accès à une même donnée, sans que l'un de ceux-ci soit investi du rôle particulier consistant à être le responsable de la durée de vie de l'objet. Cette responsabilité est partagée (d'où le nom shared) entre tous les pointeurs pointant à un moment donné sur l'objet.

Comment dans ce cas la mémoire sera-elle libérée ? En fait, quand un pointeur est détruit, il vérifie s'il n'était pas le dernier à pointer sur son objet. Si c'est le cas, il détruit l'objet, puisqu'il est sur le point de devenir inaccessible. Afin de connaître cette information, un compteur de référence est associé à l'objet, à chaque fois qu'un nouveau pointeur pointe sur l'objet, le compteur de référence est incrémenté. A chaque fois que le pointeur arrête de pointer sur cet objet (parce qu'il est détruit, ou s'apprête à pointer sur un autre), le compteur est décrémenté. Si le compteur atteint 0, il est temps de détruire l'objet.
09/09/2010, 22h25
gl

Citation:

Envoyé par Chessmaster1966

Pour confirmer et faire simple, le mieux c'est d'utiliser le mot clé "static" pour le conteneur de ton image. Ainsi fait, cette ressource sera partagée par tous les objets et quand le dernier objet sera détruit cette ressource sera forcément détruite !!!

Et si deux objets de types A utilisent deux images différentes !

Le problème avec "shared_ptr" c'est qu'il n'existe pas dans tous les languages.

J'utilise Code::Blocks avec gcc 3.4.5 et il n'existe pas !

Mais je ne vois pas où c'est compliqué que de charger en mémoire une image
puis de faire de cette zone une zone statique partagée par tous les objets.

Voici le code avec le mot clé static :
Code:

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 27 28 29 30 31 32 class A { static string TonImage; public: A(string Image) { if(TonImage == "") TonImage = Image; } string GetImage(){return TonImage;} }; string A::TonImage=""; int main() { A *a1 = new A("Paysage sous-marin"); cout << "Objet 'a1' : " << a1->GetImage() << '\n'; A *a2 = new A("Paysage de montagne"); cout << "Objet 'a2' : " << a2->GetImage() << '\n'; A *a3 = new A("Paysage de foret"); cout << "Objet 'a3' : " << a3->GetImage() << '\n'; system("pause"); return 0; }

09/09/2010, 23h31
Chessmaster1966

Citation:

Envoyé par gl

Et si deux objets de types A utilisent deux images différentes !

Ce n'est pas le sujet du problème de : lezebulon
09/09/2010, 23h47
Aleph69

Citation:

Envoyé par Chessmaster1966

Ce n'est pas le sujet du problème de : lezebulon

Il y en a un de nous deux qui n'a pas compris la question de départ. :koi:
Il me semble en effet que deux instances peuvent avoir deux images différentes dans le problème.
La question porte surtout sur la manière dont gérer le fait que deux images peuvent avoir la même image.
Ta solution de passer par du static est acceptable dans la mesure où cette donnée static contient plusieurs images.
10/09/2010, 01h30
Chessmaster1966

Citation:

Envoyé par Aleph69

Il y en a un de nous deux qui n'a pas compris la question de départ. :koi:
Il me semble en effet que deux instances peuvent avoir deux images différentes dans le problème.
La question porte surtout sur la manière dont gérer le fait que deux images peuvent avoir la même image.
Ta solution de passer par du static est acceptable dans la mesure où cette donnée static contient plusieurs images.

Je suis d'accord, l'objet A contient diverses images chaque image doit exister qu'une seule fois en mémoire, Ok.

Pour la réponse que j'ai donnée effectivement je n'ai utilisé qu'une seule image mais là n'est pas le problème c'était juste pour montrer comment faire si il faut gérer plusieurs images statiques il faut créer un tableau d'images. Selon l'argument passé au constructeur l'image spécifique à un objet A sera utilisée.

Dans ma méthode il n'y a aucun problème, alors le pointeur shared_ptr pas d'utilité surtout qu'il n'est pas implémenter dans tous les compilateurs, comment on faisait avant l'arrivée de se fameux pointeur !!!

Et voici le code dans son intégralité pour gérer plusieurs images d'une classe dont il existe qu'une seule instance de chacune pour tous objets.

L'usage du mot clé statique ne pose aucun problème et c'est très facile.

Code:

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
 
class A
{
 
    static string *Images[];
    string Image;
    static int c;
    void LoadImages()
    {
        Images[0] = new string("Image1");
        Images[1] = new string("Image2");
        Images[2] = new string("Image3");
    }
    public:
        A(int IndexImage)
        {
 
            if(c == -1)
                 LoadImages();
 
            ++c;
 
            Image = *Images[IndexImage];
 
        }
        ~A()
        {
 
            --c;
 
            if( c == -1)
            {
                delete Images[2];
                delete Images[1];
                delete Images[0];
            }
        }
 
        string GetImage(){return Image;}
};
 
int A::c=-1;
string *A::Images[3];
 
int main()
{
 
    A *a1 = new A(1);
    cout << "Objet 'a1' : " << a1->GetImage() << '\n';
    A *a2 = new A(2);
    cout << "Objet 'a2' : " << a2->GetImage() << '\n';
    A *a3 = new A(0);
    cout << "Objet 'a3' : " << a3->GetImage() << '\n';
    delete a1;
    delete a2;
    delete a3;
 
    system("pause");
    system("cls");
 
    A *a4 = new A(0);
    cout << "Objet 'a4' : " << a4->GetImage() << '\n';
    A *a5 = new A(1);
    cout << "Objet 'a5' : " << a5->GetImage() << '\n';
    A *a6 = new A(2);
    cout << "Objet 'a6' : " << a6->GetImage() << '\n';
    A *a7 = new A(2);
    cout << "Objet 'a7' : " << a7->GetImage() << '\n';
    delete a4;
    delete a5;
    delete a6;
    delete a7;
 
 
    system("pause");
 
    return 0;
 
}

Citation:

Envoyé par Chessmaster1966

Ce n'est pas le sujet du problème de : lezebulon

Ah ! Et pourquoi ?

Citation:

Envoyé par Chessmaster1966

Le problème avec "shared_ptr" c'est qu'il n'existe pas dans tous les languages.

J'utilise Code::Blocks avec gcc 3.4.5 et il n'existe pas !

Qu'il n'existe pas dans tous les langages, à priori on s'en moque un peu. Ici il est question de C++.

Qu'il n'existe pas dans toutes les versions de C++ est effectivement un peu plus gênant.

Note tout de même que les shared_ptr font parti de Boost et du TR1 depuis maintenant assez longtemps.

Au passage, gcc 3.4.5 date maintenant de 5 ans, il y a eu bon nombre de version de gcc depuis et notamment un changement de version majeur. Et code::blocks fournie maintenant gcc 4.5.0.
Citation:
Envoyé par Chessmaster1966
Et voici le code dans son intégralité pour gérer plusieurs images d'une classe dont il existe qu'une seule instance de chacune pour tous objets.

L'usage du mot clé statique ne pose aucun problème et c'est très facile.
Code:

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 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 class A { static string *Images[]; string Image; static int c; void LoadImages() { Images[0] = new string("Image1"); Images[1] = new string("Image2"); Images[2] = new string("Image3"); } public: A(int IndexImage) { if(c == -1) LoadImages(); ++c; Image = *Images[IndexImage]; } ~A() { --c; if( c == -1) { delete Images[2]; delete Images[1]; delete Images[0]; } } string GetImage(){return Image;} }; int A::c=-1; string *A::Images[3]; int main() { A *a1 = new A(1); cout << "Objet 'a1' : " << a1->GetImage() << '\n'; A *a2 = new A(2); cout << "Objet 'a2' : " << a2->GetImage() << '\n'; A *a3 = new A(0); cout << "Objet 'a3' : " << a3->GetImage() << '\n'; delete a1; delete a2; delete a3; system("pause"); system("cls"); A *a4 = new A(0); cout << "Objet 'a4' : " << a4->GetImage() << '\n'; A *a5 = new A(1); cout << "Objet 'a5' : " << a5->GetImage() << '\n'; A *a6 = new A(2); cout << "Objet 'a6' : " << a6->GetImage() << '\n'; A *a7 = new A(2); cout << "Objet 'a7' : " << a7->GetImage() << '\n'; delete a4; delete a5; delete a6; delete a7; system("pause"); return 0; }
Même en passant sur le style (utilisation de tableau C-like, appel à new/delete, etc.) qui n'est pas l'objet de la question ici :

Tu as en mémoire toutes les images même celles qui ne sont pas utilisées.
Tu es obligé de modifier la classe A à chaque que tu veux rajouter une nouvelle image (il était question de passer le nom en paramètre du constructeur).
Ne parlons même pas des problèmes de thread-safety et d'exception-safety

10/09/2010, 10h16
jabbounet

Il faut aussi être capable d'identifier les doublons pour ne pas les charger deux fois.
On ne connait pas non plus la volumétrie (nombre d'image à charger)

Quid d'une table de hachage dans une classe qui en protèges les accès?

la clé serait le nom de l'image, la donnée un pointeur vers l'image (eventuellement shared_ptr ou autre)
10/09/2010, 19h03
Chessmaster1966
Citation:
Envoyé par gl

Ah ! Et pourquoi ?

Qu'il n'existe pas dans tous les langages, à priori on s'en moque un peu. Ici il est question de C++.

Qu'il n'existe pas dans toutes les versions de C++ est effectivement un peu plus gênant.

Note tout de même que les shared_ptr font parti de Boost et du TR1 depuis maintenant assez longtemps.

Au passage, gcc 3.4.5 date maintenant de 5 ans, il y a eu bon nombre de version de gcc depuis et notamment un changement de version majeur. Et code::blocks fournie maintenant gcc 4.5.0.

Même en passant sur le style (utilisation de tableau C-like, appel à new/delete, etc.) qui n'est pas l'objet de la question ici :

Tu as en mémoire toutes les images même celles qui ne sont pas utilisées.
Tu es obligé de modifier la classe A à chaque que tu veux rajouter une nouvelle image (il était question de passer le nom en paramètre du constructeur).
Ne parlons même pas des problèmes de thread-safety et d'exception-safety
Le code que j'ai présenté n'était qu'un exemple (imparfait, peut-être !) afin de démontrer l'usage du mot clé "static" pour gérer l'information unique commune à plusieurs objets, c'est tout. Je crois que c'est ce que voulez lezebulon avoir quelques idées après il choisira ce qui lui convient le plus.

N'essayez plus de descendre mes codes (vous perdez votre temps) que je présente en précisant tel ou tel problème j'essayes de les faire simple pour que le débutant puisse comprendre et le but c'est de ne pas se lancer dans la conception pur et dur pour un exemple, je le répète c'était jsute l'exemple.

J'accepte la critique sans problème puisque elle permet de se corriger et donc de s'améliorer !!!

De toute manière tout code sera critiqué et chacun à son style ! Le but c'est qu'au final tout fonctionne bien et sans bugs pour un programme c'est cela le plus important.

Le traitement des doublons, le nombre d'images à gérer, est-ce qu'il faut toutes les charger en mémoire ou bien gérer uniquement les noms puis charger l'image ad-hoc tout cela bien entendu doit traité. C'est une réflexion plus poussée et donc de l'ajout de code à mon exemple initial. Le but d'un exemple c'est de montrer la voie et rien que cela !!!

Pour ma part je pense que les débutants ont besoin d'avoir des exemple de code opérationnel pour qu'il puisse mieux comprendre et les tester chez eux.
Après il a apportera ou non les améliorations nécessaires, libre à lui.
10/09/2010, 19h11
Flob90

La solution propre et clair au problème c'est les pointeurs intelligents, si ton compilateurs les gère pas : change le il est trop ancien.

Citation:

N'essayez plus de descendre mes codes (vous perdez votre temps) que je présente en précisant tel ou tel problème j'essayes de les faire simple pour que le débutant puisse comprendre et le but c'est de ne pas se lancer dans la conception pur et dur pour un exemple, je le répète c'était jsute l'exemple.

Oui, à part qu'inciter à utiliser des variable statique comme ca c'est la porte ouverte à n'importe quoi : problème de l'ordre d'initialisation et de destruction notament. Tu les aurais "encapsuler" dans une fonction ca aurait déjà été un peu mieux. Autant donné de bonnes pratiques directement. (et les pointeurs intelligents en est une).
10/09/2010, 19h46
Chessmaster1966

Citation:

Envoyé par Flob90

La solution propre et clair au problème c'est les pointeurs intelligents, si ton compilateurs les gère pas : change le il est trop ancien.

Oui, à part qu'inciter à utiliser des variable statique comme ca c'est la porte ouverte à n'importe quoi : problème de l'ordre d'initialisation et de destruction notament. Tu les aurais "encapsuler" dans une fonction ca aurait déjà été un peu mieux. Autant donné de bonnes pratiques directement. (et les pointeurs intelligents en est une).

Je continue de penser que l'usage de "static" n'est pas la porte ouverte à n'importe quoi, c'est de la responsabilité du programmeur de bien gérer ce qu'il fait.

Il faut vivre avec son temps et profiter de toute amélioration du language, je suis d'accord. Mais je pense aussi qu'il est important de connaître un maximum de choses même anciennes du langage que l'on utilise afin d'avoir le plus de liberté possible, je pense qu'il ne faut rien rejeter !

A chacun son style de développement. Chaque code de toute manière trouvera son détracteur !!!

Le but pour le programmeur c'est avant tout de bien comprendre ce qu'il fait avec son code (ancien ou moderne) afin de savoir ce qui se passe en coulisse. Pour les questions de performance utiliser ceci ou cela aujourd'hui avec la puissance des ordi. la marge est insignifiante.

Pour ce qui est de bonne pratique de développement à chacun son style le plus important c'est que le code soit le plus simple possible pour une efficacité optimale.
10/09/2010, 19h56
jabbounet

Citation:

Envoyé par Chessmaster1966

Il faut vivre avec son temps et profiter de toute amélioration du language, je suis d'accord. Mais je pense aussi qu'il est important de connaître un maximum de choses même anciennes du langage que l'on utilise afin d'avoir le plus de liberté possible, je pense qu'il ne faut rien rejeter !

les variables statique (et aussi globale) ont probablement été les premières a exister dans le monde informatique car beaucoups plus facile à gérer du point de vu du procésseur.

je ne sais pas si tu as connu les première calculatrices programmable par exemple mais tu avais dessus un nombre limité de variable avec un nom fixe ou tu pouvais stocker les donnée avec des instruction.

25 STO 1 pour stocker 25 dans la variable 1.

bien plus tard sont apparu les concept plus evolué telle que le code relogeable les mémoire paginées (avec les short et far pointer), la réentrance.....
10/09/2010, 21h50
gl

Citation:

Envoyé par Chessmaster1966

N'essayez plus de descendre mes codes (vous perdez votre temps) que je présente en précisant tel ou tel problème j'essaye de les faire simple pour que le débutant puisse comprendre et le but c'est de ne pas se lancer dans la conception pur et dur pour un exemple, je le répète c'était juste l'exemple.

Mon but n'était pas de descendre ton code. Mais simplement d'indiquer les limites et faiblesses de la méthode proposée. Ce qui me semble important.
13/09/2010, 11h16
bacelar

Citation:

chacun son style le plus important c'est que le code soit le plus simple possible

Il faut aussi progresser dans la qualité de son codage.
La qualité d'un code est quelque chose qui évolue dans le temps, en fonction de l'évolution de l'informatique. :aie:
13/09/2010, 21h01
Chessmaster1966

Citation:

Envoyé par bacelar

Il faut aussi progresser dans la qualité de son codage.
La qualité d'un code est quelque chose qui évolue dans le temps, en fonction de l'évolution de l'informatique. :aie:

Bien sûr qu'il faut progresser dans la qualité de son codage, je suis entièrement d'accord sur ce point et c'est une chose essentielle et c'est pour cela que j'ai appris le C++ que je trouve formidable, j'en suis fou amoureux, un passionné !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

La norme C++0x qui introduit les pointeurs shared_ptr qui (je crois) n'est pas implémenté dans tous les compilateurs et puis il ne faut pas dénigrer les membres "static" combien même il y a des pointeurs shared_ptr.

Mais c'est vrai, parfois je suis en peu provocateur. C'est juste pour voir la réaction des uns et des autres afin que les débutants puisse mieux se faire une idée de toute stratégie de développement dont il est question ici !
13/09/2010, 21h57
gl

Citation:

Envoyé par Chessmaster1966

La norme C++0x qui introduit les pointeurs shared_ptr qui (je crois) n'est pas implémenté dans tous les compilateurs

Les shared_ptr sont déjà présents dans TR1.

Quant à la norme "C++0x" (qui s'appellera plus probablement C++11 ou C++12), elle n'est effectivement pas implémentée dans tous les compilateurs, ce qui n'est pas surprenant puisqu'elle n'est pas finalisée.
13/09/2010, 23h13
Flob90

Si t'as un compilateur sans shared_ptr<>, il est grand tant d'en changer.

Quand à dénigrer les static pour les shared_ptr, ca n'a aucun sens, ils n'ont pas le même objectif, il ne sont pas alternable.
14/09/2010, 02h04
koala01

Salut,

Citation:

Envoyé par Chessmaster1966

La norme C++0x qui introduit les pointeurs shared_ptr qui (je crois) n'est pas implémenté dans tous les compilateurs et puis il ne faut pas dénigrer les membres "static" combien même il y a des pointeurs shared_ptr.

Les shared_ptr sont introduit dans le TR1, qui date quand même de plus de 5 ans :P.

De plus il n'a jamais été question de dénigrer les variables statiques, il a été question de tirer un signal d'alarme normal à leur sujet:

Une variable statique et une variable globale, c'est exactement pareil, même si la variable statique est un peu "enrobée" par rapport à la variable globale: Tout comme il y a de bonnes raisons d'éviter le recours à une variable globale, il y a de bonnes raisons (qui sont à peu de chose près les mêmes d'ailleurs) pour éviter le recours à une variable statique.

D'ailleurs, c'est bien simple: Un cas classique d'utilisation de variable statique est la mise au point du pattern "singleton", or, si l'on ne remet pas en question l'utilité de ce pattern, il faut avouer que le meilleur moyen pour n'avoir jamais qu'une instance d'une classe, c'est encore de veiller à ... ce qu'elle ne soit créée qu'une seule fois :D

Lorsque tu peux te contenter "simplement" de récupérer un pointeur depuis le retour d'une fonction pour l'injecter dans une autre, il n'y a rien à faire, les shared_ptr te libèrent de la problématique qui consiste à devoir déterminer le moment le plus opportun pour libérer la mémoire allouée à l'objet pointé.

La polémique entre l'utilisation d'un shared_ptr et celle d'une variable statique n'a purement et simplement pas lieu d'être parce que ce sont deux possibilités données pour des circonstances tout à fait distinctes et non intervertibles (mais éventuellement associables ;))