Initialisation d'une map

**Pierre de Siorac** · 25/08/2011, 00h04

Bonsoir,

Je galère un peu sur mon erreur de compil' (qui ne doit pas être grand chose m'enfin...

)

J'ai une classe qui contient un attribut map<int, int> qui est nommé du genre avec un typedef:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include <map>
 
typedef std::map<unsigned int, unsigned int> Equinoxe;
 
 
class Calendar {
	protected:
		static Equinoxe m_automne;
		static void initAutomne(Equinoxe&);
........
 
Calendar.h

Vous l'avez peut être compris avec la méthode initAutomne(Equinoxe&), je souhaite initialiser ma map m_automne quand un Objet Calendar est construit en la passant par référence pour limiter l'allocation en mémoire, d'autant plus que le tableau est grand.

Mais je butte sur cette erreur ou le compilo me dit:

Code :

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

1
2
3
 error: no matching function for call to ‘Calendar::initAutomne(Equinoxe*)’
note: candidate is: static void Calendar::initAutomne(Equinoxe&)

Et je butte la dessus....

Voila la déclaration dans mon fichier cc:

Calendar.cc

Code :

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

void Calendar::initAutomne(Equinoxe& m) { .... }

qui est appelé dans mon constructeur par:

Code :

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

initAutomne(&m_automne);

Si vous avez des bonnes idées voire la solution (sans nul doute), je suis preneur !

Merci

**gbdivers** · 25/08/2011, 00h12

Bonjour Pierre et bienvenu sur le forum (et bon choix de lecture

)

Code :

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

initAutomne(&m_automne);

Si tu utilises & ( = address_of), tu envoies un pointeur vers ta variable. Avec une référence, il suffit de passer directement la variable :

Code :

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

initAutomne(m_automne);

Une raison particulière que ce soit un static ? Et pourquoi le passer en paramètre de ta fonction si c'est un static ?

**semaphore1984** · 25/08/2011, 00h13

Bonjour,

ça peut paraître étonnant, mais ton compilateur a raison ;

initAutomne(&m_automne);

ne fait pas un appel de initautomne avec un argment "référence sur Equinoxe", mais avec un argument "pointeur sur Equinoxe"

Appelle dans ton constructeur comme ci-dessous, et ça devrait aller mieux :

Code :

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

initAutomne(m_automne);

Cordialement

**Pierre de Siorac** · 25/08/2011, 01h12

Merci pour vos remarques pertinentes

Hélas on s'approche mais je tombe sur cette erreur:

Code :

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

undefined reference to `Calendar::m_automne'

Bonne question gbdivers: Si ma manière de faire est bonne: je n'ai besoin que d'une instance de cette map et son remplissage demande près de 3000 lignes... ce qui ferait un peut désordre dans mon constructeur... Voilà pourquoi je préfère passer par une méthode à part. (la map est statique mais pas constante).

**koala01** · 25/08/2011, 01h38

Envoyé par Pierre de Siorac

Merci pour vos remarques pertinentes

Hélas on s'approche mais je tombe sur cette erreur:

Code :

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

undefined reference to `Calendar::m_automne'

Bonne question gbdivers: Si ma manière de faire est bonne: je n'ai besoin que d'une instance de cette map et son remplissage demande près de 3000 lignes... ce qui ferait un peut désordre dans mon constructeur... Voilà pourquoi je préfère passer par une méthode à part. (la map est statique mais pas constante).

C'est normal: il faut que les variables statiques soit définies quelque part, hors de toutes fonction. Voir la FAQ sur le sujet

Ceci dit, si tu as effectivement un membre statique de type équinoxe, il est:
inutile de le passer à une fonction membre parce que les fonctions membres peuvent (c'est encore heureux

) accéder aux membre de la classes, même si les fonctions "de classe" (c'est le terme officiel pour les fonctions statiques

) ne peuvent accéder qu'aux membres "de classe" (ici aussi, c'est le terme officiel pour les membres statique).

Il faut, peut etre, aussi comprendre l'intérêt des fonctions / membres statiques : ce sont des fonctions / membres auxquel(le)s on peut accéder sans être obligé de disposer d'une instance de la classe, et qui sont en outre partagé(e)s par toutes les instances...

Est-il, dans le cas présent, bien utile de les utiliser, sachant qu'il y a, a priori, deux équinoxes par année, et que bien qu'elles tombent à date fixe, il sera difficile de faire tenir les deux dans un seul membre

Si tu reste sur l'idée d'avoir les équinoxes comme membre statique, il faudrait, à pour le moins, disposer de deux membres statiques : un pour l'équinoxe d'été, l'autre pour l'équinoxe d'hiver.

