PDA

View Full Version : Constructors Deconstructors question.


Deric
04-12-2008, 04:12 PM
Is the primary purpose, of Deconstructors, to maximise available memory? (seemingly at the expense of CPU, and memory I/O, cycles?)

Thanks.

Xenakios
04-12-2008, 04:34 PM
Well, you really SHOULD release any memory you have allocated, if you no longer need it. But certainly it's a bad idea to handle anything like that in a tight performance sensitive situation...You generally should arrange things to be so that you won't need to create and destroy objects (allocate and deallocate memory) in places in the code you need good performance for.

Deric
04-12-2008, 04:53 PM
Xenakios, thanks.

Yes I fully appreciate the requirement for (any) design to be optimised for its purpose.

I was asking to verify if I'd understood the primary usage of Constructors and Deconstructors - or if I'd missed something.

Xenakios
04-12-2008, 05:11 PM
I am quite baffled about constructors/destructors, allocation and deallocation of memory and how all that relates to scope. It seems in C++ the rules for all that are quite a bit different and more complex from Delphi/Pascal, what I am more familiar with. It's too easy to leak memory...

I wonder if there are any readily available tools to help with all that? In Delphi, I could set a variable called ReportMemoryLeaksOnShutdown to true at program start, and then, upon program exit, the Delphi memory manager would tell me if any memory had leaked. I guess it's hoping too much with Microsoft flavored C++... :o

Lawrence
04-12-2008, 06:22 PM
I too would like to know the answer to Deric's question. I'm doing some light reading on C++ (not quite ready to start any coding yet) and I don't quite get that one either.

I wonder if that's simlar to SET MyVar = ObjX (construct?) function in VB that creates objects in memory that are not necessarily always released when the subroutine ends, or even when the app exits, depending on what the object type is.

You have to (or probably should?) always release (deconstruct?) the object manually when you're done with it as in "MyVar = Nothing" in VB to release the resources.

Is that the same thing? Deconstructing = housekeeping?

sws
04-13-2008, 01:18 AM
Gents,
This is an involved subject so it's hard to describe in a quick post, but here goes:
In C++, most often you allocate variables on the stack, as in "int i;". Stack variables are "automatically" deallocated upon exit of the function/code block they were defined. The other way is to allocate variables/classes/etc on the heap using "new". "new" allocates memory, and every call to "new" needs a cooresponding "delete" call to deallocate the memory. So, to answer your question, Deric, most often if a class needs a chunk of memory it is allocated in the constructor with "new" and deallocated in the destructor with "delete". Destructors also often are used as points to close files, handles, etc.
Note: You call also allocate memory on the heap in the old C way, with malloc() and free(), but that's deprecated these days.

MSVC has a built in memory leak checker, just put this at the top of your .cpp file and you should get reports of "new" with missing "delete" in the output pane of MSVC at program exit in debug mode.

#ifdef _DEBUG
#define new DEBUG_NEW
#endif


Hope this makes sense, just got back from a gig. :)

schwa
04-14-2008, 07:31 AM
Without meaning to sound glib, destructors are for cleaning up when you're done with something. Most often this means free/deleting any memory that was allocated on the heap, but it can also mean closing connections, sending signals somewhere, or any other sort of "all done, time to clean up the mess" activity.

dub3000
05-25-2008, 02:18 AM
destructors in C++ are also deterministic - which means you can do fun things like create classes that do performance analysis on a function just by allocating them on the heap at the top of a function. you store the start time in the constructor and log the duration from the destructor.

or smart "dirty" screen updating inside lots of nested rendering code: lock buffer then increase count in a constructor, decrease count in the destructor and then render your buffer to screen when the count hits 0.

note that if you're doing your allocation on the stack then tricks like that are a lot harder to pull off safely.

still, i really miss having access to things like this in managed languages.