C / C++ / MFC

25-Jun-03 5:53

Hello you out there,

I am currently developing a tiny database program and therefore using a CMapStringToOb to store my user-defined objects in memory. During development, I suddenly faced a strange problem concerning memory usage and memory leaks. I thought that something was wrong with my class and therefore created a small class called CTest, which in fact is only a "box" or an int, I know it's silly, but, hey, it's at least maybe more easy to understand than a class with CStrings and so on...

<br />
class CTest : public CObject<br />
{<br />
private:<br />
int m_TestInt;<br />
<br />
public:<br />
CTest() { m_TestInt = 0; }<br />
CTest(int NewTestInt) { m_TestInt = NewTestInt; }<br />
~CTest() {}<br />
void SetInt(int NewTestInt) { m_TestInt = NewTestInt; }<br />
int GetInt() const { return m_TestInt; }<br />
};<br />

Then I'm using it with my CMapStringToOb:

<br />
CMapStringToOb *pTestObs = new CMapStringToOb; // Create CMapStringToOb on heap (at least I thing so?!)<br />
pTestObs->InitHashTable(50000,TRUE); // Init the hash table to work faster and allocate memory now<br />
<br />
char buffer[6];<br />
<br />
for(int i = i; i<= 49999; i++)<br />
{<br />
pTestObs->SetAt(_itoa(i,Buffer,10), new CTest(i));<br />
}<br />

Ok, up to here, everything works fine. I can retrieve my elements by calling "Lookup" and so on.
But now, please have a look at that piece of code in which I'm trying to delete my objects as well as the pointers and the "Map" as stated in the MSDN:

<br />
POSITION pos = pTestObs->GetStartPosition(); // Get starting position to iterate the map<br />
<br />
while(pos != NULL)<br />
{<br />
CString String;<br />
CTest* pTest = NULL;<br />
pTestObs->GetNextAssoc(pos, String, (CObject*&)pTest);<br />
pTestObs->RemoveKey(String);<br />
delete pTest;<br />
}<br />
<br />
// pTestObs->RemoveAll(); || this didn't help either!<br />
<br />
delete pTestObs;<br />

The problem with this piece of code now is that, in Debug mode, everything seems to work just fine, I added some ::AfxMessageBox(...); statements in order to know what goes right and what goes wrong.
These CObjects need roughly 7 MB of RAM on my machine. In Debug mode, the upper code frees 7 MB, as previously needed and allocated. But in Release mode, after creating these objects and inserting them into the CMapStringToOb, this part of the code only frees round 3 MB of the memory. But... where is the rest?! I am leaking 4 MB of memory and dealing with much larger objects in the REAL program, which might easily mean around 20 MBytes.

Can any one help me? Does anyone know what I am doing wrong?

Best regards and thanks in advance,
pf7

(@ All Americans: I live in Germany, so please do not think that I won't reply immediately. It's just because of the difference in time. I'll reply!)

pf725-Jun-03 8:45

25-Jun-03 8:45

No one to help me out there?

basementman25-Jun-03 11:27

basementman

25-Jun-03 11:27

Get rid of the RemoveKey statement. After deleting all the objects, you can call RemoveAll().

onwards and upwards...

pf725-Jun-03 11:58

25-Jun-03 11:58

Thanks, but, as you can see, I've already commented the "RemoveAll()" out with the statement "didn't help either!" The fact is that, as stated in my first question, it seems as if the objects are not deconstructed correctly. But only in Release mode, not in Debug mode. I've heared that the debug mode features some type of "garbage collection" but when executing my script I do not get compiler warnings or debugger messages saying that it is deleting / destructing any instances of my object.

It's strange, I know, but if any one of you tried it out the way I did, it would - hopefully - have the same result: a memory leak of which I don't know what the cause might be.

pf726-Jun-03 3:52

26-Jun-03 3:52

@basementman: Thanks for at least reading the whole thing Smile | :)

Seems as if no one except you has any tips or wants to help me finding the solution Frown | :(

John M. Drescher26-Jun-03 23:27

26-Jun-03 23:27

Are you still having this problem. I have used code like this a hundred times in the past. I avoid MFC template classes and I recommend STL now because after learning STL you will get template classes with much more flexibility, functionality and portability. However looking at your code I do not see any reason why there is a memory leak.

John

pf727-Jun-03 4:17

27-Jun-03 4:17

Well, at the moment I'm just a beginner that tries this MFC collection class. Sadly, I've got no experience in STL at the moment. Maybe I'll learn how to use it by the time...
And yes, I've still got the same problem. I really do not know what causes these problems. As I before all this used a much more complex class with some CString(s) and COleDateTime, I thought that I did something wrong when deleting the whole object (maybe something in the destructor), but I get this problem even in this simple CTest class. I also before this created the whole thing on the stack CMapStingToOb Test; and thought it was this that caused the problem but it remained when I created it on the heap CMapStringToOb *pMTO = new CMapStringToOb;... Do you know if it has something to do with new and the associated pointers to the object instances or the instances of my CMapStringToOb?
I'll also ask a friend of mine who's got a Win XP machine to test it (I've got 98SE), maybe it is just the system... For what reason ever.

John M. Drescher27-Jun-03 9:47

27-Jun-03 9:47

I did not forget about this problem however I am too busy to help at the moment I look at as soon as I can.

John

pf727-Jun-03 11:29

maximum characters in edit box

27-Jun-03 11:29

First of all I would like to thank you; first of all you should do what you have to do Smile | :)

It's just a private project (a program I want to be used by my school) and I've got time to wait as there is no need for the program to be finished within a certain time. I'm just programming so that I get more versed in the whole subject of computer, programming, databases and data processing.

I would be glad if you had a look on it once again, but you don't have to as there really is no
need for you to spend your free time on this, you surely have got something better to do Smile | :)

Thanks again first of all (and in advance Wink | ;)

skinnyreptile25-Jun-03 5:36

skinnyreptile

25-Jun-03 5:36

I know we can use Class Wizard to set maximum length of a CString in an edit box. Is there any way to change the maximum length of an edit box without using the Class Wizard?

Re: maximum characters in edit box

Rob Caldecott25-Jun-03 5:40

Rob Caldecott

25-Jun-03 5:40

CEdit::SetLimitText or something similar (or send an EM_SETLIMITTEXT message).

When I am king, you will be first against the wall.

Re: maximum characters in edit box

skinnyreptile25-Jun-03 5:48

skinnyreptile

25-Jun-03 5:48

Thanks Rob, it works perfectly!

RTTI/dynamic_cast

Rob Caldecott25-Jun-03 5:08

Rob Caldecott

25-Jun-03 5:08

RTTI - good or bad? I am using ATL/WTL and by default, new projects created using VS.NET have RTTI disabled. Before I rush off and use dynamic_cast are there any known gotchas with using RTTI? Will it make a difference to my program size, etc.?

I used to use "IsKindOf(RUNTIME_CLASS(...))" in my MFC days, though I'll admit that is makes some code look ugly and kinda feels like a kludge.

Thoughts?

When I am king, you will be first against the wall.

John M. Drescher25-Jun-03 5:13

25-Jun-03 5:13

I use it all the time now in my MFC code and stay away from the "IsKindOf(RUNTIME_CLASS(...))" stuff...

John

Nemanja Trifunovic25-Jun-03 5:29

Nemanja Trifunovic

25-Jun-03 5:29

It *could* slow down your application a little bit, but in most cases you won't notice any difference.

Rob Caldecott25-Jun-03 5:33

Rob Caldecott

25-Jun-03 5:33

Well I guess it has to store the RTTI info so my program size will increase too I guess.

I found some more info in Effective C++ too:

"...the space cost of RTTI is an additional entry in each class vtbl plus the cost of the storage for the type_info object for each class. Just as the memory for virtual tables is unlikely to be noticeable for most applications, however, you're unlikely to run into problems due to the size of type_info objects."

So I should probably give it a go - it can be very handy...

When I am king, you will be first against the wall.

peterchen25-Jun-03 5:33

peterchen

25-Jun-03 5:33

It adds some overhead to the application (both size and runtime). It's usually negligible, but the reason why it's off by default.

You get into trouble, however, if you try to link to a .LIB which is compiled without RTTI

"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS

sighist | Agile Programming | doxygen

Peter Weyzen25-Jun-03 5:49

Peter Weyzen

25-Jun-03 5:49

Are there additional mix&match rules about using RTTI? May I create a .DLL (class library) with RTTI and link to it from non-RTTI EXE's?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
Santa Cruz Networks

peterchen25-Jun-03 6:27

peterchen

25-Jun-03 6:27

Might be a problem when the DLL exports classes. After all, if you compile the DLL without RTTI, and later request RTTI from the DLL-implemented class, something strange will happen.

I guess the C++ name decoration is different for compiles with/without RTTI, so it won't find the correct exports in a RTTI setting mismatch.

"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS

sighist | Agile Programming | doxygen

John M. Drescher26-Jun-03 23:19

26-Jun-03 23:19

I don't think you will have any problems either way as long as you don't try to use RTTI on code that was not compiled with it. I write all my code with RTTI turned on and I know the libraries that my coworkers give me do not have RTTI turned on but it does not seem to cause any problems. However when I think of it they do give me a simple class interface with no inheritance or virtual functions so maybe the problems occur when the code uses these features. When this subject was brought up I was thinking of MFC. I do use RTTI with MFC all the time. Was MFC 4.1 compiled with this turned on??

John