Enfin, Equinoxe et Solstice sont, AMHA des dates tout ce qu'il y a de plus normale, bien que nous puissions remarquer une particularité quant la quotité jour / nuit qu'elles représente...

Je ne suis vraiment pas persuadé qu'il soit opportun de créer des classes particulières (sans doute dérivées d'une classe Date) pour représenter ces dates particulières, car il n'y a strictement rien dans leur comportement qui les distingue des autres (tout au plus distingue-t-on leur particularité, mais cela reste malgré tout... des dates tout à fait comme les autres

)

Et comme, en outre, Date est typiquement une classe qui a sémantique de valeur, elle n'a, a priori, pas vocation à être dérivée

**Pierre de Siorac** · 25/08/2011, 02h04

Bon sang mais c'est bien sûr ! J'avais oublié que les variables statiques doivent être definies en dehors

J'essaierai ça demain. Merci de m'avoir rafraichi la mémoire avec les bonnes remarques !

Ceci dit, pour faire simple à propos des équinoxes, je ne me sers que des équinoxes d'automnes (eh oui je fais dans l'originalité

)qui ont lieu en général le 22 Septembre de chaque année mais peuvent aussi avoir lieu le 23 et même le 24 ! Et pour les connaître, je ne peux me baser que sur des données fournies par un observatoire puisque la variation est due aux contraintes physiques de la terre (et blabla j'en dis pas plus, ça sort de mon domaine. Faudrait faire une Faq astronomie

. )

Tout ça pour dire que ces valeurs ne peuvent pas être calculées et que je dois les insérer manuellement. Et cette classe calendar est la classe mère qui permet de fabriquer des calendriers...autres que grégorien, qui ont entre autres besoin de l'equinoxe d'automne pour fonctionner

A Demain pour la suite

**koala01** · 25/08/2011, 06h17

Envoyé par Pierre de Siorac

Bon sang mais c'est bien sûr ! J'avais oublié que les variables statiques doivent être definies en dehors

J'essaierai ça demain. Merci de m'avoir rafraichi la mémoire avec les bonnes remarques !

Ceci dit, pour faire simple à propos des équinoxes, je ne me sers que des équinoxes d'automnes (eh oui je fais dans l'originalité

)qui ont lieu en général le 22 Septembre de chaque année mais peuvent aussi avoir lieu le 23 et même le 24 ! Et pour les connaître, je ne peux me baser que sur des données fournies par un observatoire puisque la variation est due aux contraintes physiques de la terre (et blabla j'en dis pas plus, ça sort de mon domaine. Faudrait faire une Faq astronomie

. )

Tout ça pour dire que ces valeurs ne peuvent pas être calculées et que je dois les insérer manuellement. Et cette classe calendar est la classe mère qui permet de fabriquer des calendriers...autres que grégorien, qui ont entre autres besoin de l'equinoxe d'automne pour fonctionner

A Demain pour la suite

Cela va exactement dans le sens de tout ce que j'ai dit...

Que tu maintienne, dans ton calendrier, une équinoxe, ou deux, ou n'importe quelle date plus ou moins variable est une chose, mais:

Ce n'est jamais qu'une date, même si tu la "met en évidence" créant un membre qui la contienne : il n'est nul besoin de prévoir une classe particulière par rapport à une date "normale"
Le simple fait que la date soit susceptible, tu l'as dit toi même, de varier d'une année à l'autre la disqualifie pour être une variable statique, car chaque calendrier doit avoir sa propre date.

Pour expliquer plus précisément le (2), il faut te dire que toutes les instances d'une classe donnée vont partager les variables statiques.

Si tu utilises, et c'est sans doute ce qu'il va se passer, dix calendriers différents (un pour chaque année comprise entre 2012 et 2022), en même temps, il y en aura sans doute quatre pour lesquels l'équinoxe tombera le 22, trois pour lesquels elle tombera le 23 et trois pour lesquels elle tombera le 24 (même si la distribution est un peu différente).

Tu ne pourrais pas obtenir cette configuration avec une variable statique, vu que, une fois ta valeur définie, les dix calendriers utiliseraient la même date.

Si tu venais à changer la date pour la faire correspondre à une année précise, elle serait fausse pour... toutes les années qui ne correspond pas.

Ceci dit, je relis le code que tu donne, et je constate que, ce qui se passe surtout, c'est que tes termes sont très mal choisi...

Ta classe Equinoxe qui est une map (année / date

) devrait, au minimum, être nommée de telle sorte à ce que l'on sache qu'il s'agit... d'une collection permettant de récupérer la date de l'équinoxe en fonction de l'année :EquinoxeMap semblerait bien meilleure

De même, calendar pour moi représente une année, fusse-t-elle de la planète mars et puisse-t-elle durer 952 jours...

