Old 04-12-2008, 04:12 PM   #1
Deric
Human being with feelings
 
Join Date: Mar 2007
Posts: 794
Default Constructors Deconstructors question.

Is the primary purpose, of Deconstructors, to maximise available memory? (seemingly at the expense of CPU, and memory I/O, cycles?)

Thanks.
__________________
REAPER? Oh yes...
Deric is offline   Reply With Quote
Old 04-12-2008, 04:34 PM   #2
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

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.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 04-12-2008, 04:53 PM   #3
Deric
Human being with feelings
 
Join Date: Mar 2007
Posts: 794
Default

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.
__________________
REAPER? Oh yes...
Deric is offline   Reply With Quote
Old 04-12-2008, 05:11 PM   #4
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

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++...
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 04-12-2008, 06:22 PM   #5
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

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?
Lawrence is offline   Reply With Quote
Old 04-13-2008, 01:18 AM   #6
sws
Code Monkey
 
sws's Avatar
 
Join Date: Sep 2007
Location: Madison, WI
Posts: 857
Default

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.
Code:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Hope this makes sense, just got back from a gig.
sws is offline   Reply With Quote
Old 04-14-2008, 07:31 AM   #7
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,749
Default

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.
schwa is offline   Reply With Quote
Old 05-25-2008, 02:18 AM   #8
dub3000
Human being with feelings
 
dub3000's Avatar
 
Join Date: Mar 2008
Location: Sydney, Australia
Posts: 3,955
Default

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.

Last edited by dub3000; 07-29-2008 at 04:26 PM. Reason: (stack not heap!)
dub3000 is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:49 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.