C / C++ / MFC

Richard MacCutchan8-Jun-12 22:53

Richard MacCutchan

8-Jun-12 22:53

I am guessing that line 27/28 are:

C++

std::cout << "min == " << ceng.min() << std::endl;
std::cout << "max == " << ceng.max() << std::endl;

and that both functions require arguments.

speaking as ...

Falconapollo8-Jun-12 23:05

Falconapollo

8-Jun-12 23:05

Yes, you are right.

But the two functions need no parameters.
They are the member functions of

C++

mersenne_twister<unsigned int, 32, 624, 
    397, 31, 0x9908b0df, 11, 7, 0x9d2c5680, 
    15, 0xefc60000, 18>

I don't know why I get these erros.

Richard MacCutchan8-Jun-12 23:29

Richard MacCutchan

8-Jun-12 23:29

I just copied this sample from MSDN[^] and built it without problems in Visual C++ 2010 Express. Just to verify I copied the code from your original question and that also builds correctly. The only issue I can see is:

1>  _WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)1

which may mean that the Windows version is incorrect.

speaking as ...

Falconapollo8-Jun-12 23:35

Falconapollo

8-Jun-12 23:35

Thank you for you quick reply.

I found the reason by your hint:

I add so many headers into my source file.

C++

#include <iostream>
#include <vector>
#include <list>
#include <deque>
#include <algorithm>
#include <iterator>
#include <cmath>
#include <ctime>
#include <cstring>
#include <afx.h>
#include <set>
#include <hash_map>
#include <hash_set>
#include <locale>
#include <sstream>
#include <codecvt>
#include <cstring>
#include <string>
#include <clocale>
#include <random>
#include <Winsock2.h>
#include "dba.h"
using namespace std;

When I comment out the unnecessary headers from my source file. I compile successly, too!!

Thank you very much!!!

If CDialog is destroyed is UI CWinThread created While object was alive get destroyed as Well

Stephen Hewitt10-Jun-12 1:17

Stephen Hewitt

10-Jun-12 1:17

The error I'll focus on is:

1>z:\e\disk\vc\justtest\console\console.cpp(27): warning C4003: not enough actual parameters for macro 'min'

The line in question is:

std::cout << "min == " << ceng.min() << std::endl;

Notice the error is complaining about a macro called 'min' and keep in mind the fact that macro processing happens before compilation and doesn't respect normal language conventions such as scope, member functions, namespaces, etc.

The min at line 27 was being treated as a macro and object 'ceng' doesn't enter into the issue.

You obviously nuked the include that was defining the macro.
Putting something like this after all the includes would also fix the problem:

#ifdef min
#undef min
#endif

#ifdef max
#undef max
#endif

Steve

ForNow8-Jun-12 2:31

Re: If CDialog is destroyed is UI CWinThread created While object was alive get destroyed as Well

8-Jun-12 2:31

If CDialog is destroyed is UI CWinThread created While object was alive get destroyed as Well

If answer is yes then I understand my problem

«_Superman_»8-Jun-12 2:46

«_Superman_»

8-Jun-12 2:46

If the CDialog you're talking about is the main dialog, then when the dialog exits, the application exits and then all the threads be it worker threads or UI threads are all destroyed.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Polymorphism in C

Re: If CDialog is destroyed is UI CWinThread created While object was alive get destroyed as Well

ForNow8-Jun-12 10:52

Re: If CDialog is destroyed is UI CWinThread created While object was alive get destroyed as Well

8-Jun-12 10:52

Being a Mainframe assembler programmer I experinced the same thing on MVS Z/OS opertaing system

I did a ATTACH to start a thread subtask loaded programs obtained storage and as soon as the task thread goes away MVS reclaims all resources obtained by the TASK/THREAD

My question is if I do ::ShowWindow what does SW_HIDE do; are the resources used with the Cwnd:: derived object still in memory

thanks

«_Superman_»8-Jun-12 16:11

«_Superman_»

8-Jun-12 16:11

Hide does not destroy the window and so all resources are still loaded in memory.
In fact, the FindWindow API will still find this hidden window.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Polymorphism in C

Re: If CDialog is destroyed is UI CWinThread created While object was alive get destroyed as Well

