Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ map objet ou objet* ?

map objet ou objet* ?

13 réponses
Avatar
Delf
Bonjour.

Je pédale dans la semoule, j'y comprends plus rien.

J'ai une classe CAdvLogger qui contient entre autre le membre suivant:

std::map<int, CColorAssociation> m_ColorAssociationMap;

CColorAssociation est une classe banale.

Dans une des méthodes de CAdvLogger :

CColorAssociation association(level, backhexcolor, forehexcolor);
m_ColorAssociationMap[level] = association;

Et là, G++ gueule sur la 2° ligne (l. 45) :

g++ -c AdvLogger.cpp
/usr/include/c++/3.4/bits/stl_map.h: In member function `_Tp&
std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with
_Key = int, _Tp = LanCtl::Utils::Log::CColorAssociation, _Compare =
std::less<int>, _Alloc = std::allocator<std::pair<const int,
LanCtl::Utils::Log::CColorAssociation> >]':
AdvLogger.cpp:45: instantiated from here
/usr/include/c++/3.4/bits/stl_map.h:339: error: no matching function for
call to `LanCtl::Utils::Log::CColorAssociation::CColorAssociation()'
ColorAssociation.h:13: note: candidates are:
LanCtl::Utils::Log::CColorAssociation::CColorAssociation(const
LanCtl::Utils::Log::CColorAssociation&)
ColorAssociation.h:25: note:
LanCtl::Utils::Log::CColorAssociation::CColorAssociation(int, const
std::string&, const std::string&)
*** Error code 1

Si par contre j'utilise la ligne suivante et que je modifie mon code, ça
fonctionne :

std::map<int, CColorAssociation*> m_ColorAssociationMap;

...

CColorAssociation association(level, backhexcolor, forehexcolor);
m_ColorAssociationMap[level] = &association;

1° question : pourquoi ? je ne comprends pas...

Deuxième problème, en gardant le 'CColorAssociation*', je fais une
recherche sur la map :

std::map<int, CColorAssociation*>::const_iterator citer;
citer = m_ColorAssociationMap.find(level);

if (citer == m_ColorAssociationMap.end())
{
...
}
else
{
std::cout << citer->first << std::endl; // je récupère le 'int'

// Comment je récupère la valeur 'CColorAssociation*' ?

std::cout << citer->second)<< std::endl; // adresse
std::cout << (citer->second)->GetBackHexColor(); // rien...
}

Merci d'avance...

--
Delf
Do not use this email in Cc!
L'alcool tue lentement. On s'en fout. On n'est pas pressé.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Delf
Delf wrote:

std::cout << (citer->second)->GetBackHexColor(); // rien...


Marrant, le destructeur est appelé... juste après la création de mon
objet CColorAssociation...

--
Delf
Do not use this email in Cc!
L'homme n'est que poussière. La femme est aspirateur.

Avatar
Michel Decima
Bonjour.

Je pédale dans la semoule, j'y comprends plus rien.

J'ai une classe CAdvLogger qui contient entre autre le membre suivant:

std::map<int, CColorAssociation> m_ColorAssociationMap;

CColorAssociation est une classe banale.


Qu'entends tu exactement par 'classe banale' ?


Dans une des méthodes de CAdvLogger :

CColorAssociation association(level, backhexcolor, forehexcolor);
m_ColorAssociationMap[level] = association;

Et là, G++ gueule sur la 2° ligne (l. 45) :

g++ -c AdvLogger.cpp
/usr/include/c++/3.4/bits/stl_map.h: In member function `_Tp&
std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with
_Key = int, _Tp = LanCtl::Utils::Log::CColorAssociation, _Compare =
std::less<int>, _Alloc = std::allocator<std::pair<const int,
LanCtl::Utils::Log::CColorAssociation> >]':
AdvLogger.cpp:45: instantiated from here
/usr/include/c++/3.4/bits/stl_map.h:339: error: no matching function for
call to `LanCtl::Utils::Log::CColorAssociation::CColorAssociation()'


Le compilateur te dit qu'il ne trouve pas le constructeur par defaut
de la classe CColorAssociation.


ColorAssociation.h:13: note: candidates are:
LanCtl::Utils::Log::CColorAssociation::CColorAssociation(const
LanCtl::Utils::Log::CColorAssociation&)
ColorAssociation.h:25: note:
LanCtl::Utils::Log::CColorAssociation::CColorAssociation(int, const
std::string&, const std::string&)


La, le compilateur te dit qu'il a trouve un constructeur, mais qu'il ne
convient pas (des arguments sont necessaires).
Question: la classe CColorAssociation a t'elle un constructeur par defaut ?

Si par contre j'utilise la ligne suivante et que je modifie mon code, ça
fonctionne :

std::map<int, CColorAssociation*> m_ColorAssociationMap;

...

CColorAssociation association(level, backhexcolor, forehexcolor);
m_ColorAssociationMap[level] = &association;

1° question : pourquoi ? je ne comprends pas...



Parce que le type mappé est maintenant un pointeur, et que les pointeurs
possedent toutes les proprietes requises pour rentrer dans un container
standard.
Mais l'ecriture ci dessus est dangereuse, parce que le pointeur ne sera
valide que dans la portee de la variable association (et potentiellement
il restera dans la map apres, alors qu'il sera invalide).

Deuxième problème, en gardant le 'CColorAssociation*', je fais une
recherche sur la map :

std::map<int, CColorAssociation*>::const_iterator citer;
citer = m_ColorAssociationMap.find(level);
std::cout << citer->first << std::endl; // je récupère le 'int'

// Comment je récupère la valeur 'CColorAssociation*' ?



avec citer->second.

Avatar
Delf
Michel Decima wrote:

Qu'entends tu exactement par 'classe banale' ?


Une classe sans rien d'exceptionnel :)

g++ -c AdvLogger.cpp
/usr/include/c++/3.4/bits/stl_map.h: In member function `_Tp&
std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with
_Key = int, _Tp = LanCtl::Utils::Log::CColorAssociation, _Compare =
std::less<int>, _Alloc = std::allocator<std::pair<const int,
LanCtl::Utils::Log::CColorAssociation> >]':
AdvLogger.cpp:45: instantiated from here
/usr/include/c++/3.4/bits/stl_map.h:339: error: no matching function
for call to `LanCtl::Utils::Log::CColorAssociation::CColorAssociation()'


Le compilateur te dit qu'il ne trouve pas le constructeur par defaut
de la classe CColorAssociation.


Mais pourquoi un constructeur vide ? Je l'ai ajoué, ça compile mais j'ai
de drôle de comportements... je vais tracer... je comprends pas là :

La, le compilateur te dit qu'il a trouve un constructeur, mais qu'il ne
convient pas (des arguments sont necessaires).
Question: la classe CColorAssociation a t'elle un constructeur par defaut ?


Uniquement celui là à la base :
CColorAssociation(int, const std::string&, const std::string&);

Je vais investigué, merci.

--
Delf
Do not use this email in Cc!
A New York les taxis sont jaunes, à Londres ils sont noirs et à Paris
ils sont cons.


Avatar
Fabien LE LEZ
On Wed, 12 Apr 2006 22:43:01 +0200, Delf :

Le compilateur te dit qu'il ne trouve pas le constructeur par defaut
de la classe CColorAssociation.


Mais pourquoi un constructeur vide ?


Où as-tu vu "constructeur vide" ?
On te parle de constructeur par défaut, i.e. sans argument.
Il peut très bien contenir du code.


m_ColorAssociationMap[level] = association;

Décomposons un peu ce code.

"m_ColorAssociationMap[level]=" : tu demandes une référence non-const
sur un des éléments contenus dans la map<>.
Comme cet élément n'existait pas déjà, il doit être créé -- i.e.
construit, via le constructeur par défaut.

"... = association;"

Ici, tu assignes l'objet "association". Il y a donc copie (via
operator=) de l'objet à l'emplacement défini par
"m_ColorAssociationMap[level]".


