C / C++ / MFC

7-Jan-04 4:49

Hello everyone,

I have been working on an MFC SDI program whose Document actually has lists of lists (and possibly a list of a list of a list). I would like to get into a good habit and be consistent with the way I maintain collections (mostly lists, occasionally arrays and maps). Almost all my objects are derived from CObject (for serializing, etc.).

I guess it comes down to picking between CList<type, type>, CList<type, type&>, CList<type*, type*> and whatever other combinations. To keep sane, I think I always want to use CList<type*, type*>. That way, I just use the new operator at the point where an object needs to be instantiated and call delete on it (while traversing the list or sublist) at the 'outer' list's destructor.

I would like comments about this. Is it safe? Is it a decent practice to keep? How can I prevent double deleting the same objects (if that could even happen)? Does this choice affect how I code the required copy constructor and assignment operator (which always seem to involve references)?

Thanks in advance for any advice and comments!
Eric

Christian Graus7-Jan-04 10:05

Christian Graus

7-Jan-04 10:05

Cloaca wrote:
To keep sane, I think I always want to use CList.

MFC containers are utter crap. Use std::list instead and you'll find a lot of the ancillary code you need to write will already be there for you.

Christian

I have drunk the cool-aid and found it wan and bitter. - Chris Maunder

Cloaca7-Jan-04 11:53

7-Jan-04 11:53

Thanks for your tip Christian.

I will look around to learn how to make std::list (part of the STL, right?) work with MFC (including topics like Serialization, etc.).

If you could suggest any resources in particular, that would be great.

Thanks again! Smile | :)

Eric

Mike Dimmick8-Jan-04 2:27

Mike Dimmick

8-Jan-04 2:27

It depends whether you want homogeneous (containing one type of object only) or heterogeneous (containing multiple types of object) containers.

If I want a homogeneous container, I typically have the container manage the storage of the contained objects. If the objects are small (perhaps ints), I use a CList< int, int >. If the objects are larger than about 8 bytes, I use CList< T, const T& > so that any functions which need an object (to store it, or compare it) take their argument by constant reference. You don't need to do any extra clean-up when you destroy the container; it destroys all the elements for you.

For a concrete definition of a heterogeneous container, consider a class hierarchy modelling shapes. We have an abstract base class CShape with derived classes CRectangle, CEllipse and CPolygon (for example). We want the container to be able to hold any combination of rectangles, ellipses, polygons and whatever else we might define in future.

To get polymorphic behaviour, we must store base class pointers. So I would normally declare the container as storing pointers of the type of the most-derived base class common to the elements to be contained. In this case I would use a CList< CShape*, CShape* >. The ARGTYPE is a CShape* because pointers are trivial to copy.

Lists of lists are tricky in MFC because CList doesn't define a copy constructor or assignment operator. You can't contain a CList inside a CList (although you can store CList pointers). If the top-level list is heterogeneous, you probably do need to use a list of CObject pointers, and MFC has a special class for that: CObList.

Cloaca8-Jan-04 5:02

8-Jan-04 5:02

Hi Mike,

I appreciate your response. From what you wrote it looks like if I need to maintain a collection of different objects (but all derived from a common base), then a CList< baseclass*, basclass*> is the way to go (which is what I had been thinking for 'my sanity's sake').

For trivially small things (e.g. ints), a CList<int, int> is good. This sounds good to me.

You wrote: "If the objects are larger than about 8 bytes, I use CList< T, const T& > so that any functions which need an object (to store it, or compare it) take their argument by constant reference."
What is the advantage of doing CList<T, const T&> over CList<T*, T*> ? Or, alternatively, is there a reason not to do CList<T*, T*> all the time?

Thanks again!
Eric

Mike Dimmick8-Jan-04 5:23

Mike Dimmick

8-Jan-04 5:23

I prefer the version without the pointers for three reasons:

I don't have to clean up the list myself (CList doesn't delete objects pointed to in the destructor).
I don't have to handle indirections.
The list has less memory-management overhead.

I'll deviate from this if I have to store references to the same object in multiple places in a list, but this is less common.

Cloaca8-Jan-04 11:33

Adding text display to dialog box

8-Jan-04 11:33

Hi Mike,

Thanks again.
About reason 1.: Most times, the objects that are in a list are made using a call to 'new' at some point in the code. If this is the case, then the contents of the list (the newed objects) need to get deleted at some point anyway. And this must be done by walking through the list in a loop to call delete for each item before doing a RemoveAll() on the list.

Or, do you have a methodology in coding that 'recycles' objects. That is, a variable of type CMyObject is declared and reused (has its data changed) whenever an item needs to be added to the list. Then, due to storing actual T's (not T*'s or T&'s), they are passed by reference into the CList by value (so that the declared variable can be changed for reuse to create the next item in the list). Is this what you mean? Does this mean that the destructor for each item in the list is called when the CList is destroyed?

