Re: again a newbee question

  • From: Christopher Coale <ccoale427@xxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Wed, 13 Apr 2011 23:13:17 -0700

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-designed
Memory management, by its definition has global components to it. this is
true in even managed contexts in which a>garbage collector runs
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?
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.
  >First of all, why are you mapping your library in process? Other than
some specific use cases such as how jaws runs pieces of itself
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,
View the list's information and change your settings at

View the list's information and change your settings at

View the list's information and change your settings at

Other related posts: