Max Lybbert
Posts: 314
Nickname: mlybbert
Registered: Apr, 2005
|
|
Re: Myths of Memory Management
|
Posted: Sep 7, 2005 10:21 AM
|
|
As I said, I'm not all that crazy about some of the acrobatics "exception safe C++" requires. I've largely ignored Java for the last few years because, until very recently, it was a language where easy things were easy, but nothing else was possible. Now some interesting research is going in that direction, so it's useful to learn some of the more recent idioms.
And, for the record, I keep trying to learn ML, but I keep running into math-only examples and I don't usually have math-only problems. I'm sure ML is useful in other domains, but that's been my hangup so far.
Now, on to the C++ view. I'm not a fan of those people who write:
void foo()
{ hotdog A = new hotdog(5);
// ... lots of stuff
delete A;
}
But I'm fine with:
void foo()
{ hotdog A(5);
// ... same stuff
};
And I'm fine with:
class lock_file
{ lock_file(std::fstream fs)
{ // lock fs
}
~lock_file()
{ // unlock fs
}
}
Which is then used:
void change_file(std::fstream file)
{ lock_file lck(file);
// do whatever w/ file
};
That is, as an automatic variable, ~lock_file will be called at the end of its scope -- I don't have to remember, AND I know WHEN it will happen. (Yes, I know many readers know this, but a few comments convinced me that many do not).
Of course, there's no reason to believe that C++ idioms will work in Java. OTOH, BECAUSE of GC, Java programmers must handle all other cleanup by hand (http://www.codeguru.com/java/tij/tij0051.shtml).
My reference to "finally" was actually not a reference to finalizers, but a reference to the strange attempt Java's designers made at making exception safe code (try ... catch ... finally). The concept is that the GC will take care of the memory leaks, but the finally block must be there to take care of any other necessary cleanup.
Is this a damning indictment of GC? Not at all. It's a question about the sanity of Java's implementors.
|
|
Previous Topic