A priori, pour une année donnée, il ne devrait donc y avoir qu'une date correspondant à l'équinoxe, et il n'est donc pas du ressort de Calendar de maintenir la liste de l'ensemble des dates d'équinoxe

Si "quelque chose" doit garder cette liste à jour et doit permettre d'accéder à une date pour une année donnée, c'est tout, sauf le calendrier lui-même:

La responsabilité de maintenir cette liste de dates (et de permettre de les retrouver) suffit amplement pour que tu en fasse une classe particulière, et l'on peut parfaitement imaginer que tu auras sans doute besoin de cette classe à certains endroit où... il n'y a pas lieu d'avoir de calendrier...

Malgré tout le mal que l'on peut penser des variables globales (une variable statique n'est qu'une variable globale déguisée

) on peut sans doute se dire que l'idée d'utiliser un monostate (une recherche sur le forum t'indiquera de quoi il s'agit

) pour créer cette classe a quelques attraits

**Pierre de Siorac** · 25/08/2011, 16h13

Merci beaucoup pour tes remarques constructives

Bon j'avance mais rencontre d'autres problèmes...
J'ai donc d'après tes lumières, créé une nouvelle classe Equinoxe comme ceci: (J'ai pas mis toutes les méthodes, constructeurs et destructeurs)

Code :

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

1
2
3
4
5
6
7
8
9
class Equinoxe {
	private:
		unsigned int m_annee;
	public:
		......
		static std::map<unsigned int, unsigned int> m_automne;
		unsigned int getAnnee();
		unsigned int getEquinoxeAutomne();
};

Mais je butte pour initialiser ma map statique. Ma logique candide voudrait que ce soit de la sorte dans le .cc:

Code :

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

1
2
 
Equinoxe::m_automne.insert(pair<unsigned int, unsigned int>(1900, 22));

Tous les exemples que je trouve sur le net utilisent une fonction pour l'initialisation.

Merci à nouveau

**Spout** · 25/08/2011, 17h38

Bonjour,

Tu peux utiliser dans ton constructeur un test sur un booleen statique global que tu passes à true/false à la première instanciation de ta classe
Ta map ne sera alors pas recrée aux instanciations suivantes.

Bon courage

**koala01** · 25/08/2011, 20h06

Visiblement, tu n'as rien compris de ce que j'essaye d'expliquer :

l'équinox, ce n'est qu'une date, cela ne doit être rien d'autre (n'est ce pas la définition même de équinoxe

jour (date) où la nuit et la journée ont une durée identique )

Tu représente la date comme tu veux : un entier pour le jour (dans la limite de [1,31] et un pour le mois (dans la limite de [1,12], ou par un seul entier qui représente le nombre de jours écoulés depuis un point à définir par toi, ou, comme cela se fait parfois (pour les heures) en nombre de secondes qui se sont écoulées depuis le 1/1/1970 à minuit...cela n'a finalement que peu d'importance

La seule chose qui importe, c'est que tu utilises la même convention pour toutes les dates

Sur base de ces dates, tu peux envisager plein de choses : le style agenda qui ressemblerait à quelque chose comme

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
class AgendaDay // cette classe permet de mettre une date
                // particulière en relation avec les actions qui doivent
                // être prises ce jour là
{
    public:
    // hors contexte, je passe ici :-D
    private:
        Date date_; // pour savoir la date du jour
        std::list<Action> actions_; // pour savoir ce qui doit etre fait
};
class Agenda //un agenda est un ensemble de jours d'agenda, dont une
                  // bonne partie est vide à la base
{
    public:
 
    private:
        int year_;
        std::list<AgendaDay> days_; 
};

Si je fais la différence entre la date et le jour, c'est que le jour sera en définitive la durée séparant le début du jour (minuit) de sa fin (minuit) alors que la date n'est, finalement qu'une information de "position" du jour dans l'année

Ton calendar serait sensiblement identique: il regroupe l'ensemble des jours qui compose une année depuis son début (1er janvier) jusqu'à sa fin (31 décembre), avec, en plus, une information concernant la date de l'équinoxe, et donc, 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
class Day
{
    // je ne sais pas ce que tu veux faire de tes jours ;-)
    private:
        Date date_; // pour connaitre la date du jour
        /* ...*/
};
class Calendar
{
    // ni de Calendar, d'ailleurs :-P
    private:
        Date equinox; // la date de l'équinox pour l'année en cours
        std::list<Day> days_; // les jours du 1/1 au 31/12
};

Comme tu veux définir par avance les dates des équinoxes pour les N années à venir, il y aurait une troisième classe qui, par facilité ici pourrait etre implémenté sous la forme d'un pattern "monostate" 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
34
class EquinoxList
{
    public:
        void registerDay(Date const & d, int year)
        {
            days_.insert(std::make_pair(year, d));
        }
        Date const & findByYear(int year) const
        {
            std::map<int, Date>::const_iterator it=days_.find(year);
            if(it == days_.end())
                return Date(0); // une date réputée invalide :-D
            return it.second;
        }
        bool exists(int year) const
        { 
            return days_.find(year)!= days_.end();
        }
        // exemple très mal fait d'une fonction qui pourrait 
        // te permettre de récupérer la liste des équinoxes
        // dans un fichier :D
        static void readList(std::string const & filename)
        {
            days_.clear(); // pour le cas où on aurait déjà lu un fichier 
                             // et que les dates ne correspondraient pas:D
            std::ifsream ifs(filename.c_str());
            Date date;
            int year;
            while(ifs>>date>>year)
                registerDay(date, year);
        }
    private:
        static std::map<int, Date > days_;
};

Et comme tu voudrais surement gérer plusieurs Calendar en même temps, il y aurait sans doute une quatrième classe qui s'occuperait de le faire

Si je te proposer cette configuration, c'est pour plusieurs raisons:

il faut vraiment veiller à ce que les termes utilisés représentent effectivement le but de tes objets... Tu verras, cela te facilitera énormément la vie par la suite :d
Il faut également veiller à garder tes classes les plus simples possibles, et le meilleur moyen est de respecter le principe de la responsabilité unique : calendar fait une chose, EquinoxList en fait une autre, Day en fait une troisième, etc... : tu pourrais parfaitement utiliser Day sans savoir que calendar ou que EquinoxList existe: c'est indépendant
il y a d'autres (excellentes ) raisons , mais j'ai déjà écrit un roman, et je vais m'arrêter là, les deux premières suffisant normalement à te convaincre

**Pierre de Siorac** · 26/08/2011, 00h36

Bonsoir,

D'accord je comprends maintenant ton approche.
Par contre peux-tu m'expliquer pourquoi ta classe Equinoxlist qui compile telle que tu l'écris ne compile pas lorsque je souhaite decouper la classe dans un .h et .cc ? J'obtiens un "undefined reference to _days"

le fichier d'entête est pourtant bien inclus dans le .cc....

Merci encore pour ton aide précieuse...et ta patience

**Emmanuel Deloget** · 26/08/2011, 01h24

Envoyé par Pierre de Siorac

Bonsoir,

D'accord je comprends maintenant ton approche.
Par contre peux-tu m'expliquer pourquoi ta classe Equinoxlist qui compile telle que tu l'écris ne compile pas lorsque je souhaite decouper la classe dans un .h et .cc ? J'obtiens un "undefined reference to _days"

le fichier d'entête est pourtant bien inclus dans le .cc....

Merci encore pour ton aide précieuse...et ta patience

Manque la définition dans le .cc (seule la déclaration est présente, dans le .h). Il s'agit d'un static, donc cf. ton post datant de 02h04

Et l'insiste :

Envoyé par koala01

il faut vraiment veiller à ce que les termes utilisés représentent effectivement le but de tes objets... Tu verras, cela te facilitera énormément la vie par la suite :d

Ca, c'est vraiment important. Plus je travaille sur le sujet, plus je vois que la sémantique des noms de classe/variables/méthodes a un impact très fort sur la qualité finale du code. Pour être bonne, une abstraction doit être bien nommée. Mal nommé, une classe finira par faire des choses pour laquelle elle n'a pas été prévue à la base. Nommer une classe devrait te prendre au minimum 3 minutes de réflexion (pour ma part, il me faut des fois plusieurs jours pour trouver le nom qui va bien ; c'est ainsi qu'est née la classe desk de mon projet perso courant (une semaine pour trouver le nom, qui me donne alors l'abstraction à mettre en oeuvre)).

**JolyLoic** · 26/08/2011, 02h35

Envoyé par Emmanuel Deloget

Plus je travaille sur le sujet, plus je vois que la sémantique des noms de classe/variables/méthodes a un impact très fort sur la qualité finale du code. Pour être bonne, une abstraction doit être bien nommée. Mal nommé, une classe finira par faire des choses pour laquelle elle n'a pas été prévue à la base.

Il y a un argument que j'ai bien aimé à ce sujet : Certaines cultures croyaient que quand on connaissait le vrai nom d'un homme ou d'un esprit, on obtenait un pouvoir sur lui, un moyen de le soumettre à sa volonté. Et bien, en informatique, ces légendes ont pris corps, et c'est pour ça qu'il est très important de connaître le vrai nom d'une classe, d'une variable...

Initialisation d'une map

Langage C++

Discussions similaires

Partager

Partager