Thanks very much,
Eric

Anonymous7-Jan-04 4:36

Anonymous

7-Jan-04 4:36

Hello,

I have a question. I have a dialog style window. Is it possible to add text display box to it? I plan to display some text at run time. Thanks.

Re: Adding text display to dialog box

valikac7-Jan-04 7:28

valikac

7-Jan-04 7:28

Definitely.

Kuphryn

Help with HANDLEs

Mortis7-Jan-04 4:14

Mortis

7-Jan-04 4:14

I need to write a program to run a few hundred executables, and read in their results into an array.
i've posted here, before and got help. using SHELLEXECUTEINFO i can specify the .exe and a paramater. which is really cool
but the upon executing, i get a HANDLE back
i was told to monitor the handle, but how?
i need to see the values that the .exe printf() 'ed onto the command line...

this is only a small part of the project and i dont have time to go learning all the details of handle programming...
so if anyone can help me out here it'd be soo cool
thanks

PS: i need to get this done soon, so any awnser would be great

Re: Help with HANDLEs

Dominik Reichl7-Jan-04 4:33

Dominik Reichl

7-Jan-04 4:33

I suggest you to have a look at the following articles here at CodeProject:

QuickWin - Turn a console application into a Windows program
http://www.codeproject.com/dialog/quickwin.asp[^]

Redirecting an arbitrary Console's Input/Output
http://www.codeproject.com/threads/redir.asp[^]

Universal Console Redirector
http://www.codeproject.com/threads/consolepipe.asp[^]

Hope that helps you further
Dominik

_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)

Re: Help with HANDLEs

valikac7-Jan-04 7:29

valikac

7-Jan-04 7:29

One solution is pipe as the other member has mentioned. Check out MSDN.

http://support.microsoft.com/default.aspx?scid=kb;en-us;190351

Kuphryn

Fucntion execution time

islheg7-Jan-04 3:49

islheg

7-Jan-04 3:49

Dear all,

How could I calculate the execution time of a function?

I used CTime, CTimeSpan, GetTickCount but the result is always zero.

Islam Hegazy

islam

фил7-Jan-04 4:30

фил

7-Jan-04 4:30

you could SetTimer() berfore calling the proc and KillTimer() after the proc returns. in the timer proc you can then increment a variable counting the amount of ms or secs depending on what interval you've specified.

hope this helps...

oren frenkel7-Jan-04 6:27

oren frenkel

7-Jan-04 6:27

Hi,
This is the way to do it through the Windows API function:

SYSTEMTIME sStart, sEnd;
float fEllapsedSec, ffEllapsedSecModulu;
long lEllapsedDays, lEllapsedHours, lEllapsedMin, lEllapsedSec, lEllapsedMilliSec;
CString strFuncTime;

::GetSystemTime(&sStart);

// call your function:

func();

::GetSystemTime(&_sEnd);

lEllapsedDays = sEnd.wDay - sStart.wDay;
lEllapsedHours = sEnd.wHour- sStart.wHour;
lEllapsedMin = sEnd.wMinute - sStart.wMinute;
lEllapsedSec = sEnd.wSecond - sStart.wSecond;
lEllapsedMilliSec = sEnd.wMilliseconds - sStart.wMilliseconds;
lEllapsedHours += lEllapsedDays*24;
lEllapsedMin += lEllapsedHours*60;
lEllapsedSec += lEllapsedMin*60 ;

// the total number of seconds:
fEllapsedSec = (float)lEllapsedSec + (float)lEllapsedMilliSec / 1000;

// for gui presentation:
lEllapsedHours = ((long)(fEllapsedSec / 3600));
lEllapsedMin = ((long)(fEllapsedSec / 60)) % 60;
ffEllapsedSecModulu = fEllapsedSec - ((int)(fEllapsedSec / 60) * 60); // cant use modulu on float

strFuncTime.Format("%d:%d:%.3f",lEllapsedHours,(lEllapsedMin % 60),ffEllapsedSecModulu);

Alexander ^M.,7-Jan-04 10:55

Alexander ^M.,

7-Jan-04 10:55

all of your answers are very very bad!

u have to use QueryPerformanceCounter and QueryPerformanceFrequency... there is an article on CP about calculating the CRC-32. it shows how such a timer works.

Don't try it, just do it! Wink | ;-)

pankajdaga8-Jan-04 3:57

pankajdaga

8-Jan-04 3:57

QueryPerformanceCounter and QueryPerformanceFrequency are used for extremely high frequency timing calculations. For his needs, it is a total over kill.

Pankaj

Without struggle, there is no progress