From: Sean O'Dell Date: 2002-02-25T06:02:38+09:00 Subject: Re: Object/Memory Management "Sean Middleditch" wrote in message news:1014566071.13609.2.camel@stargrazer... > > "Sean Middleditch" wrote in message > On Sat, > > > > 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. > > The stack has that one advantage, yes. There are a number of ways > around it (you just mentioned one yourself). However, the stack is just > an ugly hack for bad design. The stack does *not* in any way guarantee > that those objects are cleaned up. You can leave functions without > cleaning up (destroying) objects on the stack. Errors or exceptions can > occur during stack cleanup that you can't catch or deal with. The order > of object destruction is (in many compilers) not guaranteed. When you > have multiple objects that use/reference each other all destroyed on the > same fucntion cleanup, you'll start *really* seeing some problems. The order of object destruction *is* guaranteed and works correctly on every compiler I've worked with since Turbo C++. I don't have troubles at all with C++ and I've been programming with it heavily for 10 years. I don't believe the stack in C/C++ is an ugly hack for bad design. It's been a fantastic way to help manage memory. > I believe you mentioned earlier that you are unsure of your code's error > handling and stability, yes? Well, you have to make some sacrifices > (add three lines of code) in order to make that error handling better. That was in Perl, not C++. Perl's error handling is terrible and I have a quite a bit of code that I don't trust because I didn't add error checking everywhere possible. > C++ destructors weren't intended to do anything other than clear up > resources - letting them do otherwise is bad C++ design; too many things > can go wrong during destructors to let sensitive/complex code run in > them. That's why true destructors don't exist in Ruby... it would make > it too easy for Ruby code to cause the interpreter to crash, which > should never ever ever happen. ~,^ C++ was designed to provide wrappers for resources. C++ provides for object-oriented design. Resource management is just one of its features. There are no official recommendations as to what you use C++ destructors for, and I have seen them used for lots of different things with excellent results. > As I stated above, if your code depends on destructors of objects to do > tasks like opening, writing to, and closing a file, in addition to > memory cleanup, I'd expect your application would break down very easily > if an I/O error occured. No, because when exceptions occur, the specification is to unwind the stack, not longjmp out. If I have a file object with an open file and something throws an exception, when the file object leaves the try block, its destructor will get called allowing the file to be closed properly. > Ruby is contagious. Give yourself a week or two, and you'll be dying to > write C++ code with blocks passed to functions, or memory leak free.. > > Honestly, the stack method of being lazy and letting the compiler do > your cleanup for you shouldn't even be used in C++ programs that require > any kind of stability or dependibility. Ruby simplifies all that so > much. It puts the cleanup back in *your* hands, under your control, > where it should have been the whole time. If you need a file saved, you > control when it is done, and how the errors are handled. Stability is what C++ is very, very good at. I program with C++ heavily, and all the features you are saying cause problems have actually *solved* a lot of problems for myself and everyone I've ever coded with. > I'm sorry if I sounded like I was attacking your programming style; I'm > not. It's just that after some 7 years of C++, It's hard-coded into my > head which parts of it I steer clear of, and all its numerous > short-comings. I used to like programming in nothing but C++, now I > only touch it on projects that are already in C++. C is even prettier > in that it doesn't lend itself to making too many shortcuts, and you > avoid "bugs" like stack-based object destruction. ~,^ 7 years seems like a long time to have missed so much in C++. I don't doubt you didn't enjoy programming in it. Sean