|
The best way to avoid memory leaks is not to cause them in the first place. So....
- avoid using new and delete, make your objects automatic and use "parameterise from the top"
- if you're using arrays use std::vector instead
- if you're using arrays of characters use std::string instead
- use classes to manage resources generally - google RAII and have a read
- don't use raw pointers unless you're interacting with legacy code
Cheers,
Ash
PS: For the pedants - you can break all these rules, but have a reason to apart from "I didn't do that in C" or "I read it in a book by Herb Schildt"
|
|
|
|
|
Just out of curiosity, what did Herb Schildt do?
|
|
|
|
|
Mr. Schildt has written loads of rather bad books about C++. I've met plenty of poor programmers that have learnt C from one of his books thinking they were learning C++. And more annoyingly I bought a couple of his books incredibly cheap from a remaindered book store in 1998 and even though each was the price of a pint of beer at the time I felt exceedingly short changed after reading them.
He's not unique BTW, there are plenty of appalling books out there that try to teach C++ but he's churned out far more than most of the others. What I find particularly distrurbing are the number of professional educators that don't seem to be able to tell what's a good teaching text and what isn't.
Cheers,
Ash
PS: Just so I'm not being wholly negative, there are two very good books to learn C++ from:
- "Accelerated C++" by Koenig and Moo - this is great for experienced programmers who want to learn C++
- "Programming -- Principles and Practice Using C++" by Stroustrup. This is better for people who have no exposure to programming but still gives them a good grounding.
modified on Wednesday, June 9, 2010 7:34 AM
|
|
|
|
|
I have to say your answer is one of the most informative and useful I have seen for a long time. I've learned two new patterns and got some suggestions for further reading.
It's time for a new signature.
|
|
|
|
|
Dear All,
I want to find the handle of parent window containing windowless content. Example of web page containing windowless content is http://www.metacafe.com. On this site video files is getting played in windowless mode i.e. the player is not a window but just an content embedded in some other window (host/parent window). I want to determine handle of this parent window. contrary to this on youtube, the area on which video runs, is in itself a window.
Using spy++, I can determine the hierarchy of window in the IE window and If i will follow this hierarchy I can reach to the host/parent window on metacafe. But I believe it would only be applicable to metacafe. There must be some site which will host windowless content in different windows hierarchy.
So, please let me know if anyone knows how to get window handle of parent/host window containing/hosting windowless content.
Regards
f
|
|
|
|
|
For trancating file size using:
int _chsize( int fd, long size);
require to provide parameter "int fd" i.e. file descriptor.
How to provide file descriptor?
|
|
|
|
|
What's wrong with the previous replies ? Are you too lazy to follow a link and read some documentation ?
|
|
|
|
|
For trancating file size using:
int _chsize( int fd, long size);
require to provide parameter "int fd" i.e. file descriptor.
How to provide file descriptor?
|
|
|
|
|
|
If you have a handle to a file, you can do the same using the SetFilePointer and SetEndOfFile APIs.
|
|
|
|
|
Hi all,
I am trying to read a serial port using this code
DCB dcb;
HANDLE hCom;
BOOL fSuccess;
char *pcCommPort = "COM6";
COMMTIMEOUTS cto;
hCom = CreateFile(pcCommPort,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL
);
if (hCom == INVALID_HANDLE_VALUE)
{
AfxMessageBox("CreateFile failed with error %d.\n");
}
fSuccess = GetCommState(hCom, &dcb);
dcb.BaudRate = CBR_19200;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
fSuccess = SetCommState(hCom, &dcb);
if (!fSuccess)
{
AfxMessageBox("SetCommState failed with error %d.\n");
}
int n = ReadFile(hCom, buff, 128, &readed, 0);
my problem is ReadFile is returning 1 but in bytes read field its returning 0.
Is there anythingthat i am missing
|
|
|
|
|
You didn't set the communication time-out. It is possible that you don't receive any data but the communication times-out without having read anything. Use the SetCommTimeouts in order to specify appropriate timeout values.
|
|
|
|
|
Hi,
I want complete new look and feel with tab control as I desinged. So I want to place my own formatted text along with image on tab control.
How can I do this?
Please suggest any link to do...
|
|
|
|
|
Have a look how this TabCtrl[^] is done.
|
|
|
|
|
Hi
I am using SDI in windows explorer style.
The right view contains a formview and left view consits of treeview.
In formview i m tryin to transfer the list control data to Excel sheet.
Im using excel automation ...
But its throwing run time error.
Can Anyone Help me...
|
|
|
|
|
You need to give more information.
What is the error message and when this happens.
Try to debug the application.
|
|
|
|
|
I m gettin type redefinition error,
Problem while using excel.h and excel.cpp file.
MoreOver These two files are not generated automatically, i used in VC6 and get that files and copied these files to my current project in vs2005.
The file supports in dialog based projects but not in SDI
Regards
Gany
|
|
|
|
|
Hi,
I am using the following code for years without any complaints. It is used by me in many apps, and included in libs, too many to count.
Always worked a dream.
It concerns an MFC Type CProgressDlg Base Class. A User would derrive his own class thereof, Set a Workerthread function, and the thing takes off as expected.
Here is the Header
<br />
#if !defined(AFX_PROGRESSDLG_H__07E71F2A_E348_47C9_B150_F02855B96859__INCLUDED_)<br />
#define AFX_PROGRESSDLG_H__07E71F2A_E348_47C9_B150_F02855B96859__INCLUDED_<br />
<br />
#if _MSC_VER >= 1000<br />
#pragma once<br />
#endif // _MSC_VER >= 1000<br />
<br />
enum{ <br />
WM_ENDDIALOG=WM_USER+1,<br />
WM_UPDATE_DATA,<br />
WM_SHOULD_TERMINATE,<br />
};<br />
<br />
<br />
class CProgressDlg;<br />
typedef DWORD (CProgressDlg::*PFN_PROGRESS_DLG_THREADPROC)(void);<br />
<br />
<br />
static int (ProgressDlgThread)(void*);<br />
<br />
<br />
class CProgressDlg : public CDialog<br />
{<br />
friend ProgressDlgThread(void*);<br />
<br />
DECLARE_DYNAMIC( CProgressDlg )<br />
<br />
public:<br />
DWORD GetThreadResult();<br />
PFN_PROGRESS_DLG_THREADPROC SetWorkerThreadProcedure(PFN_PROGRESS_DLG_THREADPROC pFn);<br />
void EndDialog(int ExitCode);<br />
BOOL ShouldTerminate(DWORD* pdwReason=NULL);<br />
CProgressDlg(UINT nIDTemplate,CWnd* pParent =NULL); <br />
<br />
protected:<br />
CRITICAL_SECTION m_cs;<br />
virtual void DoDataExchange(CDataExchange* pDX); <br />
virtual BOOL UpdateData(BOOL bSaveAndValidate = TRUE);<br />
virtual void OnOK();<br />
virtual void OnCancel();<br />
virtual BOOL OnInitDialog();<br />
<br />
DECLARE_MESSAGE_MAP()<br />
private:<br />
<br />
void _OnEndDialog(int ExitCode);<br />
void _OnUpdateData(BOOL bSaveAndValidate,BOOL*pbRes);<br />
PFN_PROGRESS_DLG_THREADPROC m_pFnThreadProc;<br />
BOOL m_bShouldTerminate;<br />
int m_nDlgStatus;<br />
DWORD m_dwDlgResult;<br />
DWORD m_dwThreadResult;<br />
CWinThread* m_pWinThread;<br />
<br />
<br />
<br />
};<br />
<br />
<br />
#endif // !defined(AFX_PROGRESSDLG_H__07E71F2A_E348_47C9_B150_F02855B96859__INCLUDED_)<br />
and Implementation.
<br />
<br />
#include "stdafx.h"<br />
#include "ProgressDlg.h"<br />
<br />
#ifdef _DEBUG<br />
#define new DEBUG_NEW<br />
#undef THIS_FILE<br />
static char THIS_FILE[] = __FILE__;<br />
#endif<br />
<br />
<br />
enum{<br />
THREADSTATE_NOT_STARTED=0,<br />
THREADSTATE_RUNNING,<br />
THREADSTATE_COMPLETED,<br />
}; <br />
<br />
IMPLEMENT_DYNAMIC( CProgressDlg, CDialog )<br />
<br />
CProgressDlg::CProgressDlg(UINT nIDTemplate,CWnd* pParent )<br />
: CDialog(nIDTemplate, pParent)<br />
{<br />
<br />
InitializeCriticalSection(&m_cs);<br />
<br />
m_pFnThreadProc=NULL;<br />
m_nDlgStatus=THREADSTATE_NOT_STARTED;<br />
m_dwDlgResult=IDOK;<br />
m_dwThreadResult=0;<br />
m_bShouldTerminate=0;<br />
m_pWinThread=NULL;<br />
<br />
}<br />
<br />
<br />
void CProgressDlg::DoDataExchange(CDataExchange* pDX)<br />
{<br />
EnterCriticalSection(&m_cs);<br />
CDialog::DoDataExchange(pDX);<br />
LeaveCriticalSection(&m_cs);<br />
<br />
}<br />
<br />
<br />
BEGIN_MESSAGE_MAP(CProgressDlg, CDialog)<br />
ON_MESSAGE(WM_ENDDIALOG,_OnEndDialog)<br />
ON_MESSAGE(WM_UPDATE_DATA,_OnUpdateData)<br />
END_MESSAGE_MAP()<br />
<br />
<br />
<br />
static int ProgressDlgThread(void* P){<br />
<br />
ASSERT(P);<br />
CProgressDlg* pDlg=(CProgressDlg*)P;<br />
ASSERT(pDlg->IsKindOf(RUNTIME_CLASS(CProgressDlg)));<br />
<br />
ASSERT(pDlg->m_pFnThreadProc);<br />
pDlg->m_nDlgStatus=THREADSTATE_RUNNING;<br />
<br />
pDlg->m_dwThreadResult=(pDlg->*pDlg->m_pFnThreadProc)();<br />
<br />
pDlg->m_nDlgStatus=THREADSTATE_COMPLETED;<br />
pDlg->EndDialog(pDlg->m_dwDlgResult);<br />
return 0;<br />
<br />
<br />
}<br />
<br />
BOOL CProgressDlg::OnInitDialog() <br />
{<br />
CDialog::OnInitDialog();<br />
<br />
ASSERT(m_pFnThreadProc);<br />
m_dwDlgResult=IDOK;<br />
<br />
m_pWinThread=AfxBeginThread((AFX_THREADPROC)ProgressDlgThread,this);<br />
<br />
return TRUE;
}<br />
<br />
BOOL CProgressDlg::ShouldTerminate(DWORD* pdwReason)<br />
{<br />
BOOL bShouldTerminate;<br />
<br />
EnterCriticalSection(&m_cs);<br />
if(pdwReason)*pdwReason=m_dwDlgResult;<br />
bShouldTerminate=m_bShouldTerminate;<br />
LeaveCriticalSection(&m_cs);<br />
<br />
return bShouldTerminate;<br />
}<br />
<br />
<br />
void CProgressDlg::OnCancel()<br />
{<br />
EndDialog(IDCANCEL);<br />
}<br />
<br />
void CProgressDlg::OnOK()<br />
{<br />
UpdateData();<br />
EndDialog(IDOK);<br />
}<br />
BOOL CProgressDlg::UpdateData(BOOL bSaveAndValidate)<br />
{<br />
ASSERT(m_hWnd);<br />
BOOL bRes=TRUE;<br />
::SendMessage(m_hWnd,WM_UPDATE_DATA,bSaveAndValidate,(DWORD)&bRes);<br />
return bRes;<br />
}<br />
<br />
void CProgressDlg::_OnUpdateData(BOOL bSaveAndValidate,BOOL* pbRes)<br />
{<br />
BOOL bRes=CDialog::UpdateData(bSaveAndValidate);<br />
if(pbRes)*pbRes=bRes;<br />
}<br />
<br />
PFN_PROGRESS_DLG_THREADPROC CProgressDlg::SetWorkerThreadProcedure(PFN_PROGRESS_DLG_THREADPROC pFn)<br />
{<br />
ASSERT(m_nDlgStatus==THREADSTATE_NOT_STARTED);<br />
<br />
PFN_PROGRESS_DLG_THREADPROC pfnOld=m_pFnThreadProc;<br />
m_pFnThreadProc=pFn;<br />
return pfnOld;<br />
}<br />
<br />
<br />
void CProgressDlg::EndDialog(int ExitCode)<br />
{<br />
ASSERT(m_hWnd);<br />
<br />
EnterCriticalSection(&m_cs);<br />
if(m_nDlgStatus==THREADSTATE_RUNNING){<br />
<br />
m_dwDlgResult=ExitCode;<br />
m_bShouldTerminate=TRUE;<br />
LeaveCriticalSection(&m_cs);<br />
<br />
return; <br />
}<br />
LeaveCriticalSection(&m_cs);<br />
<br />
ASSERT(m_dwDlgResult==ExitCode);<br />
<br />
try{<br />
::SendMessage(m_hWnd,WM_ENDDIALOG,m_dwDlgResult,0);<br />
}<br />
catch(...){<br />
return;<br />
}<br />
<br />
}<br />
void CProgressDlg::_OnEndDialog(int ExitCode)<br />
{<br />
try{<br />
m_pWinThread;<br />
m_dwDlgResult=ExitCode;<br />
ASSERT(::IsWindow(m_hWnd));<br />
<br />
if (m_nFlags & (WF_MODALLOOP|WF_CONTINUEMODAL))<br />
EndModalLoop(ExitCode);<br />
<br />
::EndDialog(m_hWnd, ExitCode);<br />
}<br />
catch(...){<br />
return;<br />
}<br />
<br />
}<br />
<br />
DWORD CProgressDlg::GetThreadResult()<br />
{<br />
return m_dwThreadResult;<br />
}<br />
<br />
Now, all works well in my latest App, until I want to End the Dialog.
All goes well,
CProgressDlg::EndDialog(int ExitCode)
is called, SendMessage calls OnEndDialog(...), which terminates successfully, and then the App terminates with an Exception.
In case you ask, why not trace and debug, the App behaves as expected in Debug Mode, I get this behaviuor only in the Retail version.
I got this far by setting 'StillAlive' traps in the retail version, and do not know how to get further.
Regards,
Bram van Kampen
|
|
|
|
|
Debug the retail version. Build it with debug information and proceed as normal. Debug don't really care if it's a release or debug build.
Steve
|
|
|
|
|
Did that.
It bombs somewhere in the bowels of USER32.DLL (for which I have NO code) as soon as I link with the MFC Retail Libs. It does this in One App only. I rebuilt another 5 Apps using Identical Code and Calling sequence, and it works fine.
Regards,
Bram van Kampen
|
|
|
|
|
Using SendMessage api thrown from same thread to same thread is problem in itself because SendMessage api is blocking call, better use PostMessage.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I'm not sure what you mean exactly, but using SendMessage to send a message to the same thread as the sender is fine (in fact it's the most common case).
Steve
|
|
|
|
|
ThatsAlok Using SendMessage api thrown from same thread to same thread is problem in itself because SendMessage api is blocking call
No!
The Doccumentation states clearly that SendMessage calls the WinProc immediately when called from the same thread.
This is what Windows itself does the whole time in a Single Threaded App.
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: void CProgressDlg::_OnEndDialog(int ExitCode)
I doubt about this line. You will probably need to handle both the params from SendMessage. i.e. WPARAM, LPARAM.
Also
Bram van Kampen wrote: WM_ENDDIALOG=WM_USER+1,
Not recommended as these values are already used by windows for some other messages. But I don't think it will cause the problem you are facing.
Regards,
Sandip.
|
|
|
|
|
SandipG wrote: Bram van Kampen wrote:
void CProgressDlg::_OnEndDialog(int ExitCode)
I doubt about this line. You will probably need to handle both the params from SendMessage. i.e. WPARAM, LPARAM.
No, The use of the Params is optional. At Any rate, SendMessage lands safely at the handler. It trashes when SendMessage returns.
SandipG wrote: Bram van Kampen wrote:
WM_ENDDIALOG=WM_USER+1,
Not recommended as these values are already used by windows for some other messages. But I don't think it will cause the problem you are facing.
Well, what would you reccommend instead. It could not be the problem, because SendMessage lands at the correct Handler.
Thanks
Bram van Kampen
|
|
|
|