I'm trying to "include" a CMap in another CMap, and it isn't working
very well...
Here's the faulting code:
******* IAMMetaDataCategory.h **********
#pragma once
#include "IAMMetaDataAttribute.h"
class CIAMMetaDataEvent
{
public:
CIAMMetaDataEvent(void);
~CIAMMetaDataEvent(void);
CString m_name;
CString m_resourceId;
CMap <int, int, CIAMMetaDataAttribute, CIAMMetaDataAttribute>EvtAttributes;
};
******* IAMMetaDataAttribute.h **********
#pragma once
class CIAMMetaDataAttribute
{
public:
CIAMMetaDataAttribute(void);
~CIAMMetaDataAttribute(void);
CString m_name;
bool m_multiValued;
CString m_transform;
CString resourceId;
CMap <int, int, int, int> alternateValue;
};
Trying to compile the above code throws the error:
IAMMetaDataCategory.cpp
c:\program files\microsoft visual studio
8\vc\atlmfc\include\afxtempl.h(1339) : error C2248: 'CObject::CObject' :
cannot access private member declared in class 'CObject'
c:\program files\microsoft visual studio
8\vc\atlmfc\include\afx.h(558) : see declaration of 'CObject::CObject'
c:\program files\microsoft visual studio
8\vc\atlmfc\include\afx.h(529) : see declaration of 'CObject'
This diagnostic occurred in the compiler generated function
'CMap<KEY,ARG_KEY,VALUE,ARG_VALUE>::CMap(const
CMap<KEY,ARG_KEY,VALUE,ARG_VALUE> &)'
with
[
KEY=int,
ARG_KEY=int,
VALUE=int,
ARG_VALUE=int
]
Any idea of what the problem is? The problem seems to come from the
second CMap (in IAMMetaDataAttribute), but I can't figure out what's
wrong...
Thanks for your help.
Fred
-> please read "CIAMMetaDataCategory" instead of "CIAMMetaDataEvent"
[snip]
Thanks.
Fred
<code>
...
private:
CObject(const CObject& objectSrc); // no implementation
void operator=(const CObject& objectSrc); // no implementation
...
</code>
So, CMap doesn't offer a copy semantic "out of the box".
I would suggest you to use STL std::map container, which is designed in a
way to implement copy semantic out-of-the-box.
In particular, your CMap's:
CMap <int, int, CIAMMetaDataAttribute,
CIAMMetaDataAttribute>EvtAttributes;
CMap <int, int, int, int> alternateValue;
could be substitued by the following std::map's:
std::map< int, CIAMMetaDataAttribute > EvtAttributes;
std::map< int, int, > alternateValue;
Note that std::map does not have the (IMHO) confusing ARG_KEY and ARG_VALUE
templates.
std::map just has the Key and Type template arguments (in its basic form):
map Class (Standard C++ Library)
http://msdn.microsoft.com/en-us/library/s44w4h2s%28VS.80%29.aspx
HTH,
Giovanni
"Fred" <fr...@laposte.net> ha scritto nel messaggio
news:4af7f6e2$0$10817$426a...@news.free.fr...
> I'm trying to "include" a CMap in another CMap, and it isn't working very
> well...
>
> [...]
>
> Trying to compile the above code throws the error:
> IAMMetaDataCategory.cpp
> c:\program files\microsoft visual studio
> 8\vc\atlmfc\include\afxtempl.h(1339) : error C2248: 'CObject::CObject' :
> cannot access private member declared in class 'CObject'
> c:\program files\microsoft visual studio
> [...]
Hi Giovanni,
thanks for the tip.
In the meantime, I managed to solve my problem by declaring a pointer to
the second CMap instead of the CMap itself.
i.e:
******* IAMMetaDataAttribute.h **********
#pragma once
class CIAMMetaDataAttribute
{
public:
CIAMMetaDataAttribute(void);
~CIAMMetaDataAttribute(void);
CString m_name;
bool m_multiValued;
CString m_transform;
CString resourceId;
CMap <int, int, int, int> *alternateValue;
};
So I guessed I could get out with it this way... but your post about the
std::map object puzzled me ;)
Could you tell me more about this std::map thing? Is it more efficient
than CMap? It seems to be less convenient to manipulate, isn't it?
Thanks again for your help.
Fred
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Fred
Joseph M. Newcomer a �crit :
> thanks for the tip.
You are welcome.
> In the meantime, I managed to solve my problem by declaring a pointer to
> the second CMap instead of the CMap itself.
> i.e:
> ******* IAMMetaDataAttribute.h **********
> #pragma once
>
> class CIAMMetaDataAttribute
> {
> public:
> CIAMMetaDataAttribute(void);
> ~CIAMMetaDataAttribute(void);
>
> CString m_name;
> bool m_multiValued;
> CString m_transform;
> CString resourceId;
>
> CMap <int, int, int, int> *alternateValue;
> };
OK, defining CMap as a pointer in above context I think that you are going
to shoot yourself in the foot.
In fact, there is a reason of the previous compiler error about CMap: the
compiler was trying to warn you: "CMap can't be deep-copied, CMap does not
have a copy semantic".
If you define a data member as a pointer to CMap you are shutting up the
compiler.
But you are preparing for troubles. In fact, if two instances of
CIAMMetaDataAttribute are going to be copied, the value of the pointer (i.e.
a memory address) is copied, and not the CMap instance itself.
So, in the above class, you should forbid copy semantic, declaring private
copy constructor and operator= for CIAMMetaDataAttribute.
Or just use std::map, which is copyable.
> So I guessed I could get out with it this way... but your post about the
> std::map object puzzled me ;)
> Could you tell me more about this std::map thing? Is it more efficient
> than CMap? It seems to be less convenient to manipulate, isn't it?
I'm not sure about efficiency. You should do some benchmarks in that regard
(Joe told us an importan lesson: "When you are in doubt, measure.").
I think that STL standard states that std::map insertion is O(log(N)), but
I'm not sure.
Moreover, IIRC, std::map is implemented as a kind of binary tree. If you
really want an hash-map data structure container, it is called hash_map
(probably its namespace is 'stdext', not 'std').
If you are not interested in sorting keys, stdext::hash_map may be faster
than std::map.
Moreover, as already stated, std::map is copyable, and CMap is not.
If I could do a criticism to std::map, it would be that I prefer identifier
names like 'key' and 'value' instead of 'first' and 'second'.
Moreover, I would have liked a member function something like contains() to
check if a key is stored in a std::map instance.
Instead, we have to write code like this:
std::map< string, int > someMap;
...
if ( someMap.find("Connie") == someMap.end() )
{
... "Connie" is not in the map.
}
I would have preferred something like 'someMap.contains("Connie")' instead
of comparing to someMap.end().
(Note that QT QMap has an intuitive method named 'contains' that does just
that: http://qt.nokia.com/doc/4.0/qmap.html#contains )
HTH,
Giovanni
> Thanks to all for the answers.
> I'm moving to std::
Note also that you can mix std:: container classes like std::map with
ATL/MFC convenient classes, like CString.
i.e. you can build maps in which keys and/or values are instances of
CString.
Giovanni
Thanks again Giovanni for your explanations.
I've followed your advise and I'm implementing the std::map solution :)
Fred
Ha, when it became apparent MS had no intention of improving its base
classes such as CMap, and the alternative was to learn std::map, you know
what I did? I learned C# and .NET instead! ;) (And Qt after that....)
Call me an escapist, but life is too short.
-- David
I'll try a shot at that question.
Implementation-wise, difference is significant. CMap is a hash map
(http://en.wikipedia.org/wiki/Hash_table), whereas std::map is based
on key ordering. Often, std::map internally uses a data structure
called red-black tree (http://en.wikipedia.org/wiki/Red-black_tree).
As a consequence, they have wildly different performance
characteristics, but never mind that, I don't think anyone can tell
you whether one will perform better on your own data. Speed of your
hashing function when using CMap, and operator< when using std::map,
plays a part, too.
You should also bear in mind that for small data sets, a linear search
on an array will beat any associative container. In that light, for
me, using an associative container is often a matter of convenience
rather than speed (e.g. avoids handling duplicates and I don't have to
write "find" function).
As for convenience, I fail to see how is any STL container less
convenient than it's MFC counterpart. Take a map:
* to insert an element, it's MFCMap.SetAt(key, value) or MFCMap[key] =
value versus STLMap[key] = value or STLMap.insert(SLMapType(key,
value)). With STL map, you have performance-conscious insert overload,
where you can specify the position. That's useful when you use find or
lower_bound and subsequently decide to insert a new element.
* to remove an element, you use MFCMap.RemoveKey versus STLMap.erase,
where erase is overloaded to three options, one of them being
performance-conscious, and other working on a range of elements
(sweet).
* to locate an element, you use MFCMap.Lookup(key, value) or PLookup
versus STLMap.find or lower_bound, both being more performance-
conscious in STLMap ( this is getting annoying now :-) ).
* to iterate, I fail to see how is brain-dead GetStartPosition/
GetNextWhatever and POSITION convention of MFC better than a for,
while or std::for_each.
It should be noted, however, that STL induces a certain amount of
syntax gibberish. To alleviate that, it's best to typedef every
container type and use STL-provided typedefs, e.g.:
typedef std::map<my_key_type, my_value_type> CMyMap;
CMyMap map;
for (CMyMap::const_iterator pItem=map.begin(); pItem != map.end(); +
+pItem)
{
CMyMap::const_reference KeyAndValue = *pItem;
WorkWith(KeyAndValue);
}
To me personally, map is better than CMap in that I prefer writing an
ordering predicate (operator<) to writing a hashing function.
Depending on key structure, a hashing function is more complicated,
and can cause a performance hit more easily.
What you don't have with STL out of the box is serialization.
HTH,
Goran.
> It should be noted, however, that STL induces a certain amount of
> syntax gibberish. To alleviate that, it's best to typedef every
> container type and use STL-provided typedefs, e.g.:
>
> typedef std::map<my_key_type, my_value_type> CMyMap;
> CMyMap map;
> for (CMyMap::const_iterator pItem=map.begin(); pItem != map.end(); +
Probably the new 'auto' keyword of C++0x (available in VS2010) will make
things better in this regard.
> What you don't have with STL out of the box is serialization.
MFC built-in serialization is not very good IMHO.
XML is better in this regard.
Giovanni