Avis sur la conception d'un projet c++

Version imprimable

30/12/2006, 09h36
b Oo

Avis sur la conception d'un projet c++
Bonjour à tous,
je voudrais avoir votre avis sur la conception d'un projet :
Les fichiers :
Pour l'histoire, il s'agit d'un petit projet donné en L3 Info. Les auteurs du sujet sont donnés sur le pdf.

Pour ce à qui n'ont pas voulu lire le pdf
"Le but du projet est de modéliser un mode animal, c’est à dire voir les intéractions entre les trois
éléments du monde : les carnivores mangent les herbivores et les herbivores mangent l’herbe. Pour
construire un monde animal, il est nécessaire de savoir sur quel continent on se trouve. En Amérique,
les carnivores sont les loups et les herbivores les bisons, tandis qu’en Afrique ce sont les lions et les
girafes."

La classe MondeAnimal

La classe MondeAnimal est la classe principale de notre simulation. Nous déclarons une instance de cette classe en lui passant le continent sur lequel nous voulons réaliser la simulation, et nous appelons ensuite la méthode run.
La classe MondeAnimal contient une grille de pointeurs sur des FauneFlore. (FauneFlore est une interface pour les classes Animal et Vegetal, nous la décrivons en détail dans le paragraphe suivant).

Creator et Runner :

Nous avons également défini deux autres classes dans le même fichier, car celles-ci sont des outils nécessaires au fonctionnement de MondeAnimal.
La première est la classe Runner. Il s’agit d’un foncteur qui est utilisé dans la méthode run de MondeAnimal. Nous avons créé cette classe pour pouvoir utiliser l’algorithme for_each de la STL dans la méthode run.
Il permet d’appeler pour chaque case la grille la méthode run. Le constructeur prend en paramètre un MondeAnimal par référence car la méthode run d’un FauneFlore modifie le MondeAnimal.

Le deuxième foncteur, Creator, permet de créer des FauneFlore en appelant les méthodes de fabrication du Continent passé en paramètre dans le constructeur de Creator.
Creator contient donc des pointeurs de méthodes sur la classe Continent. Cela nous permet de remplir la grille aléatoirement. Creator est donc lui aussi un foncteur qui renvoie un pointeur sur un FauneFlore.
La grille est alors simplement remplie avec l’algorithme generate de la STL, et le Creator passé en paramètre.
A noter la syntaxe de la déclaration d’un pointeur sur une méthode :
typedef FauneFlore*(Continent::* FauneFloreCreator)()const;
et l’appel de la méthode :
(continent_.*creator_[random_])();
Avec creator_ qui contient l’adresse des méthodes de fabrication.
Les méthodes de la classe MondeAnimal sont les suivantes :
- void affiche() const; permet d’afficher la grille, le nom des espèces est centré
- void run(const size_t nbIter = 1); permet de lancer la simulation nbIter fois
- void supprime(const size_t cle); supprime l’élément à l’indice clé, un Animal appelle cette méthode lorsqu’il mange quelque chose
- inline void setEspace(const size_t espace); défini le nombre de caractères sur lequel nous affichons l’espèce d’un animal, il faut que ce nombre soit supérieur à la longueur maximale des espèces
- inline size_t getTaille() const; renvoie la taille d’un côté de la grille
- inline FauneFlore * operator[](const size_t cle); renvoie le FauneFlore d’indice cle
- inline const FauneFlore * operator[](const size_t cle) const; renvoie le FauneFlore d’indice cle
- inline void echange(const size_t pos1, const size_t pos2); échange le contenu des cases en appelant swap de la STL, nécessaire pour le déplacement des animaux
La classe FauneFlore

FauneFlore est la classe mère de tous les animaux et végétaux. Elle nous permet d’avoir un conteneur de pointeurs sur la classe mère, et donc d’appeler les méthodes des « vraies classes » par le polymorphisme.

getArticle, getType, getName sont des méthodes qui permettent respectivement de retourner l’article (ie : le, la, une), le type (ie : herbivore, carnivore, vegetal), et le nom de l’espèce (ie : lion, loup, …).
findCaseVide permet de trouver s’il existe une case vide autour de l’animal, et find permet de trouver de la nourriture se trouve dans une case voisine. Pour find, nous passons le type (ie : vegetal, carnivore, herbivore) en paramètre.
Nous avons bien sûr la méthode run qui ne fait rien pour le Vegetal. Pour Carnivore et Herbivore, elle teste si l’animal peut manger, si oui, l’animal mange, sinon il se déplace (s’il peut).

