C / C++ / MFC

2-Dec-06 4:42

Hi!
I have a question concerning the use of delete keyword in C++ programs.
First, I do something like this:

int *pInt = new int [16];
delete pInt;

All the documentation I have read about delete sais that you must use delete [] when the allocated memory is an array. But if I run the small program containing these two lines of code in Debug mode, the _CrtDumpMemoryLeaks function tells me that the is no memory leak. In conclusion, why is there any need to deallocate the memory pointed by pInt using delete [] pInt; if it works using only delete pInt?

If anyone can answer my question, I would greatly appreciate it!
Thanks in advance!

Re: delete vs. delete []

George L. Jackson2-Dec-06 5:25

George L. Jackson

2-Dec-06 5:25

Please read:

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.13[^]

Re: delete vs. delete []

Eikthrynir2-Dec-06 6:24

Re: Access vector from C#

2-Dec-06 6:24

Thank you! It helps a lot!

Re: delete vs. delete []

ThatsAlok3-Dec-06 20:09

ThatsAlok

3-Dec-06 20:09

Eikthrynir wrote:
lete [] pInt

actually [] instruct compiler to delete the array of Memory block here.. if you use simple delete then only one memory block will be freed

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and you

Message Removed

2-Dec-06 3:15

Reza Shademani

2-Dec-06 3:15

Message Removed

Christian Graus2-Dec-06 10:11

Christian Graus

2-Dec-06 10:11

A vector is an array internally ( that is, it's continuous memory ). Therefore, if you set up an equivelant class in C# ( assuming it's not just a simple type ), you should be able to pass it through.

Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog

Re: Access vector from C#

Joe Woodbury2-Dec-06 10:13

Joe Woodbury

2-Dec-06 10:13

Reza Shadmani wrote:
How could i pass STL vector params between C# and C++?

No. (Assuming you want to retain the full integrity of the vector, vs. just the data.)

For examples on how to pass arrays of data, look at P/Invoke.

Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke

CEedit MFC question

FredrickNorge2-Dec-06 1:55

FredrickNorge

2-Dec-06 1:55

I want to display a text file , using the CEdit controller.

Though i dont want the user the be able to edit the text, only mark the text if he wants to copy something.

If i set the readonly parameter, it is exactly the way i want it, except its color background is greyed, i want the white.

This is the code i have now:

CEdit * p = static_cast<cedit *="">(GetDlgItem(IDC_Readme));
p->SetWindowText("Text");
p->SetMargins(2,2);

Eikthrynir2-Dec-06 2:45

2-Dec-06 2:45

You don't need to make the edit-box to be read-only. You only have to manage the WM_KEYDOWN message, like this:

BOOL CTestDlg::PreTranslateMessage( MSG *pMsg )
{
  if ( pMsg -> message == WM_KEYDOWN )
  {
    CEdit *p = (CEdit *) GetDlgItem( IDC_Readme );
    if ( GetFocus( ) == p )
      return TRUE;
  }

  return CDialog::PreTranslateMessage( pMsg );
}

I don't know what is the name of your application's main dialog class. In my example it's CTestDlg. Don't forget to declare this overriden function in that class.
Good luck!

FredrickNorge2-Dec-06 3:35

FredrickNorge

2-Dec-06 3:35

thanks, worked great!

PJ Arends2-Dec-06 22:43

PJ Arends

2-Dec-06 22:43

Handle the WM_CTLCOLORSTATIC message.

You may be right
I may be crazy
-- Billy Joel --

Within you lies the power for good, use it!!!

ThatsAlok3-Dec-06 20:13

ThatsAlok

3-Dec-06 20:13

FredrickNorge wrote:
If i set the readonly parameter, it is exactly the way i want it, except its color background is greyed, i want the white.

Hanle OnCtlColr message and repaint the ctrl with white color

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and you

Memory leaks

Eikthrynir2-Dec-06 1:45

2-Dec-06 1:45

Hi!
I have created a very simple project called Test in Microsoft Visual Studio 2005 of type Win32 Console Application, using MFC,which looks like this:

#include "stdafx.h"
#include "Test.h"
#define _CRTDBG_MAP_ALLOC
#include "stdlib.h"
#include "crtdbg.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
CWinApp theApp;
using namespace std;
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
  int nRetCode = 0;
  if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
  {
    _tprintf(_T("Fatal Error: MFC initialization failed\n"));
    nRetCode = 1;
  }
  else
    _CrtDumpMemoryLeaks( );
  return nRetCode;
}

After compiling and executing it in Debug mode, in the Output window of the IDE appeared this information:

'Test.exe': Loaded 'E:\Test\debug\Test.exe', Symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_c8452471\mfc80ud.dll', Symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c\msvcr80d.dll', Symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded.
'Test.exe': Loaded 'C:\WINDOWS\system32\sockspy.dll', Binary was not built with debug information.
'Test.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFCLOC_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_3415f6d0\mfc80ENU.dll', Binary was not built with debug information.
Detected memory leaks!
Dumping objects ->
{61} client block at 0x003A3298, subtype c0, 64 bytes long.
a CDynLinkLibrary object at $003A3298, 64 bytes long
Object dump complete.
The program '[2164] Test.exe: Native' has exited with code 0 (0x0).

As you can see, I haven't allocated any memory on the heap. The only pieces of code added by me were #define _CRTDBG_MAP_ALLOC, the include lines for stdlib.h, crtdbg.h and the call of _CrtDumpMemoryLeaks, in order to be able to see if there are any memory leaks.
In MSDN, they say that a client block is a special type of memory block used by MFC programs for objects that require a destructor.
In my opinion, no matter how hard someone tries to create an application which correctly allocates and deallocates the heap memory, that application would still have a memory leak of 64 bytes. Is this a bug in Microsoft Visual Studio 2005? Because I really don't think I'm the one responsible for deallocating those 64 bytes of memory. (Moreover, when I create an empty project (with no MFC), no memory leak is detected. I guess the call of AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0) is responsible for this trouble)
Any help will be greatly appreciated!
Thanks in advance!

Mark Salsbery2-Dec-06 5:58

Mark Salsbery

2-Dec-06 5:58

For an MFC app, you don't need a _tmain() entry point. Use the CWinApp::InitInstance() and
CWinApp::ExitInstance() overrides for initialization and cleanup.

If you absolutely MUST have your own entry point then you'll need to look at the source code for
MFC's entry-point implementation and make sure you are covering all initialization and cleanup.

If the only reason you need to override the entry point is to check for memory leaks then
you can use a static object like your CWinApp object. I use this in my app module:

#ifdef _DEBUG
class _MemStateCheck
{
public:
	CMemoryState oldMemState, newMemState, diffMemState;
 
	_MemStateCheck();
	~_MemStateCheck();
};

_MemStateCheck::_MemStateCheck()
{
	oldMemState.Checkpoint();
}

_MemStateCheck::~_MemStateCheck()
{
	newMemState.Checkpoint();
	if( diffMemState.Difference( oldMemState, newMemState ) )
	{
		TRACE( "************************\n" );
		TRACE( "Memory leaks Detected\n" );
		TRACE( "************************\n" );
		diffMemState.DumpStatistics();
		diffMemState.DumpAllObjectsSince();
	}
	else
	{
		TRACE( "************************\n" );
		TRACE( "No memory leaks Detected\n" );
		TRACE( "************************\n" );
	}
}

_MemStateCheck MemCheckObj;
#endif  //#ifdef _DEBUG

Eikthrynir2-Dec-06 7:58

2-Dec-06 7:58

Thank you for your time!

Joe Woodbury2-Dec-06 10:32

Joe Woodbury

2-Dec-06 10:32

There is no problem creating an app like this. The memory leak is a side effect of the MFC dlls unloading and is on shutdown only (and is likely due to the restrictions on unloading DLLs, rather than MFC itself.) If you link statically, the leak will go away.

Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke

Eikthrynir2-Dec-06 11:08