Avatar
kanze
Delf wrote:

J'ai une classe CAdvLogger qui contient entre autre le membre suivant:

std::map<int, CColorAssociation> m_ColorAssociationMap;

CColorAssociation est une classe banale.


C-à-d ? Il n'y a pas de classes « banales ».

Dans une des méthodes de CAdvLogger :

CColorAssociation association(level, backhexcolor, forehexcolor);
m_ColorAssociationMap[level] = association;

Et là, G++ gueule sur la 2° ligne (l. 45) :

g++ -c AdvLogger.cpp
/usr/include/c++/3.4/bits/stl_map.h: In member function `_Tp&
std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with
_Key = int, _Tp = LanCtl::Utils::Log::CColorAssociation, _Compare =
std::less<int>, _Alloc = std::allocator<std::pair<const int,
LanCtl::Utils::Log::CColorAssociation> >]':
AdvLogger.cpp:45: instantiated from here
/usr/include/c++/3.4/bits/stl_map.h:339: error: no matching function for
call to `LanCtl::Utils::Log::CColorAssociation::CColorAssociation()'
ColorAssociation.h:13: note: candidates are:
LanCtl::Utils::Log::CColorAssociation::CColorAssociation(const
LanCtl::Utils::Log::CColorAssociation&)
ColorAssociation.h:25: note:
LanCtl::Utils::Log::CColorAssociation::CColorAssociation(int, const
std::string&, const std::string&)
*** Error code 1


Comme Michel et Fabien ont déjà dit : l'expression map[index]
créer un nouvel élément dans le map, si l'élément démandé
n'existe pas. Et quelle valeur est-ce qu'il donne à cet
élément ? Sa valeur par défaut, évidemment ; c-à-d que pour un
type classe, il invoque le constructeur par défaut.

Si tu ne veux pas que ta classe ait un constructeur par défaut,
tu ne peux pas te servir de [] sur le map. En revanche, insert
ou find doivent encore fonctionner comme il faut.

Si par contre j'utilise la ligne suivante et que je modifie
mon code, ça fonctionne :

std::map<int, CColorAssociation*> m_ColorAssociationMap;

...

CColorAssociation association(level, backhexcolor, forehexcolor);
m_ColorAssociationMap[level] = &association;

1° question : pourquoi ? je ne comprends pas...


Pourquoi pas. Un pointeur, lui, a une valeur par défaut (le
pointeur null). Mais attention aux collections de pointeurs --
la décision pointeur ou non doit se faire sur la base de la
conception, et non simplement pour « faire passer la compile ».

À ta place, je ferais un pas en arrière. Je commencerais par
décider (au niveau de la conception) la rôle exacte de
CColorAssociation, et surtout, le genre de classe qu'elle doit
être. Si c'est une valeur, j'implémenterais toute la sémantique
de valeur (copie, affectation, etc.), ET un constructeur par
défaut qui met l'objet dans un état défini (mais pas forcément
signifiant -- quelque chose du genre pointeur null pourrait
convenir dans certains cas). Si l'identité de l'objet est
importante, en revanche, je déclarerais (mais sans les
implémenter) un constructeur de copie et un opérateur
d'affectation privés, et je m'assurerais que toutes les
instances soient allouées dynamiquement. (Il y a des exceptions,
où l'allocation dynamique ne s'impose pas, mais c'est quand même
la règle générale pour les objets à identité.) Et alors,
évidemment, le map contiendrait des pointeurs. (Et aussi
évidemment, il faudrait gérer la durée de vie de ces objets.)

Deuxième problème, en gardant le 'CColorAssociation*', je fais
une recherche sur la map :

std::map<int, CColorAssociation*>::const_iterator citer;
citer = m_ColorAssociationMap.find(level);