Albert Holguin8-Jun-12 4:33

Albert Holguin

8-Jun-12 4:33

Generally... no... remember that the concepts are not really tied together. For example, you can have a CWinThread with no CDialog, and you can have multiple CDialogs in one CWinThread.

Corruption of the heap. Why ?

sdancer757-Jun-12 23:49

7-Jun-12 23:49

Hi,

I have a CFormView derived class named CCatalogView. The Dialog Form was designed using the VS2008 resource editor.

I also created a new method inside the CCatalogView like the follow :

C++

CWnd* CCatalogView::CreatePane(CWnd* pParentWnd)
{
  if (GetSafeHwnd() == 0){
      VERIFY(Create(_T("CatalogView"), NULL, WS_CHILD | WS_VISIBLE | WS_CLIPCHILDREN | WS_CLIPSIBLINGS, CXTPEmptyRect(), pParentWnd, NULL, 0));
				 
  }
  return this;
}

While I can show the content of this FormView inside a pane, when I exit from the application I get a memory error :
===================================
Windows has triggered a breakpoint in Test.exe.

This may be due to a corruption of the heap, which indicates a bug in Test.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while Test.exe has focus.

The output window may have more diagnostic information.
====================================

I have already found a solution, and that was to use the

create

method, outside of the class CCatalogView as with the following code :

C++

m_pFormFrame = new CFrameWnd;
CCreateContext context;
context.m_pNewViewClass = RUNTIME_CLASS(CCatalogView);
context.m_pCurrentDoc = NULL;

m_pFormFrame->Create(NULL, NULL, WS_CHILD|WS_VISIBLE|WS_CLIPCHILDREN|WS_CLIPSIBLINGS, CRect(0, 0, 0, 0), this, NULL, 0, &context);
 m_pFormFrame->SendMessageToDescendants(WM_INITIALUPDATE, 0, 0, TRUE, TRUE);
 pPane->Attach(m_pFormFrame);

Now the question is : Why the 1st part of the code corrupts the heap ? I suspect the the "Create" is constructed to the heap instead of the stack that I assume.

If that is true, can I modify the code to make it work ?

Best Regards,

sdancer75

Rolf Kristensen8-Jun-12 2:01

Rolf Kristensen

8-Jun-12 2:01

I can recommend using Application Verifier[^] and then run your application within a debugger. Then it should break the application at the initial corruption of the heap.

Application Verifier is part of the Windows SDK[^]

Erudite_Eric8-Jun-12 2:35

Erudite_Eric

8-Jun-12 2:35

Yep, verifier, it is a good tool.

==============================

Nothing to say.

sdancer758-Jun-12 6:02

8-Jun-12 6:02

Thanks,

I didn't used Application Verifier before.

Does it run under the VS2008 IDE ?

Regards,

sdancer75

Aescleal8-Jun-12 3:00

Aescleal

8-Jun-12 3:00

You're calling two completely different functions! In the first example you're calling CCatalogView::Create, in the second you're calling CFrameWnd::Create.

As to why it's failing.. I can't tell exactly but one idea is that you're creating the CCatalogView as an automatic object. When you call CreatePane a WIN32 window object is created. When the pane window (as in the WIN32 window) is destroyed it tells the CCatalogView to do a delete this;. As the C++ object is on the stack delete goes a bit haywire.

In the second case everything's allocated on the heap. You CCatalogView is implicitly created on the heap by CFrameWnd::Create. When the WIN32 window objects are destroyed the delete this; works the way it should do and everything's cool.

Just out of interest all this delete this; rubbish generally happens in whatever override of CWnd::PostNCDestroy gets called. As a general rule always create MFC C++ window objects on the heap, unless it's a modal dialogue when it's safe to create it on the stack.

sdancer758-Jun-12 6:03

8-Jun-12 6:03

Thank you for your reply.

I am not sure if this is the real problem.... I will search more about this.

Regards,

sdancer75

sdancer759-Jun-12 3:43

9-Jun-12 3:43

As you can see "Call Stack" stops at _CrtIsValidHeapPointer. It seems that is trying to free the CCatalogView Object but it fails. Maybe that means that somehow the CCatalogView class has alreaded deleted from the memory. What is your opinion ?

ntdll.dll!77470724()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7743295a()
ntdll.dll!77401997()
KernelBase.dll!760d4bf9()
> Gnosis.exe!_CrtIsValidHeapPointer(const void * pUserData=0x03387e2c) Line 2103 C++
Gnosis.exe!_free_dbg_nolock(void * pUserData=0x03387e2c, int nBlockUse=12582916) Line 1317 + 0x9 bytes C++
Gnosis.exe!_free_dbg(void * pUserData=0x03387e2c, int nBlockUse=12582916) Line 1258 + 0xd bytes C++
Gnosis.exe!CObject::operator delete(void * p=0x03387e2c) Line 42 + 0xe bytes C++
Gnosis.exe!CCatalogView::`scalar deleting destructor'() + 0x3c bytes C++
Gnosis.exe!CView::PostNcDestroy() Line 121 + 0x21 bytes C++
Gnosis.exe!CWnd::OnNcDestroy() Line 864 C++
Gnosis.exe!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0018e038) Line 2042 C++
Gnosis.exe!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0) Line 1755 + 0x20 bytes C++
Gnosis.exe!AfxCallWndProc(CWnd * pWnd=0x03387e2c, HWND__ * hWnd=0x001906d6, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 240 + 0x1c bytes C++
Gnosis.exe!AfxWndProc(HWND__ * hWnd=0x001906d6, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 403 C++
user32.dll!76126238()
user32.dll!76127298()
user32.dll!76126899()
user32.dll!76127177()
user32.dll!76131e3a()
ntdll.dll!773b00e6()
user32.dll!76131e83()
Gnosis.exe!CWnd::DestroyWindow() Line 1007 + 0xd bytes C++
b60f0004()

sdancer75

Aescleal9-Jun-12 9:51

Aescleal

9-Jun-12 9:51

Either you've stuck the CCatalogView on the stack and PostNcDestroy is trying to delete it when the WIN32 window is being deleted OR you're stashing a pointer to the CCatalogView some where and deleting it. It may be hidden if you've stored it as a pointer to one of it's parent classes.

sdancer759-Jun-12 23:58

9-Jun-12 23:58

Thank you Aescleal,

Yes the CCatalogView is created on the stack and I did know that from the beggining, but I was wondering about the time are happenning all these things.

1. I create on the stack the  CCatalogView

2. Inside the CCatalogView class I create a Win32 Window (using Create). Really, does this window is created on the heap or in the stack ? I assume that is created on the stack. Anyway, I tried to explicitly create this window on the heap, using new (on the CreatePane) & delete (on the destructor) functions  but it also fails.

3. Now, according to my assumptions that both objects are in the stack, at the exiting procedure, it disposes first the last inserted item which is the Win32 Window (as I mentioned, I assume it created on the stack) and then the CCatalogView class itleft.

What's of the above assumptions are wrong ? That is what I did not understand.

Regards,
George

PS: Reading your comment again, you assume that the MFC Framework when is trying to delete the Window itself, is deleting also the class that is associated with that window. Maybe, is something that I did not understand well. Can you please clarify that ?

sdancer75

sdancer7512-Jun-12 3:18

Exception when debugging Multithread

12-Jun-12 3:18

Ok, I found the cause of the problem.

The default for views is to allocate them on the heap and the default post-cleanup is to 'delete this'.

So, in my situation I created the window in the stack, like it shows below.

C++

VERIFY(Create(_T("MyWind"), NULL, WS_CHILD | WS_VISIBLE, CXTPEmptyRect(), pParentWnd,  IDD_TABSHEET2, &context));

The default behavior of the CView cleanup is to delete this. Indeed, if you check inside the viewcore.cpp you will see, something like this :

C++

// self destruction
void CView::PostNcDestroy()
{
	// default for views is to allocate them on the heap
	//  the default post-cleanup is to 'delete this'.
	//  never explicitly call 'delete' on a view
	delete this;
}

That thing is all screwed up in my case. The solution ? Just override the CCatalogView::PostNcDestroy and comment the CFormView::PostNcDestroy(); to prevent calling the CView::PostNcDestroy.

C++

void CCatalogView::PostNcDestroy()
{
	// TODO: Add your specialized code here and/or call the base class
	_ASSERTE( _CrtCheckMemory( ) );

	//Don't call default PostNCDestroy which it calls CView:: delete this
	//because you get a heap corruption since the view is created on the stack.
	//CFormView::PostNcDestroy();


}

Hope, it helps someone.

Regards,

sdancer75

ForNow7-Jun-12 19:04

Re: Exception when debugging Multithread

7-Jun-12 19:04

Hi,

I am getting an exception when debugging a application after invoking CWinThread

The following is my invocation of AfxBeginThread

<pre lang='cpp'>
AfxBeginThread(RUNTIME_CLASS(SockCLeintThread),
THREAD_PRIORITY_NORMAL,
0,CREATE_SUSPENDED);

</pre>

The way I read the documentation if the first parm is CRuntimeClass* pThreadClass
the way I have it coded then its a UI thread

However while debugging the application and looking at the Thread DEBUG->
WINDOWS->THREADS The Visual Studio debugger marks the thread as a worker thread

I create the thread in a modal Dialog after at the end of one of the methods of modal dialog box I destory the modal dialog box via EndDialog don't know if this a issue

Also can sone one tell me What the /MD and /MT linker options are

Thanks

«_Superman_»7-Jun-12 19:15

«_Superman_»

7-Jun-12 19:15

It is probably because the thread is in a suspended state and has not started running.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Polymorphism in C

Re: Exception when debugging Multithread

ForNow7-Jun-12 23:53

Re: Exception when debugging Multithread

7-Jun-12 23:53

I resume the thread

myprog->progsocket->ResumeThread(); // get it going

However one I comment out anything the destroys e.g. EndDialog the Modal Dialog box whose method

I was while creating the CWinThread the exception disappears

I am wondering since I create a UI thread it associates the CWinThread with the modal

Dialog Box and when the modal Dialog Box disappears it destroys anything associated

with it e.g. the CWinThread object and anything releated to that object

code in question don't know whay my pre tags aren't taking

<pre lang='cpp'>

CprogDebug *myprog; // instantiate a Debug Class modless CDialog derived class

myprog = new CprogDebug; // Allocate on the Heap

if (myprog == NULL)
MessageBox("CprogDebug","CprogDebug Error",MB_ICONERROR);

myprog->jobname = jobname; // copy over jobname
myprog->progname = progname; // copy over progname
myprog->proglisting = dlg.GetPathName();
EndDialog(0); // Kill the Dialog
// dlg.~dlg();

myprog->Create(IDD_PROGDBG,NULL); // Attach it to a window

myprog->progsocket = (SockCLeintThread *) AfxBeginThread(RUNTIME_CLASS)
(SockCLeintThread),
THREAD_PRIORITY_NORMAL,
0,CREATE_SUSPENDED);

if (myprog->progsocket == NULL)
MessageBox("Socket","Prog Socket Error",MB_ICONERROR);

myprog->progsocket->sendwindow = (CWnd *) myprog;
// set window to receive TCP/IP messages
myprog->progsocket->m_pActiveWnd = (CWnd *) myprog; // <== point to newwindow
myprog->progsocket->m_pMainWnd = (CWnd *) myprog; // ditto
myprog->progsocket->ipaddr = "192.168.1.4"; // ip address
CHERC_CMDApp *main_app = (CHERC_CMDApp *)AfxGetApp();
int i = 0;
while(main_app->ports[i].busy != 0)
{
i++;
}
myprog->progsocket->port = main_app->ports[i].port; // port
main_app->ports[i].busy = 1;
// Tcpipthread = progsocket->m_nThreadID; // thread id
// myprog.progsocket->thisocket.send_wnd = myprog.progsocket->sendwindow;
myprog->progsocket->thisocket->send_wnd = (CWnd *) myprog;
strcpy((char *)&myprog->progsocket->thread_id,"DebugSocket");
myprog->progsocket->thisocket->thread_no = i; //
myprog->Tcpipthread = myprog->progsocket->m_nThreadID;
myprog->progsocket->ResumeThread();

</pre>

Event though I explictily point to another modless dialog I create on the heap

while in the modless Dialog Box method

ForNow7-Jun-12 23:58