Discussion :

[Nob_.]

Bien le bonjour à tous!

Je recherche un conseil pour organiser des données dans le genre de ce qui suit:

[nom_a] [date_a1][qté_a1][date_a2][qté_a2]
[nom_b] [date_b1][qté_b1]
[nom_c] [date_c1][qté_c1][date_c2][qté_c2][date_c3][qté_c3]...

où "nom" est de type chaine, qté de type int et date d'un autre type encore.
Pour chaque "nom", il y a une quantité variable et non définie au départ de "date" et "qté", qui va grossir avec le temps. De plus, je souhaite pouvoir obtenir une liste ordonnée de "nom".

J'envisage d'utiliser un ou plusieurs conteneur de type List ou Map; quelle serait la meilleure imbrication au niveau de classe ou inversement?

Merci d'avance pour vos recommandations et du temps consacré à me répondre.

[Sunsawe]

Salut,

Vu que tu veux associer des valeurs de types differents entre elles, je pense qu'une map de map ferait l'affaire.

Code :

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

map< string, map< date, int > >

Du moins si j'ai eu raison de considérer ta représentation comme étant plutot:

Code :

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

1
2
3
4
5
6
7
8
9
 
[nom_a] [date_a1][qté_a1]
        [date_a2][qté_a2]
 
[nom_b] [date_b1][qté_b1]
 
[nom_c] [date_c1][qté_c1]
        [date_c2][qté_c2]
        [date_c3][qté_c3]

et qu'il n'y a qu'une quantité par date. S'il y en avait plusieurs, une map de map de list serait à envisager.

[Nob_.]

Salut à toi Sunsawe,

oui il s'agit bien de ce genre de représentation. Je te remercie pour le conseil et ta promptitude .

Je vais donc appliquer ce cas de figure. De plus tu as éveillé ma curiosité avec le map de map de list, je vais creuser autour de ça c'est intéressant.

(P.S: Sinon je suis nouveau sur un forum, je dois marquer -résolu- c'est ça ?)

[Sunsawe]

En fait regarde bien sur ta page, tu devrais voir un bouton marqué "résolu". Normalement tu n'as qu'à cliquer dessus.

Au passage, jette un oeil à la FAQ C++, tu y trouveras de bonnes indications quant au choix d'un conteneur.

Choix de conteneur

[koala01]

Salut,

Personnellement, je n'utiliserais pas une map de map, mais plutot deux structures, dont une contenant une simple liste et une map pour gérer le tout:

Code :

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

1
2
3
4
5
struct QtyByDate
{
    Date date; /* (1) */
    int quantity; /* (2) */
};

Nota:

• (1) peut, selon le cas, être une structure de type date choisie parmi l'existant ou une simple chaine de caractères
• (2) rien n'empêche, si tu as des quantités avec des décimales, de choisir float ou double selon tes besoins

Code :

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

1
2
3
4
5
struct Product
{
    std::string name;
    std::list<QtyByDate> history;
};

Nota: je pars du principe que les quantités et les dates seront, par défaut, classées par date, vu qu'il y aura ajout à chaque fois

Par la suite, tu insère tous les produits dans une std::map, dont la clé est une chaine de caractères représentant le nom du produit:

Code :

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

std::map<std::string, Product> allProduct;

Le tout serait lu sous une forme proche de

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
void readFile(std::map<std::string, Product>& prod, std::string filename)
{
    std::ifstream ifs(filename.c_str();
    std::string prodname;
    while(ifs>>prodname)
    {
        Product p;
        p.name=prodname;
        std::string temp;
        std::getline(ifs, tempdates)
        std::stringstream ss;
        ss<<temp;
        Date date;
        int qty;
        while(ss>>date>>qty)
        {
            QtyByDate qbt;
            qbt.date=date;
            qbt.quantity=qty;
            p.history.push_back(qbt);
        }
        prod.insert(std::make_pair(p.name,p));
    }
}
/* fonction utilisée dans main sous la forme de
 */
int main()
{
    std::map<std::string, Product> allProducts;
    readFile(allProducts, "monfinchier.txt");
    /*...*/
    return 0;
}

Et, comme il est vraisemblable que tu veuille aussi enregistrer les données, cela se ferait sous une forme proche de

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
void saveToFile(std::map<std::string, Product> const & prods, std::string
                const & filename)
{
    std::ofstream ofs(filename.c_str());
    for(std::map<std::string, Product>::const_iterator itprod=prods.begin();
        itprod!=prods.end();++it)
    {
        ofs<< (*it).first;
        for(std::list<QtyByDate>::const_iterator itdate=(*it).history.begin();
            itdate!=(*it).history.end();++it)
        {
            ofs<<" "<<(*itdate).date<<" "<<(*itdate).quantity;
        }
        ofs<<std::endl;
    }
}

PS: je n'ai absolument pas travaillé dans une optique orientée objet ici, ne sachant pas exactement ce que tu veux faire de tes données, mais il serait finalement simple d'améliorer ces exemples pour qu'ils respectent les principes de l'OO

[Pragmateek]

Au lieu d'une solution technico-technique peu maintenable et évolutive, ne pourrais tu pas utiliser des entités ayant un sens métier ?

Par exemple si les données représentent les commandes des clients :
alors créer une entité "Client" contenant une collection d'entités "Commande".
Puis récupérer les "Client" à partir du modèle soit via des Getter soit via un des accesseurs :

Code :

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

1
2
3
4
5
6
Client client1 = modele.GetClient(10);
Client client2 = modele.GetClient("client2");
Client client3 = modele["client3"];
...
Commande commande = client1.Commands["2009-01-01"];
...

Ca a beaucoup d'avantages dont :
- la sémantisation du code,
- le découplage entre la logique métier et l'implémentation technique,
- l'encapsulation
...
et plus généralement tous les avantages de la POO.

[koala01]

Au lieu d'une solution technico-technique peu maintenable et évolutive, ne pourrais tu pas utiliser des entités ayant un sens métier ?

Par exemple si les données représentent les commandes des clients :
alors créer une entité "Client" contenant une collection d'entités "Commande".
Puis récupérer les "Client" à partir du modèle soit via des Getter soit via un des accesseurs :

Code :

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

1
2
3
4
5
6
Client client1 = modele.GetClient(10);
Client client2 = modele.GetClient("client2");
Client client3 = modele["client3"];
...
Commande commande = client1.Commands["2009-01-01"];
...

Ca a beaucoup d'avantages dont :
- la sémantisation du code,
- le découplage entre la logique métier et l'implémentation technique,
- l'encapsulation
...
et plus généralement tous les avantages de la POO.

Je ne sais pas si c'est à moi que tu t'adresse, mais, si tel est le cas, j'ai bien précisé que je n'avais pas travaillé dans une optique OO en précisant la raison

Il va de soi (même si je ne l'ai pas exprimé clairement) que je préférerais grandement une conception objet plus conventionnelle

Au moins, je donnais les bases "minimales" pour arriver à partir sur une conception cohérente

[Pragmateek]

Je ne sais pas si c'est à moi que tu t'adresse, mais, si tel est le cas, j'ai bien précisé que je n'avais pas travaillé dans une optique OO en précisant la raison

Ce n'était pas du tout à toi que je m'adressais, nos messages se sont croisés.

Ma proposition rejoint complètement la tienne.

[Nob_.]

Merci pour ces précisions je vois dans quelle direction travailler.
Sinon je trouve le site et le forums franchement