créer un vector<struct>

**pfeuh** · 09/08/2011, 16h47

Salut,

Débutant total en C++, j'aimerais savoir si cette façon de faire un tableau de strucures est correcte. Si oui, j'aurais cru que la méthode at() retournerait une copie de la structure, or elle semble travailler par pointeurs puisque si l'on modifie "le truc" retourné par la méthode at(), on modifie bien l'instance. C'est correct ou pas?

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
#include <iostream>
#include <vector>
 
typedef struct
{
    size_t id;
    char* label;
}DUMMY;
 
int main()
{
    std::vector<DUMMY> items;
    items.push_back((DUMMY){7, "item1"});
    items.push_back((DUMMY){5, "item2"});
    items.push_back((DUMMY){12345, "item3"});
    items.at(2).id = 54321; // modif de l'instance ou de la copie
    for(size_t index = 0; index < items.size(); index++)
    {
        std::cout << "id:" << items.at(index).id << " label:\"" << items.at(index).label << "\"\n";
    }
    return 0;
}

Encore une question, y a t-il moyen de supprimer le cast (DUMMY) des 3 lignes similaires?

Code :

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

items.push_back((DUMMY){7, "item1"});

A+

Pfeuh

**pyros** · 09/08/2011, 17h52

Salut,

Alors tout d’abord, les struct ne sont pas très "C++". Surtout si tu es débutant, utilise plutôt des class

Selon si tu es très grand débutant ou un peu débutant, tu peux aller voir sur la page sur les tuto C++, ou alors dans la faq c++ pour en apprendre un peu plus sur les classes.

Revenons à ton problème. Je ne détaillerai pas car il y aurait de quoi faire un cour de C++. Je te donne une liste de mot clef, d'idée.
Lorsque tu crée une classe, tu doit définir un constructeur (faq c++ class, contructeur, etc...). Ce qui remplacera ton cast DUMMY avec la list d'initialisation, très "C like"

Le at() ne renvois pas une copie, ni un pointeur, mais une référence (faq c++ pour en savoir plus sur les références). En fait, c'est un genre de pointeur en moins "olé olé". C'est à dire que tu ne vas pas jardiner à la main dans la mémoire. Mais oui, tu modifie bien "le truc qu'il y a dans le vecteur".

Tu peux aussi utiliser l'operator[] à la place du at() (faq c++ operator):

Code :

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

items[i].id

Voilà. Je sais que c'est assez rapide comme réponse, mais ta question qui peut paraitre anodine fait en fait appel à plein de notion de C++ que je ne peux pas détailler ici.

**pfeuh** · 10/08/2011, 08h05

Envoyé par pyros

ta question qui peut paraitre anodine fait en fait appel à plein de notion de C++ que je ne peux pas détailler ici.

Non, ce n'était pas anodin, ça me permet de mesurer le monde qu'il y a entre le C (d'où je viens) et le C++. Merci pour ta réponse et les pistes qu'elle m'a ouvertes.

A+

Pfeuh

**koala01** · 10/08/2011, 09h26

Salut,

D'abord, il faut comprendre le principe de fonctionnement des collections de la STL... :

L'ajout d'éléments se fait par copie. C'est à dire que, si tu as un code proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
int main()
{
    std::vector<Dummy> tab;
    Dummy dum;
    dum.id = 15;
    tab.push_back(dum);
    dum.id= 20;
    std::cout << "size for dum : " << dum.id << std::endl
             << "size for tab[0] : " << tab[0].id << std::endl;
    return 0;
}

tu n'obtiendra pas le résultat 20 pour dum et 20 pour tab[0] mais... 20 pour dum et 15 pour tab[0];

Autrement, une fois que l'élément a été ajouté à ta collection, tu récupérera soit une référence (un alias, ou, comme l'a dit pyros, une "sorte de pointeur" qui garde la syntaxe classique, même si ce n'est pas tout à fait vrai) soit un itérateur, c'est à dire un objet qui te permet de parcourrir la collection (entre autres avec l'operateur d'incrémentation "++" ) et qui utilise la syntaxe des pointeurs.

Ceci dit, en ce qui concerne le code même de ta structure :

Tout comme en C, les identifiants entièrement écrits en majuscules sont "classiquement" réservés par convention pour le préprocesseur. Il vaudrait donc mieux utiliser Dummy que ... DUMMY.

De plus, la définition d'un type utilisateur (qu'il s'agisse d'une énumération, d'une structure ou d'une classe ) provoque la déclaration du type en question.

