|
WREY wrote:
Would the following cause a memory leak?
Why ask? Running your code in the debugger will tell you (upon exit) if any memory was not freed.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
To add to that you should run the code in Debug Mode. by pressing F5
"When death smiles at you, only thing you can do is smile back at it" - Russel Crowe (Gladiator)
|
|
|
|
|
That was a given. Running the program in any other fashion does not invoke the debugger and thus does not show any memory leaks.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
It might be a given to you, but reading some of the other questions in here lead me to believe that we must assume nothing when posting replies 
I thought some of the people I'd worked with didn't know much...
Steve S
|
|
|
|
|
True. I did consider past posts by WREY and felt that he at least had that much know-how. He does have an air of confidence about him, and thus I was willing to forgo a more detailed answer.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Occasionally when reading some of the questions I think to myself
"an MSDN search for x and y would tell you that", and then something comes along that makes me think of the things I thought I knew that just got corrected.
In quiet moments, I consider some of the comments I've read in other people's code or in documentation, such as
"lint's tiny little mind is fried!" - actual program output from a UNIX lint run
"Stop the forking loggers" - comment in /etc/init source code
"Abandon hope all ye who enter here" - seen in Emacs memory management code
and my personal favourite:
"Wisdom and informed courage count for much" - fsdb* man page
Steve S
* fsdb, for the younger generation, is a file system debugger, often used to patch a damaged filesystem to recover data, in the days when dinosaurs ruled the Earth, and Peter Norton did not grace the cover of a book.
|
|
|
|
|
You presumed I did not run the debugger, and you presumed I would not have run it in Debug Mode. How thoughtful of you.
Thank you for your presumptions.
William
Fortes in fide et opere!
|
|
|
|
|
Thanks for your reply.
I did run debug, but some of the things I saw I didn't fully understand. For example, I was looking to see if the value of certain pointers would be 0x00000000 at the conclusion of the program where breakpoints were set (that, plus any message about unfreed memory). When none of those indications were observed, I didn't know what to believe.
My decision now is to just delete all members of the array (the long way) using embedded 'for' statements.
William
Fortes in fide et opere!
|
|
|
|
|
If you can set a breakpoint (that is reached) on the delete *pMySt[i] statement, and not see a "Detected memory leaks!" message in the Debug tab of the Output window, you have no memory leaks.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Thank you again for your reply.
No "Detected memory leaks!" message was observed anywhere!!
I believe, looking for values of certain pointers was not a good thing to do. I thought those pointers would show no values (sort of equivalent to NULL) which would then indicate they were NOT pointing to anything, and therefore indicating (memory of) the array had been properly deleted.
Thanks for your help. I appreciate it.
William
Fortes in fide et opere!
|
|
|
|
|
As an afterthought, I commented out the "delete" statement to which you refered, compiled and run the program over, and saw no message about any memory leak detected!!
Shouldn't I have seen a memory leak message (considering quite a number of those objects were created)?
Yes, I did run the debugger. (VC++ 6.0, using Win2K)
William
Fortes in fide et opere!
|
|
|
|
|
Well, not having everything in front of me, I may not be 100% accurate in reproducing this. I added the following to an existing project I was working on:
class CMyDialog : public CDialog
{
public:
CMyDialog();
~CMyDialog()
{
delete pMySt[0][0];
}
BOOL OnInitDialog()
{
CDialog::OnInitDialog();
pMySt[0][0] = new MyStruct();
return TRUE;
}
struct MyStruct
{
} *pMySt[10][10];
};If the delete statement was commented out, a memory leak was indeed detected.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Any array value that you assign to needs to have delete called on it. If you need to use delete rather then using one of the various smart pointers out there, then I've found the following very helpful.
1. Always initialize all pointers to NULL.
2. Set the pointer to NULL after you call delete.
Note. it is always safe to call delete NULL, but smart pointers are much better.
BTW. it looks like you are only deleting the first 10 entries in a 121+ element array. You might just need to fix by changing your destructor loop to
for(int i=0; i
|
|
|
|
|
HI u all gurus on code project
i am a beginner in vc++ . i am trying to make a plugin like visualisation ..for wmp.I read info from msdn. but i need some more .
anybody done this kind of stuff.Can anybody give me some sample code.so that i can understand..
or suggest any link about this.
Reply me soon
rahul
|
|
|
|
|
|
I have a small dialog based code that proceeds through several dialogs to input data into a database. I have developed this on two separate machines and it works fine, when I copy the files to a third machine the code fails to open the second, or any subsequent, dialogs. I am using peekmessage to handle WM_DESTROY.
Many Thanks for any suggestions
|
|
|
|
|
This could be due to a number of reasons. Anything from invalid database connection, to differences in Operating Systems.
A little more information is needed to trace this problem down.
I Dream of Absolute Zero
|
|
|
|
|
Here is the code that causes problem, CIOC_Login is a CDialog based class:
<br />
while (control.Login == FALSE)<br />
{<br />
dlg0 = new CIOC_Login();<br />
m_pMainWnd = dlg0;<br />
nResponse0 = dlg0->DoModal();<br />
::PeekMessage(&msg,NULL,WM_QUIT,WM_QUIT,PM_REMOVE);<br />
...........<br />
...........<br />
delete dlg0;<br />
}<br />
....<br />
....<br />
while (nControl !=2) <br />
{<br />
int nResponse1;<br />
nResponse0 = dlg1.DoModal(); <-- Doesn't open!<br />
::PeekMessage(&msg,NULL,WM_QUIT,WM_QUIT,PM_REMOVE);<br />
|
|
|
|
|
MSDN articles Q138681 and Q253130 might be of interest to you.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Thanks, deleting the reference to m_pMainWnd solved the problem.
AndyB
|
|
|
|
|
Hello,
I have a MDI type application with 2 different views. I create the CDialogBar in my CChildFrame class so the DialogBar is viewed with in the child frame. I want to catch WM_LBUTTONDOWN messages for the dialog bar but can't. I have tried to catch this msg in CChildFrm::WindowProc and other obvious areas but never see the message.. I used spy++ and can see a WM_SETCURSOR msg being sent to the ChildFrame with a WM_LBUTTONDOWN as part of the WM_SETCURSOR message (kinda confusing).. Any ideas?
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Never mind, I figured it out.
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Ok, so I'm writing a multi-user database app. The downside is that I am interfacing with Access databases. Now it's not like hundreds of users, but maybe tens of users, so here is my design dilemma...
Should I:
A. Create a connection to the database and keep that connection open during the application lifetime.
B. Create a connection to the database, buffer the data, close the connection, and then only reconnect to commit changes.
C. Open and close the connection each time data is updated WITHOUT buffering the data.
D. Some other idea?
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
I guess the methods of keeping your "connetion pool" will differ, depending on your software circumstances.
I would never by default consider C., because it can eat up considerable amount of time each time you connect. But this may be necessary on a stateless Client/Server program.
Personnally, I tend to keep a db connection, disconnecting after a specified amount of inactivity, then reconnect when required.
I Dream of Absolute Zero
|
|
|
|
|
The answer really depends upon the frequency that the user will hit the database. Remember, connecting to a database is very expensive, so if the users will be accessing the database more than every couple of minutes, it makes sense to connect and keep the connection open.
onwards and upwards...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
