RE: again a newbee question

  • From: "Sina Bahram" <sbahram@xxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Thu, 14 Apr 2011 09:19:45 -0400

I definitely agree with that.

Take care,
Sina

-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx 
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Dave
Sent: Thursday, April 14, 2011 1:33 AM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: again a newbee question

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
>> >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.
>  >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,
>> >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

Other related posts:

  1. Home
  2. programmingblind
  3. Archive
  4. 04-2011