>Let's go through, line by line:
O goody, I get to drink from the challus of over-whelming knowledge.
>>Ty: You are advocating using global functions to free up something that should
be OOP and probably is in a carefully>well-designed
>app.
>Memory management, by its definition has global components to it. this is true in
even managed contexts in which a>garbage collector runs globally.
Parts of it are global, yes. But we're not speaking of memory management here
now, are we? We're speaking of a well designed app.
>And also, I'm not saying register every little piece against atexit, but rather
use the built in features of the>language so you
>register the big boys, and cascade down from there; furthermore, it's completely
OO, because the registration process>can be done in
>an OO way via a myriad of means.
You've just given an example of how multiple inheritance and other features of
a language make this dificult to do.
>>Ty: So shall we all just use global pointers to resources so that the atexit
handlers can delete them?
>No
I'm glad you agree.
>>Ty: Just calling exit and leaving the OS to delete things kind of kills the
whole portability idea.
>Actually, it kills the idea of good design, but really has no effect on
portability, if you want to get technical>about semantics.
It does. because when I rely on an OS to free my memory and resources because
I'm to lazy to do it myself, some may do it differently or not at all, or bits
and pieces of it.
>>Ty: Sure Windows and Linux give you back the memory you've claimed, but there are
resources (direct 3d, as Chris>>already gave an
>>example of) that won't get freed, nor should they.
>I disagree. I do think that they, quote, should, unquote, and this is the entire
purpose behind the last decade of>language and
>programming environment design; however, I explained above how external
resources would be handled.
If your language that you are using is garbage collected, sure.
>>Ty: Also if you call out to a shared library that is mapped into two processes and
the library creates memory,>>without you free the
>>memory that your program requires, the memory is going to stay allocated
until the library gets unloaded.
>in process in IE for minimization of dom request delays via MSAA, I can't imagine
this is a good idea. You want to>talk about
>destroying any chance of good design or even the thought of portability ...
that's what to do right there.
If I call a function in a dll that creates a chunk of memory set aside for a dx
device for example, or anything else and I don't properly free that, that
memory has a chance of sticking around. Not only that, but anything that that
call created has a chance of sticking around as well. And if you are in a c++
program and you're calling out to libraries, you may or may not be deallocating
in destructors anyway.
>Second of all, you are repeatedly conflating library and program. Why would I
need to free memory that my program>requires in a
>discussion about a library which is mapped into it?
>I'd recommend actually learning about how modern operating systems perform
paging, memory management, and scheduling.>You have
>several of these concepts confused.
I don't, but thanks for the recommendation anyway.
>>Ty: I think confused is the right word, yes.
>Yes, I agree, confused is definitely the right word.
As you've very clearly just shown us.
>Take care,
>Sina