Il n'est donc plus nécessaire de passer par le typedef struct, mais on peut se contenter d'un

Code :

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

1
2
3
4
5
struct Dummy
{
    size_t id;
    char *label;
};

En outre, il faut savoir que C++ fournit, en standard, une classe qui a pour objectif de gérer (de manière totalement transparente pour l'utilisateur) les chaines de caractères.

Comme je présumes que label est destiné à représenter une telle chaine de caractères, tu aurais largement intérêt à préférer cette classe...

Ne serait-ce que parce que la gestion des chaines de caractères est très loin d'être simple en C

(or, char *, c'est... une chaine "C style"...)

Enfin, on peut considérer que, si l'on vient à modifier l'id ou le label, on obtient un élément totalement différent.

Il serait donc "utile" (et des plus intéressants) de rendre ces données privées (de manières à ce que seules l'objet puisse y accéder), et de ne fournir vers "l'extérieur" que... des fonctions permettant d'y accéder en lecture.

Il faudra alors cependant également prévoir de fournir un constructeur (cf la FAQ

)qui aura pour objectif de s'assurer que ton objet est correctement initialisé au moment où tu le crées.

Au final, Dummy pourrait ressembler à

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
/* la seule différence entre une struct et une class en C++ est 
 * l'accessibilité qui y est appliquée :publique pour les struct et privée
 * pour les class
 */
class Dummy
{
    public:
        /* le constructeur */
        Dummy(size_t i, std::string const & l):id_(i),label_(l){}
        /* les "accesseurs" qui nous intéressent */
        size_t id() const{return id_;}
        std::string const & label() const{return label_;}
    private:
        /* les données réellement utilisées */
        size_t id_;
        std::string label_;
 
};
int main()
{
    std::vector<Dummy> tab;
    tab.push_back(Dummy(1,"le premier"));
    tab.push_back(Dummy(2,"le deuxieme"));
    tab.push_back(Dummy(3,"le troisieme"));
    tab.push_back(Dummy(4,"le dernier"));
 
}

**3DArchi** · 10/08/2011, 10h45

Bonjour,

Envoyé par pyros

Alors tout d’abord, les struct ne sont pas très "C++". Surtout si tu es débutant, utilise plutôt des class

Juste une remarque : les struct sont tout autant "C++" que les class. Les deux mots clés sont équivalents pour définir un type à la nuance près d'une visibilité et un héritage par défaut public avec struct et privé avec class. Cf F.A.Q. Quelle est la différence entre class et struct ?

On utilise même très souvent struct en C++ objet sans états, foncteurs, traits&policies, prog générique...

Comment choisir l'un plutôt que l'autre. On recommande parfois d'utiliser struct pour les types sans invariants et plutôt class pour les types avec des invariants. Ou une autre façon, les types POD (donc sans invariants) en struct, les autres en class

**pfeuh** · 10/08/2011, 11h32

Envoyé par koala01

Tout comme en C, les identifiants entièrement écrits en majuscules sont "classiquement" réservés par convention pour le préprocesseur. Il vaudrait donc mieux utiliser Dummy que ... DUMMY.

C'est noté. Je me suis basé sur la structure FILE qui est en majuscules et qui est la première qui m'est venue à l'esprit.. Merci pour l'exemple de code C++ qui est très parlant et très pédagogique..

A+

Pfeuh

**koala01** · 10/08/2011, 12h04

Envoyé par pfeuh

C'est noté. Je me suis basé sur la structure FILE qui est en majuscules et qui est la première qui m'est venue à l'esprit.. Merci pour l'exemple de code C++ qui est très parlant et très pédagogique..

A+

Pfeuh

Si ce n'est que FILE en C est... une définition préprocesseur, permettant de cacher l'intégralité d'une structure sous-jascente... CQFD

Tu n'as, en effet, aucun moyen de travailler avec FILE autrement que... en passant par les fonctions qui prennent un FILE en paramètre (ou renvoyant un pointeur dessus)

**pfeuh** · 10/08/2011, 14h12

Envoyé par koala01

Si ce n'est que FILE en C est... une définition préprocesseur

Ben comme ça, je m'endormirai moins bête.

J'ai repris je crois toutes les remarques pour aboutir à ça:

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
#include <iostream>
#include <string>
#include <vector>
 
class Dummy
{
    public:
        Dummy::Dummy(size_t i, std::string lab);
        size_t Dummy::getId(void);
        void Dummy::setId(size_t i);
        std::string Dummy::getLabel(void);
        void Dummy::setLabel(std::string lab);
    private:
        size_t id;
        std::string label;
};
 
Dummy::Dummy(size_t i, std::string lab)
{
    id = i;
    label = lab;
}
 
size_t Dummy::getId(void)
{
    return id;
}
 
void Dummy::setId(size_t i)
{
    id = i;
}
 
std::string Dummy::getLabel(void)
{
    return label;
}
 
void Dummy::setLabel(std::string lab)
{
    label = lab;
}
 
void showTab(std::vector<Dummy> tab)
{
    for(size_t index = 0; index < tab.size(); index++)
    {
        std::cout << "index:" << index << " id:" << tab[index].getId()
        << " label:\"" << tab[index].getLabel() << "\"\n";
    }
}
 
int main()
{
    std::vector<Dummy> tab;
    tab.push_back(Dummy(1,"le premier"));
    tab.push_back(Dummy(2,"le deuxieme"));
    tab.push_back(Dummy(3,"le troisieme"));
    tab.push_back(Dummy(4,"le dernier"));
    showTab(tab);
    tab[2].setLabel("le cinquieme");
    tab[1].setId(12345);
    showTab(tab);
    return 0;
}

Est-ce conforme à la philosophie C++? Et toujours la même question que je me pose: Ce qui est passé en paramètre à la fonction showTab, est-ce un pointeur (euh... Une référence, si j'ai bien compris) ou une copie de l'instance?

Une dernière remarque: On me conseille souvent la faq pour un mot clef ou autre (constructeur , référence, etc...). Je lis les faq et je comprends les infos qui y sont données. Le problème, c'est que je n'ai pas les réflexes C++, puisque j'ai ceux du C.

**koala01** · 10/08/2011, 15h20

Ca s'améliore, mais il reste deux / trois remarques à répéter:

De prime abord, les accesseurs (tes fonctions getXXX) devraient être constants et, si le type renvoyé n'est pas un type primitif (tel que int ou double), une référence constante sur la donée originelle :

La référence permettra d'éviter la copie -- qui peut prendre du temps ou même parfois être interdite -- de la donnée d'origine, et le fait de rendre cette référence constante évitera que l'utilisateur ne tente de la modifier induement (le fait de rendre la fonction elle-même constante te fera insulter par le compilateur si, d'aventure, tu te trouves dans une situation dans laquelle tu finirais par modifier l'objet

)

Les muttateurs (tes fonctions setXXX) ne doivent pas forcément être présents: ainsi que je te l'ai expliqué plus haut, si tu modifie l'id d'un objet existant, tu obtiens... un tout nouvel objet. Il n'y a donc strictement aucune raison de permettre ce genre de modification !!!

Lorsque tu définis le constructeur d'une classe, préfères utiliser la liste d'initialisation à l'affectation des membres : même les types primitifs disposent de "pseudo constructeurs", et, encore une fois, cela permettra peut être d'éviter des copies couteuses

Lorsque tu transmet un argument plus gros qu'un type primitif à une fonction, il est de bon ton, toujours pour éviter les copies inutiles, de le passer sous la forme d'une référence, qui sera, encore et toujours, constante si la fonction qui reçoit l'argument n'a pas vocation à le modifier.

Te sentirais le courage de modifier encore une fois ton code, uniquement sur base de ces remarques

**pfeuh** · 11/08/2011, 09h55

Envoyé par koala01

De prime abord, les accesseurs (tes fonctions getXXX) devraient être constants

pour être constant, c'est ce que tu as déclaré comme ça, avec le const et le '&'?
std::string const & label();

Envoyé par koala01

La référence permettra d'éviter la copie

J'ai déclaré ma fonction showTab ainsi:
void showTab(std::vector<Dummy> tab);
Je n'ai toujours pas le déclic, que dois-je faire pour que le paramètre tab soit considéré comme une référence au lieu d'une copie?

Envoyé par koala01

Les muttateurs (tes fonctions setXXX) ne doivent pas forcément être présents: ainsi que je te l'ai expliqué plus haut, si tu modifie l'id d'un objet existant, tu obtiens... un tout nouvel objet. Il n'y a donc strictement aucune raison de permettre ce genre de modification !!!

Je suis tout à fait d'accord, mon code initial est à seule fin de compréhension, le type d'objet qui m'intéresse étant plus complexe, avec un id, un label, un type, des flags (read, write, visible etc...), un pointeur sur la donnée réelle, des méthodes de sérialisation/desérialisation etc...

Envoyé par koala01

Te sentirais le courage de modifier encore une fois ton code, uniquement sur base de ces remarques

Bien sûr... Dès que j'aurai compris ce qui me manque!

A savoir comment passer tab à la fonction showTab par définition plutôt que par copie.

**3DArchi** · 11/08/2011, 10h07

Envoyé par pfeuh

pour être constant, c'est ce que tu as déclaré comme ça, avec le const et le '&'?
std::string const & label();

std::string const & label()const;.
Non seulement la valeur retournée est constante mais tu indiques aussi que la fonction est constante.

Envoyé par pfeuh

J'ai déclaré ma fonction showTab ainsi:
void showTab(std::vector<Dummy> tab);
Je n'ai toujours pas le déclic, que dois-je faire pour que le paramètre tab soit considéré comme une référence au lieu d'une copie?

void showTab(std::vector<Dummy> const &tab);

**oodini** · 18/08/2011, 18h19

Envoyé par koala01

Enfin, on peut considérer que, si l'on vient à modifier l'id ou le label, on obtient un élément totalement différent.

Supposition audacieuse.
Quand ma femme a changé de nom en m'épousant, elle est restée la même personne.

Envoyé par koala01

Il serait donc "utile" (et des plus intéressants) de rendre ces données privées (de manières à ce que seules l'objet puisse y accéder), et de ne fournir vers "l'extérieur" que... des fonctions permettant d'y accéder en lecture.

Non, l'encapsulation n'est pas toujours utile. Et cela rajoute un niveau d'indirection supplémentaire. À faire si nécessaire, sans zèle.

**3DArchi** · 18/08/2011, 18h43

Salut,

Envoyé par oodini

Supposition audacieuse.
Quand ma femme a changé de nom en m'épousant, elle est restée la même personne.

Je ne mettrai pas ma tête sur le billot. Ce n'est pas aussi anodin que l'on a tendance à le penser que de changer de nom. Un nom joue dans la représentation de soi mais aussi dans ses rapports aux autres.

Envoyé par oodini

Non, l'encapsulation n'est pas toujours utile. Et cela rajoute un niveau d'indirection supplémentaire. À faire si nécessaire, sans zèle.

C'est pas pour contredire, mais c'est à peu près le contraire que j'aurais tendance à préconiser : à ne pas faire si vraiment justifié et sans zèle. Par défaut, capturer le bon concept avec son bon niveau sémantique et mettre en place l'encapsulation me semblent être la démarche première à préconiser. Et ne pas faire d'encapsulation a probablement à voir avec la sémantique faible de l'amalgame des composants (en général, cela traduit l'absence d'invariant à garantir) et est probablement l'exception.

**koala01** · 18/08/2011, 22h00

Envoyé par oodini

Supposition audacieuse.
Quand ma femme a changé de nom en m'épousant, elle est restée la même personne.

Attention, elle prend ton nom comme deuxième nom, même si son premier passe du coté de "née" ou du "mauvais coté" du trait d'union...

Ton nom à toi est "temporaire" pour ta femme et ne durera que le temps du mariage

(je ne te souhaites évidemment pas de divorcer, on est bien d'accord

) alors que son nom "de jeune fille" lui restera quoi qu'il puisse arriver

Non, l'encapsulation n'est pas toujours utile. Et cela rajoute un niveau d'indirection supplémentaire. À faire si nécessaire, sans zèle.

A l'instar de 3D, je trouve que tu pars dans le mauvais sens ici...

L'encapsulation doit, par défaut, être appliquée, les cas où elle ne devrait pas l'être n'étant sommes toutes que l'exception

Je ne parle pas des fonctions setXXX dont je ne suis absolument pas partisan, mais d'une encapsulation correcte grace à laquelle les modifications éventuellement apportées aux données se font au travers de comportements réputés comme ayant de grandes chances de rester valides sans le temps: elle permet réellement d'augmenter le respect de l'OCP

**Emmanuel Deloget** · 19/08/2011, 16h25

Envoyé par oodini

Supposition audacieuse.
Quand ma femme a changé de nom en m'épousant, elle est restée la même personne.

Parce que le nom de ta femme ne fait pas partie de ses propriétés intrinsèque

Non, l'encapsulation n'est pas toujours utile. Et cela rajoute un niveau d'indirection supplémentaire. À faire si nécessaire, sans zèle.

Vade-retro !

1/ Une encapsulation bien faite ne rajoute rien.
2/ Elle est TOUJOURS utile
3/ ce n'est pas une question de zèle, c'est une question de vie ou de mort du projet

**oodini** · 19/08/2011, 16h33

Vade retro ?
Si je suis le diable, tu es quant à toi Renaud de Châtillon. :-)

Je suppose que tu n'utilises jamais les structures ?

**Emmanuel Deloget** · 19/08/2011, 16h44

Envoyé par oodini

Vade retro ?
Si je suis le diable, tu es quant à toi Renaud de Châtillon. :-)

Je suppose que tu n'utilises jamais les structures ?

Sauf en cas exceptionnel.

Le seul cas ou les structures sont autorisées(*), c'est lorsqu'elles compose un objet sans invariant fort (c'est à dire ou toutes les combinaisons de tous les membres sont possibles), et de tels objets sont rares lorsqu'on utilise les bonnes abstractions.

Dès lors qu'il y a deux propriétés dans une structure, il y a de très grandes chances que ses deux propriétés soient liées (et qu'on ne puisse pas les modifier indépendamment) ou ait un domaine d'existence bien spécifique (auquel cas il faut contrôler les valeurs). Rares sont les cas ou ces deux propriétés sont fausses, et plus tu augmentes le nombre de membres, plus les cas sont rares.

(*) dans lama vision de la POO, s'entends.

**oodini** · 19/08/2011, 17h25

Envoyé par Emmanuel Deloget

Sauf en cas exceptionnel.

Le seul cas ou les structures sont autorisées(*), c'est lorsqu'elles compose un objet sans invariant fort (c'est à dire ou toutes les combinaisons de tous les membres sont possibles), et de tels objets sont rares lorsqu'on utilise les bonnes abstractions.

Dans le programme présenté dans le post original, explique-moi quelle est la contre-indication.
La question ne porte même pas sur l'encapsulation, aucune donnée métier n'est donnée, et il n'y est pas fait question d'invariant.

**3DArchi** · 19/08/2011, 18h10

Envoyé par oodini

Dans le programme présenté dans le post original, explique-moi quelle est la contre-indication.
La question ne porte même pas sur l'encapsulation, aucune donnée métier n'est donnée, et il n'y est pas fait question d'invariant.

Envoyé par pfeuh

Je suis tout à fait d'accord, mon code initial est à seule fin de compréhension, le type d'objet qui m'intéresse étant plus complexe, avec un id, un label, un type, des flags (read, write, visible etc...), un pointeur sur la donnée réelle, des méthodes de sérialisation/desérialisation etc...

(c'est moi qui souligne)

Si Emmanuel, Koala et moi avons réagi c'est que ton propos initial :

Envoyé par oodini

Non, l'encapsulation n'est pas toujours utile. Et cela rajoute un niveau d'indirection supplémentaire. À faire si nécessaire, sans zèle.

nous a semblé pouvant être mal interprétée. J'ai souligné la dernière phrase car la démarche OO est exactement le contraire. On cherche à travailler avec le bon niveau d'abstraction, l'encapsulation étant un moyen vital pour garantir la cohérence des services proposés vs la façon dont ils sont réalisés.
L'absence d'invariant d'un type, le cas où l'encapsulation semble effectivement moins forte, est très rare. Et qui plus est, ces types 'triviaux' ont rapidement vocation à être encapsulés dans des types plus riches.

**3DArchi** · 19/08/2011, 18h13

Envoyé par 3DArchi

Et ne pas faire d'encapsulation a probablement à voir avec la sémantique faible de l'amalgame des composants (en général, cela traduit l'absence d'invariant à garantir) et est probablement l'exception.

Envoyé par Emmanuel Deloget

(*) dans lama vision de la POO, s'entends.

la ma notre
On est au - 2 sur ce fil mais je suis persuadé qu'en fouillant dans ce site ou dans d'autre, la cohorte serait vite dépassée.