C / C++ / MFC

31-Jul-06 9:49

Hi!

We have a class CDriver which inherits from IDriver. CDriver is defined in a library, CDriver.lib. CDriver.lib is added to the library definition of the project settings, and we have CDriver.h included in the file list for the project.

If we create a new class, CMyDriver, which inherits from CDriver, and add member variables to it, when we run the app, things crash when the destructor is called. If we remove the member variables things work properly. We can add as many member functions as we want, but cannot add member variables.

We dont understand that's happening. Any ideas? This is basic inheritance!! This is weird that I cannot add member variables.

Help!?!?!?
-C

C^hris L^osinger31-Jul-06 9:57

C^hris L^osinger

31-Jul-06 9:57

sounds less like an inability to add member variables, and more a case where something is happening in the destructor of the CMyDriver class that crashes the app.

can you step into the destructor in the debugger ?

Why donchoo take a peekchur mayn?
OK, cleeeeek

Wheatbread31-Jul-06 10:34

31-Jul-06 10:34

I cannot step through it in the debugger as it simply crashes. Frown | :-(

Hans Dietrich31-Jul-06 10:02

Hans Dietrich

31-Jul-06 10:02

When you say, "CDriver is defined in a library", I assume you mean a DLL. If that is the case, then search for any old copies of the DLL that may be getting loaded. For example, did you previously copy it to the Windows directory? If you find old copies, rename them and make sure the current DLL is in the app's exe directory, and try again.

This may not be the cause of the crash, but it is a good starting point.

Best wishes,
Hans

Wheatbread31-Jul-06 10:35

31-Jul-06 10:35

CDriver is defined in a library (.lib) file that statically linked at compilation. I'm pretty sure its loading the correct lib file, but I'll double check.

Zac Howland31-Jul-06 10:13

31-Jul-06 10:13

Is the destructor in CDriver declared as virtual?

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Wheatbread31-Jul-06 10:37

Re: Adding member variables crashes app [modified]

31-Jul-06 10:37

No, the destructor is not virtual. Should this be? If so, I guess I've forgotten basic C++ inheritance rules in which my question makes me look silly!! Smile | :)

Zac Howland31-Jul-06 10:47

31-Jul-06 10:47

Yes. The destructor MUST be declared virtual if you plan to derive from it. Here is why:

class Base
{
public:
	Base() {}
	~Base() {}
private:
	// whatever you want here
};

class Derived : public Base
{
public:
	Derived() {}
	~Derived() {}
private:
	int m_MyInt;
};

void main()
{
	Base* pB = new Derived;
	delete pB;	// memory leak
}

What happens is that the ~Base() destructor is called, but not the ~Derived(). Thus, m_MyInt stays allocated in memory (that is, the portion of memory allocated for a Base object is freed, but not that for Derived). This is called memory slicing (see "Effective C++" by Scott Meyers for more details).

The rule of thumb: If your class is meant to have classes derived from it, it MUST have a virtual destructor.

This problem can (and will) blow up your memory eventually (either stack or heap or both).

-- modified at 16:48 Monday 31st July, 2006

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Wheatbread31-Jul-06 11:06

31-Jul-06 11:06

Thanks. This was a good catch. Unfortunately, I still get an 'access violation' at destructor. I set a breakpoint in my derived class CMyDriver, and it doesnt step into the CDriver nor IDriver.

I'm just confused. If I remove the member variables from the class definition, things work fine. Frown | :-(

Zac Howland31-Jul-06 11:14

31-Jul-06 11:14

Any way you can actually show the code (slimmed down) you are using? The definitions of all 3 classes and the implementations for the destructors would be helpful in evaluating your problem.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Wheatbread1-Aug-06 12:28

1-Aug-06 12:28

CIDriver, CDriver and CMyDriver all have virtual destructors.

__declspec(dllexport) CIDriver* InitDriver(CIKernel* i_hKernel)
{
//__asm { int 0x03 }

CMyDriver* hUserDriver = new CUserDriver;
hUserDriver->Create(i_hKernel);
return (CIDriver *)hUserDriver;
}
__declspec(dllexport) void EndDriver(CIDriver* i_hIDriver)
{
CMyDriver * hUserDriver = (CMyDriver *)i_hIDriver;
hUserDriver->Destroy();
delete hUserDriver;
}

My app crashes at the 'delete hUserDriver'. EndDriver is an exposed interface call that another DLL calls to detroy the driver. hUserDriver->Destroy() destroy all internal structures of CDriver (not CMyDriver, as this function isnt overloaded in CMyDriver). CMyDriver is not referencing any objects destroyed by the Destroy call. Nothing is available in the debugger as its all assembly at that point.

In the class definition for CMyDriver, if I add public member variables, it crashes on the delete. If I make them global (file scope), it doesnt crash.

I"m wondering if its looking at the class size or something. I'm just confused.
-C

Zac Howland1-Aug-06 17:07

1-Aug-06 17:07

Wheatbread wrote:
CMyDriver * hUserDriver = (CMyDriver *)i_hIDriver;
hUserDriver->Destroy();
delete hUserDriver;
}

My app crashes at the 'delete hUserDriver'. EndDriver is an exposed interface call that another DLL calls to detroy the driver. hUserDriver->Destroy() destroy all internal structures of CDriver (not CMyDriver, as this function isnt overloaded in CMyDriver). CMyDriver is not referencing any objects destroyed by the Destroy call. Nothing is available in the debugger as its all assembly at that point.

Does Destroy get called from any of those destructors (or is anything that is cleaned up in Destroy also cleaned up in any of the destructors)?

Wheatbread wrote:
CMyDriver * hUserDriver = (CMyDriver *)i_hIDriver;

Just FYI, this is a dangerous cast. You should use dynamic_cast or reinterpret_cast to do this (and check the return value). This shouldn't be the cause of your problem, though.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

subitem in CListCtrl

Tara1431-Jul-06 9:46

Tara14

31-Jul-06 9:46

Hi,

I am having a trouble with my CListCtrl
I need to get the subitem number.

void CDlg::OnItemchangedList(NMHDR* pNMHDR, LRESULT* pResult)
{
NM_LISTVIEW *pNMListView = (NM_LISTVIEW*)pNMHDR;
int nItem = pNMListView->iItem;
int nSubItem = pNMListView->iSubItem;
*pResult = 0;
}

The above is returning the nItem number properly. But it is always giving zero for nSubItem.

Why is this happening?

Thanks.
Tara

Fortitudine Vincimus!

Hans Dietrich31-Jul-06 10:07

Hans Dietrich

31-Jul-06 10:07

How many subitems does it have? Can you post the code that you use to add the subitems?

Best wishes,
Hans

Tara1431-Jul-06 18:37

Tara14

31-Jul-06 18:37

I use SetItemText to add items to the list.

The items are read from mdb database. The number varies from two to about 50.

Fortitudine Vincimus!

David Crow31-Jul-06 10:20

David Crow

31-Jul-06 10:20

Just respond to the NM_CLICK notification message.

"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank

"Judge not by the eye but by the heart." - Native American Proverb

Tara1431-Jul-06 18:53

Tara14

31-Jul-06 18:53

I am using CEditList class got from codeproject. I have added a lot of other features to it. There is already an NM_CLICK message handled there. If I try to add one more message in the dialog box class, it does not work. But as such, when I put a message box in the onClick function in CEditList, it correctly gave the column number.

Fortitudine Vincimus!