Il n'y a pas les classes Continent, Amerique, Afrique car elles ne sont pas très compliquées. TLogfile permet juste de sauvegarder dans un fichier les différents évènements.

Les problèmes de notre conception sont :
1. la duplication de la méthode run, en effet juste une chose varie entre les 2
2. la méthode type() et getType() qui sont vraiment pas top
1. La duplication de la méthode run a été obligée car nous pour un herbivore nous cherchons de l'herbe autour, alors que pour un carnivore nous cherchons un herbivore. A part ceci c'est le même code.

2. Nous avons utiliser la méthode getType pour forcer les classes filles a implémenter cette méthode et pour faire des "méthodes virtuelles statiques".
Nous utilisons type pour trouver un animal avec la méthode find.

J'aimerais donc savoir si nous aurions pu éviter les deux points précédents. Le premier peut être résolu de la maniére suivante :
j'implémente la méthode run dans Animal, et je crée un méthode regime virtuelle pure qui dit ce qu'un Animal mange et find appelle cette méthode.
Il y a peut-être mieux, non ?

Je voudrais également savoir, imaginons que j'ai 5 000 animaux. Est-ce qu'il pourrait-être intéressant de faire un pattern stratégie pour la méthode run (ie le comportement d'un animal) ?

N'hesiter pas a faire des remarques sur la conception même si elle a été beaucoup guidée.

Merci d'avance.
30/12/2006, 13h05
loufoque

Citation:

La classe MondeAnimal contient une grille de pointeurs sur des FauneFlore. (FauneFlore est une interface pour les classes Animal et Vegetal, nous la décrivons en détail dans le paragraphe suivant).

Pourquoi des pointeurs ? T'alloues dynamiquement des types dérivés pour pouvoir stocker ça de manière uniforme ? (ce qui d'ailleurs n'est pas nécessaire)
Dans ce cas, tu n'as pas des problèmes d'exception safety ?
Tu n'as d'ailleurs pas vraiment précisé qui avait la charge de gérer les différentes ressources.

Citation:

La première est la classe Runner. Il s’agit d’un foncteur qui est utilisé dans la méthode run de MondeAnimal. Nous avons créé cette classe pour pouvoir utiliser l’algorithme for_each de la STL dans la méthode run.

Un simple bind aurait suffit.

Citation:

Il permet d’appeler pour chaque case la grille la méthode run. Le constructeur prend en paramètre un MondeAnimal par référence car la méthode run d’un FauneFlore modifie le MondeAnimal.

Le monde ne devrait-il pas être disponible sous forme de singleton ou autre truc du genre plutôt ?

Citation:

Le deuxième foncteur, Creator, permet de créer des FauneFlore en appelant les méthodes de fabrication du Continent passé en paramètre dans le constructeur de Creator.
Creator contient donc des pointeurs de méthodes sur la classe Continent. Cela nous permet de remplir la grille aléatoirement. Creator est donc lui aussi un foncteur qui renvoie un pointeur sur un FauneFlore.
La grille est alors simplement remplie avec l’algorithme generate de la STL, et le Creator passé en paramètre.
A noter la syntaxe de la déclaration d’un pointeur sur une méthode :
typedef FauneFlore*(Continent::* FauneFloreCreator)()const;
et l’appel de la méthode :
(continent_.*creator_[random_])();
Avec creator_ qui contient l’adresse des méthodes de fabrication.

Mouais, ça me parait pas top.

Citation:

void affiche() const = 0; permet d’afficher la grille, le nom des espèces est centré

Pourquoi la fonction est pure ?
Il y a une histoire d'héritage de monde ?

Citation:

inline void setEspace(const size_t espace); défini le nombre de caractères sur lequel nous affichons l’espèce d’un animal, il faut que ce nombre soit supérieur à la longueur maximale des espèces

Quel intérêt de limiter ça ? Utilise std::string.

Citation:

inline FauneFlore * operator[](const size_t cle); renvoie le FauneFlore d’indice cle
inline const FauneFlore * operator[](const size_t cle) const; renvoie le FauneFlore d’indice cle

Ne serait-il pas mieux de retourner des références ?

Citation:

Elle nous permet d’avoir un conteneur de pointeurs sur la classe mère, et donc d’appeler les méthodes des « vraies classes » par le polymorphisme.

Pourquoi la classe contient des pointeurs ?

Citation:

getArticle, getType, getName sont des méthodes qui permettent respectivement de retourner l’article (ie : le, la, une), le type (ie : herbivore, carnivore, vegetal), et le nom de l’espèce (ie : lion, loup, …).

getType est déjà fourni par le RTTI.

Je croyais aussi qu'une FauneFlore avait une fonction membre run ?
30/12/2006, 15h14
b Oo
Merci loufoque de t'être penché sur le problème.

Citation:

Pourquoi des pointeurs ? T'alloues dynamiquement des types dérivés pour pouvoir stocker ça de manière uniforme ? (ce qui d'ailleurs n'est pas nécessaire)
Dans ce cas, tu n'as pas des problèmes d'exception safety ?
Tu n'as d'ailleurs pas vraiment précisé qui avait la charge de gérer les différentes ressources.

MondeAnimal crée les objets et les detruits. Donc, les ressources sont seulement gérées par MondeAnimal. Pourquoi des pointeurs et non des objets ?
Lorsqu'un Carnivore mange un Herbivore je le détruis.

Citation:

Un simple bind aurait suffit.

Non car :
Code:

1 2 3 4 5 6 7 8 void Runner::operator()(FauneFlore * fauneFlore) { if (fauneFlore != 0) fauneFlore->run(monde_, indice_); ++indice_; indice_ %= taille_; }
monde_ est la référence sur le MondeAnimal et indice, c'est l'indice sur la case de la grille.

Citation:

Le monde ne devrait-il pas être disponible sous forme de singleton ou autre truc du genre plutôt ?

Non je ne pense pas, nous pouvons lancer des simulations sur différents mondes. Sinon je pourrais limiter à 5 le nombre d'instances pour les 5 continents et là ça rejoint ce que tu as dis.

Citation:

Quel intérêt de limiter ça ? Utilise std::string.

Tu as pensé que je limitais le nombre de caractères de la chaine ?
Non, en fait c'est pour le setw. Cela me permet d'avoir un affichage centré et pour cela je dois avoir une valeur plus grande dans le setw que la longueur max d'une chaine.

Citation:

Pourquoi la classe contient des pointeurs ?

Non pas la classe FauneFlore mais MondeAnimal oui.
C'est juste pour dire pourquoi j'ai rajouter une classe FauneFlore.

Citation:

getType est déjà fourni par le RTTI.
Je croyais aussi qu'une FauneFlore avait une fonction membre run ?

Oui, on est d'accord, je ne teste pas avec le type pour savoir quel méthode j'appelle.
Mais si j'ai une grille 2x2 :
-------------
Lion | Girafe |
-------------
rien | Herbe |
-------------
Je voudrais que Girafe avec la méthode find cherche de l'herbe et si elle en trouve la mange.
De même le Lion avec la méthode find cherche une Girafe et s'il en trouve la mange.
Cela sans changer la méthode find définit dans la classe Animal.
Sinon je pourrais faire dynamic_cast à la place de mon getType pour savoir si c'est le bon truc que j'attends.
Car là je ne vois pas comment le RTTI peut m'aider.

Je mets le lien dans le 1er post vers le code source dans quelques minutes.
30/12/2006, 20h54
loufoque

dynamic_cast est implémenté grâce au RTTI.
31/12/2006, 10h56
b Oo

Autant pour moi.
Si je veux éviter un dynamic_cast il suffit que je définisse une méthode qui fait ce que j'attends ?
C'est plus "beau" de faire une nouvelle méthode qu'un dynamic_cast non ?

Sinon pour Creator tu n'aimais pas trop ça, tu vois quelque chose d'autre ?

Merci encore.
31/12/2006, 11h42
JolyLoic

Citation:

Envoyé par b Oo

Autant pour moi.
Si je veux éviter un dynamic_cast il suffit que je définisse une méthode qui fait ce que j'attends ?
C'est plus "beau" de faire une nouvelle méthode qu'un dynamic_cast non ?

Pourquoi serait-ce plus beau ?

Ce qui est "moche" dans le dynamic_cast, ce n'est pas le dynamic_cast, c'est de devoir faire un traitement spécifique à une classe dérivée particulière, sans pouvoir encapsuler ce traitement dans une fonction virtuelle de cette classe. A partir du moment où tu as décidé que c'est ce que tu voulais faire, autant utiliser un outil tout fait pour le faire.

D'autant plus que dynamic_cast a l'avantage de marcher avec des hiérarchies sur plus de deux niveaux, ce qui n'était pas le cas de la plupart des fonctions bricolées pour le remplacer que j'ai pu rencontrer. J'entends pas là, si C dérive de B qui dérive de A, tu as un A* qui pointe sur un objet de type C. Un dynamic_cast en B* de ce pointeur sera un succès, ce qui est une bonne chose. Un test de type monA->getType()==B::GetTypeName() échouera.

Un cas où je pourrait voir l'intérêt de faire ce genre de chose, c'est si le type n'est pas directement lié à la hiérarchie de classe. Par exemple, dans une hiérarchie mammifères/oiseaux/reptiles, tu pourrait être tenté d'utiliser le RTTI pour implémenter une fonction indiquant si un animal pond des oeufs. Jusqu'au jour où tu rencontres un ornithorynque.
31/12/2006, 13h25
b Oo

Salut,
non je ne veux pas "bricoler" une méthode, je pensais à une méthode virtuelle. Je n'ai pas été très clair, il faut croire.
Je ne vois pas d'ailleurs comment une méthode non virtuelle pourrait arranger mon problème ici.
Je demandais s'il vallait mieux que je crée une méthode virtuelle ou s'il était mieux de rester avec dynamic_cast.
Le choix de la méthode virtuelle est surement meilleur si la méthode s'applique à toute ma hiérarchie, non ?
01/01/2007, 04h32
JolyLoic

Le bricolage auquel je pense fait lui aussi appel à une fonction virtuelle... Mais montre moi ce que tu as en tête. En particulier, est-ce que ça passe le test des hiérarchies à plus de 2 étages ?

Salut,
je suis d'accord avec toi que getType n'est pas une solution très élégante.
getType() ne me permet pas de savoir quel est exactement le type de la classe, mais il permet de me dire si un FauneFlore est un herbivore ou un carnivore ou un végétal.
Pourquoi j'ai besoin de savoir cela, car un carnivore mange un herbivore et un herbivore mange un végétal. Et ca je ne sais pas comment le traduire sans un getType.
J'ai bien fait un code sans getType mais celui-ci n'est pas très bien non plus.

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
template <class Nourriture>
size_t Animal::find(const MondeAnimal & mondeAnimal, const size_t pos, const Nourriture * n) const
{
    delete n; // car on cree un objet juste pour le template
    size_t taille = mondeAnimal.getTaille();
 
    // on recherche l'element a gauche de pos
    size_t indiceElt = pos-1;
    // si on est pas sur un bord
    if (pos > 0 && (pos % taille) != 0)
        // renvoie si 0 si pas le bon type et si le pointeur est deja a 0
        if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
            return indiceElt;
 
    // on recherche l'element a droite de pos
    indiceElt = pos+1;
    // si on est pas sur un bord
    if (indiceElt < taille*taille && (indiceElt % taille) != 0)
        if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
            return  indiceElt;
 
 
    // on recherche l'element en bas de pos
    indiceElt = pos-taille;
    if (pos >= taille)
           if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
                return indiceElt;
 
 
    // on recherche l'element en haut de pos
    indiceElt = pos+taille;
    if (indiceElt < taille*taille)
        if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
            return indiceElt;
 
    return pos;
}
 
 
void Animal::run(MondeAnimal & mondeAnimal, const size_t pos) const
{
    size_t cle = find(mondeAnimal, pos, nourriture());
    if (cle != pos)
    {
        mange(mondeAnimal[cle]);
        mondeAnimal.supprime(cle);
    }
    else
    {
	cle = findCaseVide(mondeAnimal, pos);
	if (cle != pos)
	{
	    mondeAnimal.echange(pos, cle);
	    ostringstream entier1;
	    ostringstream entier2;
	    entier1 << pos+1;
	    string chaine = this->getName() + " se deplace de la case ";
	    chaine += entier1.str();
	    chaine += " a la case ";
	    entier2 << cle+1;
	    chaine +=  entier2.str();
	    TLogFile::getInstance().ecrire(chaine);
	}
	else
	{
	    string chaine = this->getName() + " ne peut pas bouger";
	    TLogFile::getInstance().ecrire(chaine);
	}
    }	    
}

nourriture() est une méthode qui crée un objet dynamique sur la nourriture d'un animal

Code:

1
2
3
4
Vegetal * Herbivore::nourriture() const
{
    return new Vegetal(); 
}

je me sert également du fait que l'on peut modifier le type de retour pour une hiérarchie :

Code:

1
2
3
4
5
6
7
8
virtual FauneFlore * FauneFlore::nourriture() const
{ 
   return 0;
}
Herbivore * Carnivore::nourriture() const
{
    return new Herbivore(); 
}

En fait l'objet ne me sert à rien ici, c'est juste pour pouvoir faire un dynamic_cast du type de mon objet et car je ne peux passer directement un objet dans le paramètre de mon template.

Le problème avec cette méthode est le delete dans ma méthode find et je dois aussi rendre instanciable mes classes Herbivore et Végétal.

05/01/2007, 11h05
loufoque

Déjà y'a un delete ailleurs que dans un destructeur.
C'est mal parti.
05/01/2007, 11h20
Patriarch24

Citation:

je suis d'accord avec toi que getType n'est pas une solution très élégante.
getType() ne me permet pas de savoir quel est exactement le type de la classe, mais il permet de me dire si un FauneFlore est un herbivore ou un carnivore ou un végétal.
Pourquoi j'ai besoin de savoir cela, car un carnivore mange un herbivore et un herbivore mange un végétal. Et ca je ne sais pas comment le traduire sans un getType.
J'ai bien fait un code sans getType mais celui-ci n'est pas très bien non plus.

Double aiguillage ? Pattern "visitor" !
05/01/2007, 11h22
bolhrak

Citation:

Envoyé par loufoque

Déjà y'a un delete ailleurs que dans un destructeur.
C'est mal parti.

Bon ma question va être un peu HS, désolé, mais comment peux tu garantir des delete uniquement dans des destructeurs ?

Par exemple si j'ai une classe DocumentManager, qui contient une liste de documents, il faut bien qu'il les détruise à chaque fois un document est fermé non ? Ou bien tu passes systématiquement par des handlers ?
05/01/2007, 11h34
Laurent Gomila

Citation:

Bon ma question va être un peu HS, désolé, mais comment peux tu garantir des delete uniquement dans des destructeurs ?

Là par exemple tu peux prendre un std::auto_ptr en paramètre, plutôt qu'un pointeur brut.
Tu pourrais aussi ne rien passer du tout et spécifier le paramètre template explicitement.

Voir la FAQ pour plus de détails concernant les pointeurs intelligents et le RAII.
05/01/2007, 13h44
loufoque

Citation:

Bon ma question va être un peu HS, désolé, mais comment peux tu garantir des delete uniquement dans des destructeurs ?

Tu peux toujours lire ça que j'ai écrit y'a pas longtemps sur usenet et qui apparemment n'a intéressé personne.
http://groups.google.com/group/comp....48fe777747e426
05/01/2007, 14h14
b Oo

Citation:

Le problème avec cette méthode est le delete dans ma méthode find et je dois aussi rendre instanciable mes classes Herbivore et Végétal.

Citation:

Déjà y'a un delete ailleurs que dans un destructeur.
C'est mal parti.

Pour eviter le delete je peux renvoyer un auto_ptr ou sinon il faut que j'encapsule mon objet dans une classe.
Si j'utilise un auto_ptr, il sera détruit à la fin de la fonction, c'est bien çà ?

Citation:

Double aiguillage ? Pattern "visitor" !

Il faudrait que je fasse un visiteurType qui me renvoie le type de l'objet ?

Merci encore.
05/01/2007, 15h04
Laurent Gomila

Citation:

Si j'utilise un auto_ptr, il sera détruit à la fin de la fonction, c'est bien çà ?

Oui.
05/01/2007, 15h09
bolhrak

@Laurent Gomilla : je connais déjà ces techniques, ma questino portait plus de manière générale, mais tu y réponds en grande partie ;) Disons que mon problème est que j'utilise quand même beaucoup les pointeurs, et que pas mal de commentaires sur ce forum me font me poser des questions.

