From: Sean O'Dell Date: 2002-02-24T18:22:13+09:00 Subject: Re: Object/Memory Management "Sean Middleditch" wrote in message > On Sat, 2002-02-> If you are coming from a C++ background, then why not just define a > "close" method for your objects? It can't be any more cumbersome than > in C++, in which you would have add to explicitly call delete anyhow. Because, generally speaking, I create objects on the stack, which in turn dynamically allocate the memory they actually use internally (and free on destruction). I generally don't use new to create objects I use within functions because functions don't have reliable cleanup routines. C++ can catch exceptions, but there is no equivalent to "finally" or "ensure." Creating the objects on the stack ensures that they get cleaned up properly when they go out of scope. I've had tremendous success with this way of doing things. It's intuitive, it's dependable and best of all you can have a bad day coding and still not create anything terribly funky. > It's a choice of: (A) do you want the ease of letting the stack cleanup > for you, or (B) do you want the ease of never dealing with memory > management, again, ever. I'd rather have the stack way of doing things, complete with the automatic call to finalize. It's not just an issue of memory management. That's part of it, but the main thing to me is the encapsulation that the destructor provides. There's more to be done when an object goes out of scope than just return memory to the system. Losing that paradigm is a tough bullet to bite, but I am hearing a lot about how great garbage collection is, so I'm accepting it for now and I'll just see for myself. It should be apparent to me within a month or two how well this memory management system holds up. I wouldn't say I have a downright good feeling about this memory/destructor thing...but I have learned ways to work around doing what I'm already used to doing and I'm trusting all these very smart people not to be leading me blind off of a cliff. Sean