if (citer == m_ColorAssociationMap.end())
{
...
}
else
{
std::cout << citer->first << std::endl; // je récupère le 'int'

// Comment je récupère la valeur 'CColorAssociation*' ?

std::cout << citer->second)<< std::endl; // adresse
std::cout << (citer->second)->GetBackHexColor(); // rien...
}


Je ne vois pas où est le problème. L'expression citer->second
donne bien la valeur qui est associée à l'indice. Si cette
valeur est un pointeur, il faut le traiter comme un pointeur, si
c'est une valeur, comme une valeur.

Mais je crois d'abord qu'il faut que tu définisses bien ce que
c'est que ce CColorAssociation. (Et en passant, c'est quoi, ce
CC au début. Color ne s'écrit qu'avec un seul C.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Avatar
Fabien LE LEZ
On 13 Apr 2006 01:32:31 -0700, "kanze" :

CColorAssociation est une classe banale.


C-à-d ? Il n'y a pas de classes « banales ».


En voyant le mot "banal", j'ai cru qu'il parlait d'une classe
"gentille" (i.e. aussi facile à utiliser que int : copiable, etc.),
mais manifestement ce n'est pas le cas de CColorAssociation...


Avatar
kanze
Fabien LE LEZ wrote:
On 13 Apr 2006 01:32:31 -0700, "kanze" :

CColorAssociation est une classe banale.


C-à-d ? Il n'y a pas de classes « banales ».


En voyant le mot "banal", j'ai cru qu'il parlait d'une classe
"gentille" (i.e. aussi facile à utiliser que int : copiable,
etc.), mais manifestement ce n'est pas le cas de
CColorAssociation...


Mais c'était un peu mon point. Il n'y a pas que des classes à
sémantique de valeur. Et ce qui est « banale » dépend bien du
rôle de la classe dans l'application -- une classe d'entité qui
supporte la copie et l'affectation ne serait certainement pas
banale.

(Sinon, je jouais un peu sur le mot. Une classe « banale »
serait une classe sans intérêt. Et qui a le temps à écrire des
classes sans intérêt.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Avatar
Fabien LE LEZ
On 13 Apr 2006 09:54:33 -0700, "kanze" :

Et qui a le temps à écrire des
classes sans intérêt.)



Je connais des profs qui écrivent _pour_ des classes sans intérêt,
mais je digresse.

Avatar
espie
In article <443d4f7c$0$7738$,
Delf wrote:
Bonjour.

Je pédale dans la semoule, j'y comprends plus rien.

J'ai une classe CAdvLogger qui contient entre autre le membre suivant:

std::map<int, CColorAssociation> m_ColorAssociationMap;



Tous les containers de la STL ne savent gerer que des types qui ont une
semantique de valeur. Ca veut dire en particulier que tes CColorAssociation
sont susceptibles d'etre dupliques, copies, initialises a une valeur par
defaut, et detruits sans prevenir.

Deux questions a se poser:
- est-ce que c'est bien le type de semantique dont tu reves. En particulier,
si je prend un CColorAssociation et que je le copie, est-ce que j'obtiens
bien deux fois `le meme' objet.
- dans l'hypothese ou c'est le cas, est-ce que c'est efficace ? std::map
a le droit de faire plein de copies de l'objet en question, ce qui a un cout.

Sinon, ben prend un pointeur effectivement. Ca va bien sur t'obliger
a gerer un tantinet la memoire (ou bien sinon, les smart pointers du tr1),
mais le compilo ne gueulera plus parce qu'il sait copier des pointeurs, et
il a meme une jolie notion de pointeur nul.

Avatar
kanze
Marc Espie wrote:

[Juste un détail de vocabulaire...]

Deux questions a se poser:

- est-ce que c'est bien le type de semantique dont tu reves. En
particulier, si je prend un CColorAssociation et que je le copie,
est-ce que j'obtiens bien deux fois `le meme' objet.


Non. Tu obtiens deux objets distincts avec la même valeur. Avec une
définition de « même valeur » qui dépend de comment tu as défini
le
constructeur de copie ou l'opérateur d'affectation.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

1 2