@Loufoque : merci pour le lien :p Malheureusement je ne connais pas très bien C++/CLI, je vais donc me renseigner sur le sujet avant, mais j'ai quand même l'impression que cela va bien plus loin que la question que je me pose (en même temps c'est pas plus mal me permettra de découvrir de nouveaux trucs ;) )
05/01/2007, 15h25
Laurent Gomila

Citation:

Envoyé par bolhrak

@Laurent Gomila : je connais déjà ces techniques, ma questino portait plus de manière générale, mais tu y réponds en grande partie ;) Disons que mon problème est que j'utilise quand même beaucoup les pointeurs, et que pas mal de commentaires sur ce forum me font me poser des questions.

C'est pour ça que je t'ai orienté vers les pointeurs intelligents et le RAII. Normalement avec la FAQ tu devrais avoir un bon point de départ sur ces 2 concepts.
05/01/2007, 16h35
loufoque

Citation:

@Loufoque : merci pour le lien :p Malheureusement je ne connais pas très bien C++/CLI

Mon message ne parle pas de C++/CLI.
Mais bon apparemment le problème vient de mon lien, j'avais voulu pointer sur un message en particulier mais apparemment ça pointe que vers le début du fil.
Ce lien semble fonctionner.
05/01/2007, 21h10
JolyLoic

