Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[James Kanze]

On Aug 17, 6:21 pm, Standish P stnd...@gmail.com wrote:
  Garbage collection doesn't use a stack. It uses a heap,
  which is in the abstract a collection of memory blocks of
  different lengths, divided into two lists, generally
  represented as linked lists:

  1.  A list of blocks that are free and may be used to store
  new data

  2.  A list of blocks that are in use, or haven't been freed (yet)

 Is this all that a heap is or is there more to it ?

There are many different ways to implement a heap.  The above is
not a good one, and I doubt that it's really used anywhere.

 I have been looking for simple but complete explanation of
 heap for a while and not gotten to it.

Complete in what sense?  The basic principle of how to use it is
simple.  As for how to implement it, there are many different
algorithms that can be used.

 I think I am looking for a stack allocation on the same
 pattern.

Stack allocation is far, far simpler (usually).

 In a disk, a file is fragmented in many contiguous blocks and
 is accessed automatically.

At the system level, the same thing holds for memory, and the
actual physical memory is fragmented into contiguous blocks,
each the size of a page.  The MMU (hardware) makes this
transparent to user programs, however.

  There is no way you could do memory management of all but the most
  trivial and fixed-length data chunks using a stack.

The length isn't the issue.  The order of allocation and freeing
is.  (For many specific uses, stack based allocators can and
have been used, but they don't work for generally allocation.)

--
James Kanze
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: which language allows you to change an argument's value?

[James Kanze]

On Sep 30, 6:49 pm, Summercool [EMAIL PROTECTED] wrote:
 On Sep 30, 4:18 am, 7stud -- [EMAIL PROTECTED] wrote:

  SpringFlowers AutumnMoon wrote:
   we have no way
   of knowing what we pass in could get changed.

  Sure you do.  You look at the function's signature.  In order to use
  someone else's library, you have to know the function's signature.  And
  the signature explicitly tells you whether the value you pass in could
  be changed.

That's not really correct.  It's more a case that if you don't
know what a function does, you don't use it.  Regardless of the
language, calling a function without knowing what it does is a
sure recepe for disaster.

 do you mean in C++?  I tried to find signature in two C++ books and it
 is not there.  Google has a few results but it looks something like
 prototype.  Is signature the same as the function prototype in the .h
 file?  If so, don't we usually just include ___.h and forget about
 the rest.  Documentation is fine although in some situation, the
 descriptions is 2 lines, and notes and warnings are 4, 5 times that,
 and the users' discussing it, holding different opinion is again 2, 3
 times of that length.  I think in Pascal and C, we can never have an
 argument modified unless we explicitly allow it, by passing in the
 pointer (address) of the argument.

In C, that's partially true; no part of the expressions involved
in the function invocation will be modified through the function
argument unless the address is specifically taken (or the
argument has array type).  The situation in Pascal, C++, Ada and
most other languages is different; Pascal and C++ have reference
parameters (called VAR in Pascal), as well as value paramters,
Ada has in, inout and out parameters.

The situation in Java is somewhat more complicated; formally,
Java only has pass by value, and there's no way a function can
modify any of the arguments.  In practice, however, if the
expression has an object type, the value is a pointer (called
reference in Java) to the object; if the object is a well
defined value type (e.g. java.lang.String), it will be
immutable, but entity objects don't follow this rule, and not
all value objects (e.g. java.awt.Dimension) are well designed.

 also i think for string, it is a bit different because by default,
 string is a pointer to char or the address of the first char in C and C
 ++.

Strings in C++ are class types, with full value semantics.

 So it is like passing in the address already.  it is when the
 argument n is something like 1 that makes me wonder.

C++ requires an lvalue unless the reference is to a const, so
you cannot pass 1 to a C++ function and expect/worry about it
being changed.  The same holds for most modern languages, I
think, although the mechanisms involved may differ.  (I'd be
very surprised, for example, if Ada allowed anything but what in
C++ would be an lvalue to be passed to an inout or an out
parameter.)  In most modern languages, however, you can
circumvent the controls with enough indirections.

--
James Kanze (GABI Software) email:[EMAIL PROTECTED]
Conseils en informatique orientée objet/
   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

-- 
http://mail.python.org/mailman/listinfo/python-list