|
Check the CMemoryState class which can be used for debug versions only.
Atul
Sonork 100.13714 netdiva
|
|
|
|
|
first make this declaration at the top of your stdafx.h file:
#define _CRTDBG_MAP_ALLOC
next make sure that these files are included in your project:
#include <stdlib.h>
#include <crtdbg.h>
finally, when your program shutsdown, you need to call this function:
_CrtDumpMemoryLeaks();
This will produce an output like this:
<br />
Detected memory leaks!<br />
Dumping objects -><br />
C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\leaktest\leaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.<br />
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD <br />
Object dump complete.<br />
You can click on filename with the line number and it will take you to the place where you allocated the memory. This will be a good place to start.
After you get a list of objects that are leaking, you will now have the allocation number of the block that was leaked. In the example above (18) was the block.
You can run the program again and set a break point when block 18 is allocated. First set a break point right when your program loads.
Declare a variable in your watch window called:
_crtBreakAlloc
Set this variable to 18, this will tell the debugger to break when the 18 block is allocated. With this you can step through the code and know exactly which element that you allocated that is leaking. With this technique it is very important that you perform the exact same operations in the program in order to make the memory allocation follow the same path.
Look up this article on MSDN for more information about this technique:
Detecting and Isolating Memory Leaks Using Microsoft Visual C++ by Edward Wright
This technique is a good, free, place to start, but like other people have said, BoundsChecker is a good place to go if you have the money to buy this tool.
|
|
|
|
|
What I do is I also use the define
#define _CRTDBG_MAP_ALLOC
My stdafx.h has this in it :
<br />
<br />
#ifdef _CRTDBG_MAP_ALLOC<br />
#include "crtdbg.h"<br />
#endif<br />
<br />
and I call this little function in OnInitInstance
or during initialization for non-MFC apps.
<br />
<br />
void EnableMemoryLeakDump( void )<br />
{<br />
#ifdef _DEBUG<br />
<br />
int tmp = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );<br />
tmp |= _CRTDBG_LEAK_CHECK_DF;<br />
tmp &= ~(_CRTDBG_CHECK_CRT_DF );<br />
_CrtSetDbgFlag( tmp );<br />
<br />
#endif // _DEBUG<br />
}<br />
<br />
I don't call anything else and I get leak reports on termination. This works for MFC and straight-Win32 apps.
|
|
|
|
|
Does VC7 support this?
I've been digging through the posts here, and I can't seem to find out. I was hoping someone here could give me a yes or no before I start digging through the M$ site.
And is anyone else disgusted with the state of the VC6 STL implementation code? It has to be some of the worst, most poorly documented code I've seen...
J
|
|
|
|
|
Jamie Hale wrote:
Does VC7 support this?
No, but VC 7.1 will.
I vote pro drink
|
|
|
|
|
Thanks.
J
|
|
|
|
|
VC 7.1 will.
Allegedly. I've come to take MS statements with a grain of salt. When I see it I will believe it.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
Allegedly. I've come to take MS statements with a grain of salt. When I see it I will believe it.
LOL. Then my answer will be:
No, but VC 7.1 should.
I vote pro drink
|
|
|
|
|
Be more assertive. That has been our problem as developers using MS products.
No, but VC 7.1 should. Damnit!
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
I would normally agree, but it has been publically stated by Mr Lippman from memory that Loki and Boost compile with no problems on their internal build of VC7. I doubt they would pull it off and then not release it.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Picture the daffodil. And while you do that, I'll be over here going through your stuff.
|
|
|
|
|
I doubt they would pull it off and then not release it
Keep this for the record, Christian Mr Lippman has embraced with enthusiasm his new role as MS hypeman --his latest article on MSDN Magazine is a thing to forget-- so I'd take this kind of statements very lightly. To the best of my knowledge, there's no current C++ compiler capable of compiling Loki in its entirety (moreover, Loki's source code is not standard compliant in some minor details), so the assertion of VC++ being able to do the job is a rather strong one. But then again, I'd really love to know they're telling the truth (really).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
|
I've seen a lot of discussion about MS not supporting PTS - what the f*** (pardon my french) is PTS? I use templates regularly and afaik I have never had any need for PTS (or maybe I haven't realized it as I don't know what it is... )
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
I'm just starting to understand it, but it goes something like this...
If you have a template
template<typename T>
class Wank {
public:
void Stoo();
};
you can "override" the definition by providing other templates
template<typename T>
class Wank<int> {
public:
void Stoo();
};
template<typename T>
class Wank<T *> {
public:
void Stoo();
};
The first is used when you declare a Wank object with an int parameter - this is called explicit template specialization. The second is used when you declare a Wank object with a pointer parameter - this is called partial template specialization. PTS is used a bunch with STL iterators.
This is just an example. There have been some good articles in CUJ about it, and I have a few books (STL stuff) coming that will hopefully go into much more detail.
J
|
|
|
|
|
I have a project that I moved over to version six (current w/all updates). Since then I added several new classes. Two of these do not appear in the class browser view. One is a xxxDoc and the other is the xxxView. The xxxDoc did appear for awhile but has disappeared. I have rebuilt the .clw file several times thinking the problem is there. The code gets executed, other classes that call on these have no problem. In fact the only problem I can see is the fact that these do not appear in the class browser view, which means that to locate a function, etc., I have to use the find command. Anyone know of an IDE problem that would cause this?
Thanks - Mike
|
|
|
|
|
I know that the class browser has sometimes difficulty to show classes. If you want to make them appear again, just write something in your class (like "int i;"), presse enter, delete it again, or enter a carriage return after the definition and delete it, and you should see your class back again in the class browser.
ex:
class CMyClass : public CDialog
{
-->
class CMyClass : public
CDialog
{
--->
class CMyClass : public CDialog
{
Just do that (do not rebuild or anything), it works again for a moment.i know it is weird, but that´s the only solution I´ve found yet.
RaGe/NewGen
|
|
|
|
|
Check out the great article on VC++ innards. The demo code has a VC++ plug-in called OpenVC. It adds a little "radioactivity" icon to your tool bar, and when you click it, it rebuilds your workspace and classview.
It is extremely handy - I couldn't live without it.
J
|
|
|
|
|
Delete your .NCB file and re-open the project. The add-in referred to by the other poster does this automatically.
HTH
Jignesh
|
|
|
|
|
My Problem is rather complex.
I have created an MFC dialog based Application. There are two windows in
this Dialog, each of them has its own class derived from CDialog - CMainDlg (created by MFC) and CChild (created by adding a Dialog with the Wizard).
I have an CChild member object (name it m_ChildWin) in CMainDlg, in order to be able to open the Child Dialog with m_childwin.CreateWindow(...)
I also have two CListCtrl declared as member variable, one in CMainDlg and one in CChild. I want to access the CListCtrl from CMainDlg with functions from the CChild class. (In fact, CChild is only a setup dialog for CMainDlg).
How do I manage to do this ?
To make things clearer:
class CMainDlg : public CDialog
{
...
CListCtrl m_MainList;
CChild m_ChildWin;
void OnButton
{
m_ChildWin.CreateWindow(...);
}
}
class CChild : public CDialog
{
...
CListCtrl m_SetupList;
void UpdateMainList;
{
How do I update m_MainList from here ?!
}
}
Thanks.
RaGE/Newgen
|
|
|
|
|
Rage wrote:
m_ChildWin.CreateWindow(...);
Hmmm. I'd have thought you'd be better off using Create(). In fact neither CDialog nor CWnd has a member function called CreateWindow.
Rage wrote:
How do I update m_MainList from here ?!
In this particular case since the CMainDlg object is your main window [this being a dialog based app], you can use AfxGetMainWnd() to get a pointer to your CMainDlg object [cast it] and now you have access to m_MainList.
Regards
Nish
Nish was here, now Nish has gone;
He left his soul, to turn you on;
Those who knew Nish, knew him well;
Those who didn't, can go to hell.
I like to on the Code Project
Sonork ID 100.9786 voidmain
www.busterboy.org
|
|
|
|
|
While Nish's answer is strictly correct, I would suggest (from an OO point of view) that this might be a bit safer:
In the CChild class, add a member function called Create, for example, which takes all of the parameters that you would normally need for a Create call and then a CListCtrl pointer as well:
BOOL CChild::Create(CListCtrl *apListCtrl, UINT nIDTemplate, CWnd *pParentWnd)
{
if (CDialog::Create(nIDTemplate, pParentWnd))
{
m_pListCtrl = apListCtrl;
return TRUE;
}
return FALSE;
}
where m_pListCtrl is a CListCtrl * member variable. You can then use this at will without having to rely on calls to AfxGetMainWnd(). Not only does this ensure that the correct list control is used, it means you don't have to make the CListCtrl public in your main dialog class.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
first, thanks for your answer...
Of course, it was Create and not CreateWindow ... sorry ..
Derek Waters wrote:
In the CChild class, add a member function called Create, for example, which takes all of the parameters that you would normally need for a Create call and then a CListCtrl pointer as well:
Sorry, i do not see the point in this, since the dialog is called in CMainDlg with m_ChildWin.Create(nIDTemplate,pParentWnd). Maybe I did not get the thing ?
RaGE
|
|
|
|
|
Basically, I was just using the Create call as a way to pass in the extra parameters you need:
m_ChildWin.Create(&m_MyListCtrl, IDD_MY_CHILD_DIALOG, this)
if:
BOOL CChildDlg::Create(CListCtrl *apListCtrl, UINT nIDTemplate, CWnd *pParentWnd)
{
m_pMyListCtrlPtr = apListCtrl;
return CDialog::Create(nIDTemplate, pParentWnd);
}
so you're intercepting the Create call (but still calling the dialog Create function) to pass in your extra parameters.
As I said, this is just my opinion of how it should be done, feel free to use Nish's method, or any other you can think of.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
I've tried to implement my own message filter (IMessageFilter) in a client that talks to a COM server.
It works if I test it in a simple dialog app, but when I implement it in an SDI app, the filter is never used.
Anyone got any ideas?
Cheers,
/Fredrik
Sonork ID: 100.11430:PhatBoy
|
|
|
|
|
Funny, it works in the SDI app if I call AfxOleInit() first.
In the dialog app there is no need for that.
Cheers,
/Fredrik
Sonork ID: 100.11430:PhatBoy
|
|
|
|