C / C++ / MFC

Christian Graus8-Aug-01 12:31

8-Aug-01 12:31

You could make it static or make it a member variable and set it up in your initialisation.

I just reread your post - I'd make it a member variable and then delete/recreate when the user changes what it is.

Christian

Secrets of a happy marriage #27:

Never go to bed if you are mad at each other. It's more fun to stay up and fight.

Craig Miller9-Aug-01 7:02

Craig Miller

9-Aug-01 7:02

Thanks for the info Christian. Just so I'm clear on what you mean.

1. Create member variable in my .h file
CDC dc;

2. In my loadFile function (when the user selects a new imgage.)
if(dc != NULL)
delete dc;
dc.CreateCompatibleDC(NULL);
CSize sizeOfBmp = m_dibMask.GetSize();
CBitmap *pOldBmp = m_dibMask.MakeBitmap(&m_dibMask, &dc, sizeOfBmp);

//Fix Dundas bug
delete dc.SelectObject(pOldBm);

3. In my destructor
if(dc != NULL)
delete dc;

I'm kind of questioning the deletion of the dc, how do I do that correctly without creating memory leaks?

Thanks again for all your help,

Craig

Christian Graus9-Aug-01 11:31

9-Aug-01 11:31

No, this is dodgy - it won't compile. You are treating the variable DC as a pointer when you check for NULL and call delete, but it isn't one.

You can get the same effect without using a pointer by using dc.DeleteDC(); which will get rid of anything that was there before, but not crash if it was empty.

Christian

Secrets of a happy marriage #27:

Never go to bed if you are mad at each other. It's more fun to stay up and fight.

Craig Miller9-Aug-01 12:12

Craig Miller

9-Aug-01 12:12

Yes, that works correctly and doesn't even crash Wink | ;-)

. The only thing I question about this whole situation is, the call to

CBitmap *pOldBm = m_dibMask.MakeBitmap(...)

is basically making a call to SelectObject which returns the old object. According to the documentation you should always call SelectObject using the originally selected object, in this case pOldBm. Will I run into any memory leaks by not selecting the old pOldBm back into SelectObject()?

Thanks again for all your help, it's actually working Smile | :)

,

Craig

Christian Graus9-Aug-01 12:28

9-Aug-01 12:28

There's no point catching it if you don't put it back in ;0)

Usually this is a major disaster, but if you create the DC afresh before selecting the bitmap, the one coming out is 1x1x1, in other words, it's not really important. You could store the bitmap *, and check it for NULL before deleting the DC to know if you need to select it back in, but I doubt it's necessary...

Christian

Secrets of a happy marriage #27:

Never go to bed if you are mad at each other. It's more fun to stay up and fight.

Craig Miller9-Aug-01 12:54

Craig Miller

9-Aug-01 12:54

I see now, so I will have to worry about this when for instance I open up another image using the same dc right?

Currently, I have the following code in my LoadImage(...) method

if(m_dc != NULL)
     dc.deleteDC();

m_dc.CreateCompatibleDC(NULL);
CBitmap *pOldBm = m_dibMask.MakeBitmap(...);

So, for the dc.deleteDC() do I need to worry about saving the old bitmap? Or, does deleting the dc pretty much mean I'm starting with a clean one again without worrying about selecting the old bitmap back in?

Thanks again for all of your great help to get me to understand how all this dc stuff works,

Craig

Christian Graus9-Aug-01 13:05

9-Aug-01 13:05

Yes, you've got it. Don't bother catching it, unless you want to use a member variable, and select it back before calling DeleteDC(); It's probably better that you do, but I doubt you'll notice any difference if you don't.

Glad to help Wink | ;)

Christian

Secrets of a happy marriage #27:

Never go to bed if you are mad at each other. It's more fun to stay up and fight.

STL weirdness

#realJSOP8-Aug-01 7:42

#realJSOP

8-Aug-01 7:42

I wrote an STL version of my CQStringParser class, and in order for it to compile cleanly at warning level 4, I had to do the following:

// Set the wanring level to 3 because if you don't, you'll get 
// over 40 warnings about crap in the standard libraries
#pragma warning (push, 3)
// Now, you have to disable warning 4786 because when the STL macros 
// are expanded, the identifiers are greater than 255 characters in 
// the debug info.  
#pragma warning (disable : 4786)

#include <list>
#include <string>

// reset all warnings to their prior state
#pragma warning (pop)

Why do I have to pragma around those includes? Is this just an example of Microsoft's inability to develope standard code?

Next question - When I run the app, Boundschecker reports memory and resource leaks in the very same files that generate the warnings. Why?

I guess I just don't get it - what does the STL bring to the table that MFC doesn't do as well or better?

C^hris L^osinger8-Aug-01 8:25

C^hris L^osinger

8-Aug-01 8:25

about the warnings... they're just warnings. no big deal. i have the same pragmas everywhere and sometimes it takes 2 or more of them per file to get rid of all the warnings.

but what does STL bring ?

// randomly shuffle the elements in an array
std::random_shuffle(fileArray.begin(), fileArray.end());

// reverse the order of an array
std::reverse(fileArray.begin(), fileArray.end());

// sort an array 
std::sort(fileArray.begin(), fileArray.end());

yes, you can do those with CArray, if you write extra code, or with qsort (if you write extra code). but with STL, it's already there.

stack, queue (deque), set, etc. are all already implemented, no need to fake them with CArray or CList.

portability.

it's not MFC! there are many situations where MFC is not an option. STL is almost always an option.

-c

------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com

Todd Smith8-Aug-01 10:47

Todd Smith

8-Aug-01 10:47

I only get those warnings with STL stuff so I just have a generic "Warnings.h" file that I include when I use STL headers that disables that warning.

M$'s STL implementation isn't the best. There are memory leaks that are known and have been documented. You might want to drop in a better STL library such as stlport.org.

Tomasz Sowinski9-Aug-01 3:22

Tomasz Sowinski

9-Aug-01 3:22

M$'s STL implementation isn't the best.

In fact, the STL included in VC6 was developed by PJ Plauger of Dinkumware.

Tomasz Sowinski -- http://www.shooltz.com

Christian Graus8-Aug-01 12:23

8-Aug-01 12:23

I guess I just don't get it - what does the STL bring to the table that MFC doesn't do as well or better?

I'm only repeating myself and others, but I've already noted I am an STL zealot, so.....

I've actually recently read that the MFC containers were a stopgap as STL only recently became part of the standard. Having said that, you should certainly get stlport instead of using M$ crappy implimentation.

STL gives you a whole swag of cool functions you can plug in, a number of containers such as queue, vector, map ( which is a tree ), list, all of which can be plugged into the algorythms and work with each other ( so I can copy the contents of a tree into a vector in one line of code ). You can also write custom iterators for your own containers ( MSDN had an example that created an iterator for favourites from IE, meaning they could then be manipulated by the STL algorithms ).

I'd definately recommend this book:

The STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library

It's written by people who worked with Stepanov when he was writing it, and Stepanov himself provides the foreword. To date, everyone I have put onto this book has loved it and the STL.

Christian

Secrets of a happy marriage #27:

Never go to bed if you are mad at each other. It's more fun to stay up and fight.

8-Aug-01 12:53

One reason the warnings are generated is due to these templates producing names longer than 256 chars... gotta love templates. Wink | ;)