Of course, we all agreed that modern operating systems will take care of freeing most standard resources (most definitely including memory) when the program terminates. However, where we disagree is that Tyler (I think) and I believe that a resource, no matter whether it is a POSIX-standards-compliant resource or a HAL resource from some non-standard SDK, should be properly discarded by the user prior to the program being terminated, and therefore exit() should not be used simply because it's a convenient way of discarding all resources.
As I tutor C++ programming and TA the course, I see a lot of intro students using exit() when it very clearly should not be used. They first learn about the function and automatically think "an easy way to just end the program instead of returning control back to a caller." And that simply is not a good way to learn programming.. not all languages provide you with an easy escape like that, and when these intro students become dependent on it, it's just all around bad. I hope you understand my point here.
When taking a course in structured programming, the students need to learn just that -- structured control. Meaning, they need to be able to control the flow of function calls, and how they return, and error handling (such as making the function return an error code instead of "void" and then exiting).
Now, I personally absolutely disagree with using the exit() function in any case (not once in my years of programming have I ever used or needed the exit function, and I still don't use it). But.. my main point here is that it is definitely not good to introduce "exit" to intro to C or C++ students.
On a quick little side example, this is something that I see on so many assignments:
ifstream inData("someFile.txt");
if (! inData) { exit(1); }
when that code is inside a function other than main (sometimes inside
main as well). And then every now and then I see the dreaded
system("PAUSE"), but don't even get me started on that...
Anyways, that's my two cents. On 4/13/2011 10:32 PM, Dave wrote:
On a purely theoretical level, I agree with Sina. A vanilla, standards compliant, textbook OS would restrict a running process to a virtual memory addressing scheme (32 or 64 bit) and provide the illusion of all that memory. Under the hood, actual physical pages would be allocated for the process. Once exiting a process, just dump the allocated pages. However, in Windows land, making such an assumption leads to BSOD's, as well as other nasties since kernel access is kind of at your fingertips (less so in Vista/7). You also have dll injection as Sina pointed out. I'm totally ok with the exit() call as long as its in a class lower down the abstraction chain. Btw, it's a terrible idea to start learning how to code with C/C++ because of these "trivia" type of tidbits. It's not exactly the best computer science teaching has to offer... On 4/13/11, Littlefield, Tyler<tyler@xxxxxxxxxxxxx> wrote:On 4/13/2011 9:40 PM, Sina Bahram wrote: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-designedapp. 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?NoI'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.>First of all, why are you mapping your library in process? Other than some specific use cases such as how jaws runs pieces of itselfin 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__________ View the list's information and change your settings at //www.freelists.org/list/programmingblind__________ View the list's information and change your settings at //www.freelists.org/list/programmingblind
__________View the list's information and change your settings at //www.freelists.org/list/programmingblind
