CArray of stdext::hash_map<int,int> not possible ( access violation ) ?
in [MFC]
|
Prev: about changing dialog box property at run time
Next: [Q] CTabCtrl/CBitmapButton: custom color for the WHOLE background
From: Stephan T. Lavavej [MSFT] on 10 Mar 2010 18:09 CArray memcpys its elements and is therefore incompatible with non-PODs (POD = Plain Old Data) such as all STL containers. This particular code doesn't crash with VC10, but a trivial modification does crash: C:\Temp>type meow.cpp #include <afxtempl.h> #include <hash_map> int main() { typedef stdext::hash_map<int, int> MAP; CArray<MAP> test; MAP item; test.Add(item); test.Add(item); test[0][111] = 222; test[0][333] = 444; test[1][555] = 666; test[1][777] = 888; test.RemoveAll(); } C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp meow.cpp _WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h) C:\Temp>meow [BOOM] Please don't modify _ITERATOR_DEBUG_LEVEL (formerly _HAS_ITERATOR_DEBUGGING/_SECURE_SCL) without knowing exactly what you're doing. That's like silencing compiler warnings without understanding them. Because the STL works with non-PODs, STL containers can hold ATL/MFC objects. (They just need to be copyable and assignable - only overloaded op&() presents problems.) (CArray also has a terrible growth policy.) Stephan T. Lavavej Visual C++ Libraries Developer "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message news:e$9NudHwKHA.3952(a)TK2MSFTNGP06.phx.gbl... > "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> ha scritto nel > messaggio news:#$kXYmGwKHA.5940(a)TK2MSFTNGP02.phx.gbl... > >> I'll let you know if I have some more information... > > A small update: I've just tried in VS2010 RC, and the code runs fine (no > access violation). > > Giovanni > >
From: Giovanni Dicanio on 11 Mar 2010 03:22 "Stephan T. Lavavej [MSFT]" <stl(a)microsoft.com> ha scritto nel messaggio news:ujPN#aKwKHA.1796(a)TK2MSFTNGP02.phx.gbl... > CArray memcpys its elements and is therefore incompatible with non-PODs > (POD = Plain Old Data) such as all STL containers. Wow... memcpy's in C++ code to do copies... this is epic failure. > Please don't modify _ITERATOR_DEBUG_LEVEL (formerly > _HAS_ITERATOR_DEBUGGING/_SECURE_SCL) without knowing exactly what you're > doing. That's like silencing compiler warnings without understanding > them. Thanks. So this seems to confirm what I wrote above to the OP: > If I were you, I would trust STL's _H.I.D., and would get rid of CArray > storing the hash_map, and use std::vector instead. > Because the STL works with non-PODs, STL containers can hold ATL/MFC > objects. (They just need to be copyable and assignable - only overloaded > op&() presents problems.) But thanks to CAdapt I think these problems could be solved (at least for some classes): http://msdn.microsoft.com/en-us/library/bs6acf5x(VS.80).aspx > (CArray also has a terrible growth policy.) Yes, the arithmetic growth... Thanks for your post, Giovanni
From: Oliver Regenfelder on 11 Mar 2010 03:55 Hello, Stephan T. Lavavej [MSFT] wrote: > CArray memcpys its elements and is therefore incompatible with non-PODs > (POD = Plain Old Data) such as all STL containers. This particular code > doesn't crash with VC10, but a trivial modification does crash: Thanks for the info! Is this mentioned anywhere on the msdn MFC documentation of CArray? Interestingly there is the CopyElements helper which is used for the CArray::Append and CArray::Copy methods used to append/copy complete arrays. This method uses operator= according to the dokumentation. So assigning to a CArray would use memcpy, while appending would use operator= ? Best regards, Oliver
From: Joseph M. Newcomer on 16 Mar 2010 21:19 It is worth noting the && (rvalue-reference) and "move semantics" for copying values which means operator = can be overloaded with a && (rvalue-reference) parameter, and whose implementation can just copy the pointer to the data and not the data itself, causing tremendous performance improvement because no actual copy of the data is done (the RHS of the assignment is recognized as a temporary which will be discarded upon completion of the expression). This is a significant improvement in the C++ language supported in VS2010 and STL makes heavy use of it to improve performance, as does some of MFC. I've devoted about 20 slides to this feature in my new VS2010 course. Very valuable for inter-thread message passing as well. joe On Wed, 10 Mar 2010 16:51:42 +0100, "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote: >"Adam" <adam_mich(a)gazeta.pl> ha scritto nel messaggio >news:8e5420ef-ab34-4c5c-975e-860b9e114b99(a)c16g2000yqd.googlegroups.com... > >>> These could be error messages generated by the Iterator Debugging feature >>> of >>> Microsoft VC++'s STL implementation. >> >> In fact. In VS2005 SP1 Vista it starts to crash in a different place, >> so _SECURE_SCL has also be set to 0. >> >> #define _SECURE_SCL 0 >> #define _HAS_ITERATOR_DEBUGGING 0 >> >> It solves(?) the problem. > >I'm not sure it actually solves the problem... > >My understanding is that both _SECURE_SCL and _HAS_ITERATOR_DEBUGGING should >help the programmer preventing shooting his own foot. > >I'm more oriented in thinking that there could be subtle bugs that may arise >in using STL containers inside MFC's CArray. > >I'll let you know if I have some more information... > >Giovanni > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 16 Mar 2010 21:26
SEe below... On Thu, 11 Mar 2010 09:22:19 +0100, "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote: >"Stephan T. Lavavej [MSFT]" <stl(a)microsoft.com> ha scritto nel messaggio >news:ujPN#aKwKHA.1796(a)TK2MSFTNGP02.phx.gbl... > >> CArray memcpys its elements and is therefore incompatible with non-PODs >> (POD = Plain Old Data) such as all STL containers. > >Wow... memcpy's in C++ code to do copies... this is epic failure. **** It only does this if the default assignment operator is in effect, which is why it only works for PODs. Generally, it results in a compiler error if it would have to do assignments and there is no assignment operator. If the POD assignment would work, it apparently falls through and use memcpy, which is actually correct for POD. ***** > > >> Please don't modify _ITERATOR_DEBUG_LEVEL (formerly >> _HAS_ITERATOR_DEBUGGING/_SECURE_SCL) without knowing exactly what you're >> doing. That's like silencing compiler warnings without understanding >> them. > >Thanks. So this seems to confirm what I wrote above to the OP: > > > If I were you, I would trust STL's _H.I.D., and would get rid of CArray > > storing the hash_map, and use std::vector instead. > > >> Because the STL works with non-PODs, STL containers can hold ATL/MFC >> objects. (They just need to be copyable and assignable - only overloaded >> op&() presents problems.) > >But thanks to CAdapt I think these problems could be solved (at least for >some classes): > >http://msdn.microsoft.com/en-us/library/bs6acf5x(VS.80).aspx > > >> (CArray also has a terrible growth policy.) > >Yes, the arithmetic growth... **** I got some lovely performance graphs; the time goes up as if y=x*x on the time plot of 10, 100, 1000, 10000, 100000, 1000000 CArray::Add and at a very flat linear slope for std::vector<T>push_back(T v). BUt if you SetSize(0, n) for suitably large n then it is not arithmetic growth for CArray. So we are talking here about default behavior. joe **** > > >Thanks for your post, >Giovanni > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |