Discussion :

[Chessmaster1966]

Il y en a un de nous deux qui n'a pas compris la question de départ.
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 !!!

[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 :

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
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;
 
}

[gl]

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

Ah ! Et pourquoi ?

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.

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 :

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
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

[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)

[Chessmaster1966]

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.

[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.

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).

[Chessmaster1966]

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.

[jabbounet]

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.....

[gl]

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.

[bacelar]

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.

[Chessmaster1966]

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.

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 !

[gl]

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.

[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.

[koala01]

Salut,

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 .

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

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 )