|
#pragma warning(disable:4786)
put this before (and sometimes after) any STL includes.
it's a harmless warning.
-c
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
Thank you very much.
I also had another question. Do you have any idea of the performance benefit or degradation when using STL containers instead of MFC containers? I have a set of programs that makes extensive use of MFC containers. But, for a new version of the program, I wanted to use SMART pointers and found that MFC containers are not typesafe. Hence the reason to move to STL. But, I also do not want to find out later that there is a performance degradation.
How would you rate MFC vs STL container (specifically maps) performance? Would using a library from stlport.org help?
Thanks again
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
i've heard VC's STL maps can be slower than MFC's CMap. but, i've also heard that other STL implementations can be faster.
try www.deja.com
-c
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
MFC containers are not typesafe??? What do you mean, which ones are you using?
Regards,
Alvaro
|
|
|
|
|
CPtrList, CTypedPtrList, CMapStringToPtr etc...
None of them are typesafe.
-Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Woah!
CPtrList is not type safe since it holds a list of void pointers. But CTypedPtrList is a type-safe “wrapper” for objects of class CPtrList (according to MSDN).
The CTypedWhatever classes are type-safe. The only ones that aren't are the CPtrWhatever and the CObWhatever classes. Also, CArray, CMap, and CList are type-safe.
Regards,
Alvaro
|
|
|
|
|
In general, you can suppress this warning using the pragma directive
#pragma warning(disable:4786)
However, this does not always work - in particular, I have noticed problems when mixing STL and MFC with the DEBUG macro (and adding in DLLs just for good measure). Microsoft has acknowledged that this pragma does not always work :
http://support.microsoft.com/support/kb/articles/Q167/3/55.ASP - "BUG: C4786 Warning Is Not Disabled with #pragma Warning"
You should also look at installing and using the "STL Error Message Filter" from BDSoft (http://www.bdsoft.com/tools/stlfilt.html) - it's free, and very, very good at turning STL errors into english!
-----------------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."
|
|
|
|
|
In my case the pragma directive works. Maybe because I am not using MFC in this application at all.
Also, I asked earlier also, do you have any experience using STL containers and their relative performance compared to MFC containers, especially maps?
Thanks a lot.
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
No, I have no idea of the relative efficiencies of MFC versus STL containers - I have been using STL heavily for the past 3 years, and prior to that I used a library of custom built containers. I have never used MFC containers. I would expect STL to be similar to MFC in performance, but I do know that there have been examples of STL running much slower than MFC in specific instances. I believe this is due mainly to the fact tht MFC was designed in the early ninties, when PCs were NOT equiped 1gig CPUs, and therefore a fair amount of effort went into building a libraray that had reasonable performance. STL, on the other hand, is designed for portability and flexibility (via extension), and the entire container/iterator/algorithm framework has at least some inherent overhead. I have never found STL to be a 'choke-point' in my code, however.
Your quickest answer is probably to code up a simple test - build a small MFC exe that has a std::map and a CMap, then try filling, sorting, searching, removing. put it all into a loop, run it 10000 times, see how long it takes.
-----------------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."
|
|
|
|
|
Yes .. I will be doing that. I was getting some peer opinion/experiences also. I did not want to find out something late in the development stage.
Thanks for the info. I will post the results of my test.
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
I want my CStatic behind all other buttons, edit controls etc.
It's a bitmap static and how to do that!??
// DeRGTT
|
|
|
|
|
Don't use a static - draw the bitmap onto the background instead.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Ok... how to do that then!
|
|
|
|
|
|
|
Hi,
Going over some code in a multithreaded library I came across a snippet that bewilers me, and I was hoping one of you can make sense of it for me. It is part of a multi-threaded application. First there a global structure declared.
struct CustomStruct
{
CWnd* pCwnd;
int* pInt;
long* plong;
}
These are the same declarations but I can't recall them. But they are all pointers to some value. Then in one member function part of a class there is this call.
...
CustomStruct* pCS=new CustomStruct;
pCS->pCwnd=AfxGetMainWnd();
pCS->Int=&IntVariable;
pCS->plong=&LongVariable;
CreateThread(...(Pass the above struct address as LPVOID)
And in the static function for the thread we have
CustomStruct* pCS=(CustomStruct*)wParam;
CWnd* pCwnd=pCS->pCwnd;
int* pInt=pCS->pInt;
long* plong=pCS->plong;
delete pCS;
How does the delete portion of the code work? I don't understand how we can delete the structure here and still have access to the new pointers we declared in the function? How can we delete the structure and still have the data stored in the pointer still be valid? Did we not get rid of that data with delete? I'm confused please explain.
Thanks in Advance.
Sam C
----
Systems Manager
Hospitality Marketing Associates
|
|
|
|
|
As you noticed, the temporary structure just contains a window handle and pointers to other variables. Once these values are copied from the structure, it can be deleted.
The original variables that the pointers referenced still exist.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Thanks. I get it now, but what if we change the pointers to be straight variables. For example, remove the CWnd* and change the other to to long and int (instead of long* and int*) then by deleting the structure this time we remove those variables from memory? And the above example I gave will no longer be valid?
Thanks for helping out I didn't have pointer problems or memory allocation problems using VB
Sam C
----
Systems Manager
Hospitality Marketing Associates
|
|
|
|
|
Think about CustomStruct as a disposable paper bag. Inside there are three things: a pointer to CWnd, a pointer to int, and a pointer to long. You take these things out of the bag, and get rid of the bag.
'delete' destroys only a memory block that holds three pointers. These three pointers remain perfectly valid.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Thanks for some reason I was thinking it "destroyed" everything. So only the pointers are deleted but not the actual value stored in memory. So if these weren't pointers then we would have a "memory" leak problem? Say for instance we remove the CWnd, but keep int and long we call delete would those values be removed from memory?
Sam C
----
Systems Manager
Hospitality Marketing Associates
|
|
|
|
|
You're almost there!
Yes, when 'delete' is called on the struct/class, the members are destroyed. If those members are pointers, then the pointer is destroyed, but not what is pointed to. If you have no other pointer to the 'pointed to' object, then you have a memory leak (remember - you can have multiple pointers pointing to the same memory address/object).
If you want the things that are 'pointed to' to be destroyed when you call 'delete', you write a destructor that does this. As a general rule (there are always exceptions, and the code you are looking at is one of those exceptions)
if a class/struct contains pointers, it should also have a destructor that 'cleans up' the pointed to objects. And a copy constructor and an assignment operator - but that's getting a little too complicated for now!
So far, so good (I hope).
If the members are just 'builtin types' like int, then when delete is called the int is destroyed. However, in your code you copied the int value from the struct just before calling delete. Therefore, the 'int' in the struct is removed from memory by the call to delete, but the copy you made still remains valid, becuase it is a different copy of the int value from the struct. Er... I think that's what I'm trying to say!
-----------------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."
|
|
|
|
|
I think the easy way to get your head around pointers is to think of them as addresses. the RAM (memory) is a street, and every house on that street has an address (a pointer). If you want to tell your friend to go to a certain house, you write the address on a piece of paper, and you give him the paper (you have just passed a pointer, in a customstruct(on paper)), then he goes out and meets another friend, who also wants the addresses that he writes in his notebook (gets a copy of the pointer). Now your friend decides he doesn't need the address any more so he throws away the paper (deletes the custom struct, but the memory(house) still exists). As long as the house exists the address is valid, but if the house burns down (your object is deleted from memory) the address will point to an empty lot (invalid memory).
I hope this helps, this analogy helped me understand pointers
---
Blessed are those who can laugh at themselves, for they shall never cease to be amused
|
|
|
|
|
Actually this is a very good analogy!!! I GET IT (somewhat) NOW! Thanks for that analogy I really appreciate it.
Sam C
----
Systems Manager
Hospitality Marketing Associates
|
|
|
|
|
Just wanted to give everyone a blanket THANKS. I finally am getting a good grasp of everything that is being said about pointers. I thought I had a good grasp before, but that creating a structure and then deleting it in another function kind of killed me
But thanks to all for being patient and taking the time to help me understand this one concept better.
Sam C
----
Systems Manager
Hospitality Marketing Associates
|
|
|
|
|
I created by Wizard ATL COM DLL that import my MFC extention DLL(from type: base Dialog) in my ATL.
Please check my steps (describes below) and tell me if I miss something.
(because when I try to perform its function from client program it become crazy)
------------------------------------------------------------------------
1. I opened project: ATL COM Wizard. [DLL] [MFC Support]
2. I inserted to the library that created the file : MyMfcDll.dll
and attached to the ATL project the files : MyMfcDll.h , MyMfcDll.lib
3. I Added by wizard ATL class [MyClass] [single] [dual]
4. I added by wizard method [ShowMfcDialog] to IMyClass and fill it so :
___________________________________________
#include "MyMfcDll.h"
STDMETHODIMP CMyClass::ShowMfcDialog()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState())
CMyDialog dlg; //from the imported dll
dlg.DoModal();
return S_OK;
}
______________________________________________
5. I registered the dll (regsvr32)
and that's all !
What is missing ?
I will be greatful if you will help me ! PLEASE !!!!!
|
|
|
|