C / C++ / MFC

6-Jul-04 9:46

subject. Please!
Thanks a lot in advance.

Johan Rosengren6-Jul-04 10:44

6-Jul-04 10:44

Rigid programming discipline.

If that is not enough, Boundschecker.

CherezZaboro6-Jul-04 11:40

6-Jul-04 11:40

You had to go out and type in that first remark, right? What if it's not my code? Cool | :cool:

"Boundschecker" - now I remember. D'Oh! | :doh:

Johan Rosengren6-Jul-04 21:05

6-Jul-04 21:05

inner wrote:
You had to go out and type in that first remark, right? What if it's not my code?

Of course I had Smile | :)

There is an almost religious belief in leak finding tools, garbage collectors etc. With stricter discipline, leaks are much less of a problem.

And even if the code is not yours, a global search for all instances of new, replacement of dynamically allocated stuff with static variables etc. will increase code quality - something that a memory leak tool will not - you'll only fix leaks, not bad memory usage. An example:

void SomeFunction()
{
  CSomething* obj = new CSomething;
  // code
}

Boundschecker will find that you never deallocate obj. The chances are big that you replace the code with:

void SomeFunction()
{
  CSomething* obj = new CSomething;
  // code
  delete obj;
}

No leak. So far, so good. Now, the next maintaining developer copies part of the code to another function, so:

void SomeOtherFunction()
{
  CSomething* obj = new CSomething;
  // other code
}

New leak. If you instead corrected the code from the beginning to:

void SomeFunction()
{
  CSomething obj;
  // code
}

you'll have less lines of code to analyze for the next maintainer, easier to find the necessary but risky dynamic allocations, and no temptations for the copy and paste brigade = higher quality code!

CherezZaboro7-Jul-04 3:32

7-Jul-04 3:32

I understand all that! Thanks!
In 8 years of programming I never had to use boundschecker! Heck, that's why I even forgot the name of it and asked here. Used to hear about it from people but I always was able to find/fix issues with just what VC has to offer.
Now about the new and replacing it. You don't suggest to not use pointers at all, do you? Plus some of the problems that come up are not even related (seemingly - excuse my spelling Blush | :O

) to our in house code as you described with different maintainers. Our code uses libraries from other vendors. And right now I'm having a problem with this:

<br />
Detected memory leaks!<br />
Dumping objects -><br />
{67} client block at 0x015B4CE8, subtype 0, 64 bytes long.<br />
a CDynLinkLibrary object at $015B4CE8, 64 bytes long<br />
{63} client block at 0x015B4A08, subtype 0, 64 bytes long.<br />
a CDynLinkLibrary object at $015B4A08, 64 bytes long<br />
{56} client block at 0x015B2E18, subtype 0, 64 bytes long.<br />
a CDynLinkLibrary object at $015B2E18, 64 bytes long<br />
Object dump complete.<br />

Of course the issue is probably in my code but it comes up as a leak of a MFC class. Now I would just like to see where exactly those objects are created. How else can I see when the process loads like 50 DLLs? Only 4 of them are mine and the leak is not in them.

Johan Rosengren7-Jul-04 3:52

7-Jul-04 3:52

inner wrote:
Now about the new and replacing it. You don't suggest to not use pointers at all, do you?

No, of course not. But it should be used sparingly, and with care. An example where new is necessary is in containers, where lots of objects are stuffed in vectors or CObArrays. But in this case, by creating a container wrapper class, where the dtor deletes all memory, you'll avoid possible leaks. Another rule of thumb that I've used with great success is always writing the deallocation code at the same time as the allocation.

inner wrote:
Of course the issue is probably in my code but it comes up as a leak of a MFC class. Now I would just like to see where exactly those objects are created. How else can I see when the process loads like 50 DLLs?

This might very well be because a dtor is not called, so it's not certain that Boundschecker or other tools will point out the real error.

But I'm a great fan of Boundschecker. That tool has saved lots of development time around the word! It shouldn't be difficult to be allowed to buy it, if you are in a situation where you can't decide such stuff yourself - running your application(s) through it, it will most likely earn its cost the first day, when leaks and GDI-losses are detected Smile | :)

CherezZaboro7-Jul-04 4:21

7-Jul-04 4:21

The thing about CDynLinkLibrary is that it's created like this, right? :

<br />
new CDynLinkLibrary(TrymfcdefDLL);<br />

Without assigning it to anything. And MFC knows to kill it when DLL is about to be unloaded, right?
And each MFC extension DLL has this, right? Well. In my DLLd dtors deffinitely get called. Cause I've replaced CDynLinkLibrary with my own CDynLinkLibrary derived class and ctor and dtor TRACE to output. So there are some other DLLs that have a problem I assume.
Confused | :confused:

Do you know by any chance if latest is compatible with VC6? Cause I still have my projects there. I want to go VC 7 but, our management doesn't like to take such steps in a hurry.
Mad | :mad:

Johan Rosengren7-Jul-04 4:53