Discussion :

[koala01]

Si on utilise des vector<>, n'est il pas difficile d'éviter leur imbrication dès qu'on représente une structure un tant soit peu hiérarchique? Je veux dire quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
class UnType {
  int Index;
  vector<UnAutreType> Enfants
};
 
vector<UnType> MaHierarchie;

Sinon, cela reviendrait à dire qu'il faut éviter de mettre dans un vecteur tout objet contenant un autre vector, et alors ca limite quand même passablement l'intérêt du truc, non?

Francois

Là aussi, tu aborde finalement deux problèmes particuliers...

Celui de l'imbrication "brute" des vecteurs, et celui de la délégation des tâches.

Je ne suis absolument pas partisan de trouver un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
typedef std::vector<std::vector<UnType> > Matrix;
/*...*/

mais, la délégation des tâche aidant, je ne suis pas forcément opposé au fait de retrouver un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Line
{
    private:
        std::vector<UnType> l;
};
class Matrix
{
    private:
        std::vector<Line> m;
};

ou la version utilisant boost::array si les dimensions sont clairements définies à la base.

Et je n'aurais même aucune objection, si seuls le type réellement manipulé et la matrice étaient intéressant à avoir des classes imbriquées, sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class Matrix
{
    class Line
    {
        private:
            std::vector<UnType> l;
    };
    public:
    /* interface */
    private:
        std::vector<Line> m;
};

Parce que cela implique que j'aie au minimum réfléchi correctement à la sémantique à apporter aux différentes dimensions.

Et cette réflexion m'inciterait peut-être à choisir justement un conteneur différents, selon le type le plus courent d'accès envisagé

Ceci dit, si cette approche souffre effectivement des problèmes liés au redimensionnement et à la copie des tableaux dynamiques, qui sont, finalement, les mêmes que ceux rencontrés pour les tableaux C style, elle permet de travailler de manière beaucoup plus "exception safe" du fait du RAII.

Au passage, la nouvelle norme en préparation (connue sous le vocable C++0x et prévue normalement pour la fin de l'année) prévoit d'introduire la notion de "sémantique de mouvement" (move semantic) qui permettra justement d'éviter au maximum les copies inutiles d'objets.

[Invité]

Je suis d'accord avec tout ca. Je citais cet exemple comme un cas dans lequel initialisation et copie automatique de vector<> posait problème... Et oui, l'idée n'est pas de représenter des tableaux rectangulaires, mais des structures hierarchiques.

Dans ce cas, l'imbrication de vecteurs devient une alternative pratique (faire un tableau unique signifierait un chargement en plusieurs passes, une gestion assez complexe des paramètres de structure, et l'impossibilité de modifier le hierarchie à l'exécution), mais c'est aussi là qu'on va voir arriver les problèmes de rapidité (trop de vecteurs, trop d'initialisations, trop d'indirections, trop de copies...)

Francois

[koala01]

Je suis d'accord avec tout ca. Je citais cet exemple comme un cas dans lequel initialisation et copie automatique de vector<> posait problème... Et oui, l'idée n'est pas de représenter des tableaux rectangulaires, mais des structures hierarchiques.

Le fait est que tu risque de toutes manières de te heurter à "des problèmes" à représenter des structures hiérarchiques, y compris si tu décide de travailler avec les pointeurs bruts...

D'un côté, tu subira les problèmes de performances brutes dérivant directement d'un "mauvais choix" de la structure dynamique permettant la gestion des éléments contenus.

D'un autre coté, il sera aussi très simple de se retrouver avec tous les problèmes potentiels dus au simple fait de vouloir gérer soi même la mémoire.

La solution sur ce point tient en deux axes (qui ne sont absolument pas antinomiques, bien au contraire) qui consisteront peut être:

• à résoudre le problème de la hiérarchisation des objets avec le design pattern composite
• à résoudre les problèmes liés à la gestion dynamique de la mémoire avec boost::pointer_container (du moins en attendant la nouvelle norme)

Nous sortons là du cadre de la seule utilisation de la STL, mais il faut se rendre compte que boost (de manière générale) inspire grandement la norme et permet réellement de se simplifier la vie sur des points que la norme a laissé de coté...

Et pour ce qui est du problème propre aux pertes de performances dues à la copie, nous pourrions dire que nous attendons tous la nouvelle norme qui permettra la sémantique de mouvement