Personellement, j'ai du C++/CLI la plus mauvaise expérience qui me semble possible de l'introduction d'un Garbage Collector en C++. Lier l'utilisation ou pas du GC au système de type, bien qu'attrayant au premier abord, ne marche pas vraiment, puisque le choix d'avoir une donnée partagée n'est pas du ressort de la donnée elle même, mais de l'usage que l'on soihaite en faire.

Dans ce sens, je préfère largement la proposition de Boem, qui a l'avantage d'être globalement compatible avec les programmes actuels raisonnables. Elle peut rendre correct des programmes qui ne le sont pas, mais ne peux pas rendre incorrecte des programmes raisonnables qui le sont (avec la bonne définition du mot raisonnable ;)). Je manque d'expérience avec ce GC, mais j'ai bien envie d'essayr un de ces jours.

Donc quand tu (si j'ai bien suivi, c'est toi Mathias Gaunard, l'auteur de l'article en question) proposes que le GC soit une fonctionnalité séparée, comment proposes-tu que cette séparation ait lieu ?
05/01/2007, 22h11
Médinoc

Le C++/CLI n'est pas pour moi l'introduction d'un GC en C++ : Ce serait plutôt l'introduction du C++ dans un système à GC.
05/01/2007, 22h33
loufoque

Bon apparemment mon lien est toujours pas bon (désolé j'ai du mal avec ce service de google - peut-être que tout simplement le lien devient invalide quand le fil est modifié ?).
Je faisais référence à mon message sur le RAII tout ça.

Le ramasse-miettes, C++/CLI etc. c'est hors sujet ici.

Citation:

Lier l'utilisation ou pas du GC au système de type, bien qu'attrayant au premier abord, ne marche pas vraiment, puisque le choix d'avoir une donnée partagée n'est pas du ressort de la donnée elle même, mais de l'usage que l'on soihaite en faire.

On a juste un type de pointeur particulier, ainsi qu'un gcnew. (enfin en C++/CLI il faut quand même que la classe soit déclarée comme étant utilisable avec le ramasse-miettes qui indique si on doit autoriser son usage avec le GC ou pas)
Ce type de pointeur est similaire à un pointeur intelligent comme shared_ptr par exemple, mais en mettant ça dans le langage, on peut rendre ça plus performant.
06/01/2007, 01h51
Luc Hermitte

Citation:

Envoyé par loufoque

Bon apparemment mon lien est toujours pas bon (désolé j'ai du mal avec ce service de google - peut-être que tout simplement le lien devient invalide quand le fil est modifié ?).

Le M-Id. Il n'y a que ça de vrai.
L'absence de réponse, ce n'est pas parce que tu avais répondu à un trolleur non initié?

Autrement, il me semble que James cite régulièrement l'exemple des programmes multithreadés comme application pratique des GC en C++. Ceci dit, le framework que j'utilise au taf' (ACE) me pousse vers les queues de messages. Du coup, je suis, pour l'instant, passé à côté des GC appliqués au MT.
06/01/2007, 04h22
JolyLoic
Citation:

Envoyé par loufoque

Bon apparemment mon lien est toujours pas bon (désolé j'ai du mal avec ce service de google - peut-être que tout simplement le lien devient invalide quand le fil est modifié ?).
Je faisais référence à mon message sur le RAII tout ça.

Je pense avoir lu le bon message.

Citation:

Envoyé par loufoque

Le ramasse-miettes, C++/CLI etc. c'est hors sujet ici.

Ah bon ? Quand il s'agit du discussion sur les bonnes pratiques du C++ et de son évolution, il me semble légitime de citer les langages qui lui sont proches.

Citation:

Envoyé par loufoque

On a juste un type de pointeur particulier, ainsi qu'un gcnew. (enfin en C++/CLI il faut quand même que la classe soit déclarée comme étant utilisable avec le ramasse-miettes qui indique si on doit autoriser son usage avec le GC ou pas)

Plus que simplement utilisable par le GC, on la déclare comme utilisable uniquement par le GC. C'est ça que je trouve étrange.

Citation:

Envoyé par loufoque

Ce type de pointeur est similaire à un pointeur intelligent comme shared_ptr par exemple, mais en mettant ça dans le langage, on peut rendre ça plus performant.

Introduire un pointeur spécifique pose le problème de savoir ce que l'on fait en cas d'interaction avec d'autres pointeurs.

Supposons qu'on note # ce pointeur, et # l'opérateur de déréférencement. Que faire si l'on a :
Code:

1 2 int #i = gcnew int(42); int *j = & (#i);
Ou
Code:

1 2 3 int *i = new int(42); int #j = & (*i); delete i;
06/01/2007, 12h55
loufoque

C'est simple, il suffit de ne pas permettre d'assigner un T* à une variable de type T#.
Le premier exemple ne pose pas de problème particulier, si ce n'est que le GC ne prend pas en compte j, ce qui signifie accessoirement que i peut être libéré même si j pointe vers la valeur.

Citation:

Autrement, il me semble que James cite régulièrement l'exemple des programmes multithreadés comme application pratique des GC en C++. Ceci dit, le framework que j'utilise au taf' (ACE) me pousse vers les queues de messages.

A priori partager les données plutôt que de les transmettre est plus performant sur les systèmes SMP, qui sont tout de même plus populaires.
06/01/2007, 15h16
JolyLoic

Citation:

Envoyé par loufoque

C'est simple, il suffit de ne pas permettre d'assigner un T* à une variable de type T#.

J'ai bien respecté cette règle dans mon code. Je déréférence un pointeur d'un type, et je met l'adresse du résultat dans le pointeur du second type. Je ne fais pas d'affectation directe. A partir du moment où on peut déréférencer les pointeurs, et prendre l'adresse de l'objet pointé, j'ai du mal à voir comment empêcher qu'un pointeur géré par GC et un autre non pointent sur le même objet. Il y a d'ailleurs le même problème avec les smart_ptrs boost.
06/01/2007, 18h20
loufoque

Citation:

Je déréférence un pointeur d'un type, et je met l'adresse du résultat dans le pointeur du second type.

Si t est de type T, alors &t est de type T* const.
i étant de type int*, *i est de type int, et &(*i) est de type int* const.
07/01/2007, 02h38
JolyLoic
Dans ce genre de situation, je vois 3 alternatives pour lopérateur d'adressage :
- Il ne retourne qu'un pointeur non géré par le GC, et rien d'autre (j'ai un peu l'impression que c'est ce que tu proposes. Peut-être que ça a du sens, faut que je creuse),
- Il retourne soit un pointeur géré par GC, soit un pointeur non géré en fonction de son contexte d'utilisation,
- Il y a deux opérateurs d'adressages. L'un retournant un pointeur géré, lautre non.

J'avais écrit mon code dans l'hypothèse 2. Je me rend compte qu'il aurait été plus clair dans l'hypothèse 3, en notant par exemple % l'opérateur qui retourne une adresse gérée par le GC.
Code:

1 2 3 4 5 6 int *i = new int(42); int #j = %(*i); delete i; int #i = gcnew int(42); int *j = & (#i);
07/01/2007, 19h40
loufoque

Ton opérateur % n'a pas de raison d'être. Bien que demander l'adresse de n'importe quel objet ait du sens (puisque tout objet a une adresse d'après le modèle de C++, sauf optimisations avec les registres), demander à partir de n'importe quel objet à obtenir une référence intelligente vers un élément stocké dans un endroit spécial et qui peut être automatiquement libéré quand il n'est plus référencé est tout simplement impossible.
Ce serait comme demander à savoir dans quel fichier sur le disque dur est stockée une variable en mémoire vive.

Ton hypothèse 2 n'a pas de sens ; l'adresse d'une variable c'est l'adresse d'une variable, juste un genre d'entier qui donne un emplacement en mémoire. Ça n'a conceptuellement rien à voir avec une référence vers un objet géré par le ramasse-miettes, bien que le second contienne forcément le premier d'un point de vue implémentation.

J'utilise le terme de référence intelligente plutôt que de pointeur parce que cela est plus adapté dans le cadre de l'utilisation d'un GC.
Il ne s'agit plus vraiment d'une adresse qu'on peut éventuellement déréférencer mais d'une référence vers un objet forcément valide, ou d'une référence nulle.
Ce n'est néanmoins pas une référence au sens C++ du terme, puisqu'on peut changer l'objet référencé.

De toutes manière ajouter cela au langage n'est qu'une optimisation de ce qu'on pourrait faire avec une bibliothèque.
Cela aurait bien sûr une interface totalement différent de shared_ptr, qui ne fait que gérer des pointeurs alloués avec new qu'on lui fournit (et qu'on peut d'ailleurs lui reprendre).
Si j'en avais la compétence j'implémenterais bien ce genre de chose.
07/01/2007, 19h45
Médinoc

Surtout que c'est une erreur de se dire "tant que je garde une référence active vers un objet, tous les pointeurs vers celui-ci resteront valides : Le ramasse-miettes ppeut à tout moment déplacer une variable en mémoire afin de faire de la place...
Le seul antidote à cela sont par exemple les pin_ptr<> du C++/CLI...
07/01/2007, 21h10
loufoque

Citation:

Le ramasse-miettes ppeut à tout moment déplacer une variable en mémoire afin de faire de la place...

C'est pas vraiment possible avec la proposition de Boehm.
08/01/2007, 01h37
JolyLoic

Effectivement, le GC proposé par Boem ne permet pas de servir de défragmenteur de mémoire. Par contre, il évite d'avoir une double indirection pour accèder aux données pointées. Je ne sais pas ce qui est le plus efficace (sachant qu'on est dans un contexte où comme il y aura aussi des pointeurs non gérés pas GC, il y aura toujours des problèmes de fragmentation).
08/01/2007, 20h59
JolyLoic
Citation:

Envoyé par loufoque

Ton opérateur % n'a pas de raison d'être. Bien que demander l'adresse de n'importe quel objet ait du sens (puisque tout objet a une adresse d'après le modèle de C++, sauf optimisations avec les registres), demander à partir de n'importe quel objet à obtenir une référence intelligente vers un élément stocké dans un endroit spécial et qui peut être automatiquement libéré quand il n'est plus référencé est tout simplement impossible.

Il y a des moments où bien que tout ce qu'on ait à notre disposition, ce soit un objet, on sait par ailleurs que cet objet est géré par un GC, et on aimerait bien retourner une référence vers lui (d'ailleur, cet opérateur existe en C++/CLI, et s'écrit %). Le cas le plus classique auquel je pense, c'est depuis une fonction membre de l'objet (le shared_from_this() de boost, du moins dans les cas où il marche...).

Autrement ce que tu proposes a l'air assez proche de ce qu'il y a en C++/CLI, à l'exception près qu'un tel poiteur serait utilisable pour tous les types, et non uniquement les types spécifiquement faits pour. Intuitivement, j'aurais tendance à aller dans cette direction explicite, même si je pense que telle que décrite elle laisse des zones floues actuellement.

Un autre point d'intéraction entre les types de poniteurs auquel je pense (même notation):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 struct A { B* b; }; struct B { A #a; }; { A #a = gcnew A; a->b = new B; a->b->a = a; }
Dans ce cas, peut-on collecter ? Après tout, a est connu par un pointeur non managé, donc peut donc être considéré comme non collectable. Ou alors, on considère que l'on doit aussi remonter à travers les pointeurs non managés pour déterminer des objets non atteignables ?

L'approche proposée par Boem est différente, en celà qu'elle me semble plus facilement compatible avec du code existant.

Citation:

Envoyé par loufoque

De toutes manière ajouter cela au langage n'est qu'une optimisation de ce qu'on pourrait faire avec une bibliothèque.

Je suis loin d'en être certain. Après tout, Boem propose une solution bibliothèque depuis longtemps, s'il veut une solution langage, ce n'est probablement pas sans raison. Et le fait qu'il ait pas mal travaillé sur le modèle mémoire en multithread n'y est probablement pas étranger. Mais j'avoue ne pas avoir lu dans les détails ces documents.

Citation:

Envoyé par loufoque

Si j'en avais la compétence j'implémenterais bien ce genre de chose.

Sans même parler d'implémentation, je serais curieux de voir une spec détaillée de la chose, afin de mieux juger de comment elle peut tenir la route.
08/01/2007, 23h13
David Fleury

J'avais cru lire un jour qu'un GC correct ne pouvait pas être implémenté en C++ à l'aide d'une librairie mais qu'il devrait l'être au niveau du langage même.
(j'essayerai de voir si je retrouve ce truc qui doit dater sûrement, alors ça a peut être changer)
10/01/2007, 10h38
Jean-Marc.Bourguet

Citation:

Envoyé par Hylvenir

J'avais cru lire un jour qu'un GC correct ne pouvait pas être implémenté en C++ à l'aide d'une librairie mais qu'il devrait l'être au niveau du langage même.
(j'essayerai de voir si je retrouve ce truc qui doit dater sûrement, alors ça a peut être changer)

Il y a quelques effets qui font qu'un GC en C++ tel qu'il est actuellement est formellement impossible: on peut cacher des pointeurs (dans un fichier, par un algo d'encryptage ou de compression; ce n'est uniquement theorique: il y a un moyen d'implementer une forme restreinte de listes doublement chainee avec un seul pointeur et je l'ai vu utiliser en pratique) et donc un GC ne peut pas determiner formellement dans tous les cas si un pointeur est accessible ou non. Les optimisations peuvent aussi cacher parfois des pointeurs. En pratique rare sont les programmes qui utilisent la possibilit de cacher les pointeurs et les optimisations ne cachent pas les pointeurs mais si on veut une garantie (le probleme est que sans garantie, le GC peut liberer de la memoire qui ne le devrait pas) il faut traiter ces cas limites et ca ne peut se faire que dans la description du langage.