Discussion :

[lezebulon]

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 :

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

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

[Aleph69]

Bonjour,

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

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

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

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

[Aleph69]

Bonjour,

LA solution : un shared_ptr.

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

Et un petit exemple d'utilisation dans la faq pour pouvoir démarrer.

[poukill]

C'est aussi dans le nouveau standard : std::tr1::shared_ptr

[Aleph69]

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

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

[Goten]

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 .

[Aleph69]

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

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.

[Goten]

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

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

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.

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.

NaN n'existe pas en C++

[Aleph69]

Au niveau du respect : un peu plus oui.

Tu as des exemples en tête.

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.

[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

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

[Aleph69]

Bonsoir,

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.

[Aleph69]

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 :

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.

[gl]

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 !

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

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 :

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

[Chessmaster1966]

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

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

[Aleph69]

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