Roland Pibinger wrote:
On 15 Dec 2006 05:11:33 -0800, "Lew Pitcher" wrote:
Roland Pibinger wrote:
The compiler just needs to add the 'free' call(s) in the same scope in
which *alloc is called (in inverse order).
Nope. Not a good idea.
There are many examples where the results of malloc() are or can be
passed out of scope, to the next level higher. I certainly don't want
my compiler to throw away the deliberately malloc()ed memory that my
node allocation function in my binary tree builder grabbed. It is up to
the node deallocation function to do that.
Ok, then call those functions lmalloc ('local malloc') ... and
everything is clear. You can assign locally allocated memory to local
variables and pass it to other functions but you cannot return it or
assign it to non-local variables. In a sense alloca does something
similar (but only on the stack).
First off, I don't see the difference between your proposed lmalloc()
function and "automatic storage", other than your proposed lmalloc()
needs new compiler magic, where "automatic storage" does not.
Consider
{
struct a { int aa; char ab;};
struct a element, *ptr_to_element ; /* "automatic storage" */
ptr_to_element = &element;
/* do useful work with element, ptr_to_element */
} /* element, ptr_to_element automatically deallocated */
vs
{
struct a { int aa; char ab;};
struct a *ptr_to_element ;
ptr_to_element = lmalloc(sizeof *ptr_to_element );
/* do useful work with ptr_to_element */
} /* ptr_to_elementt automagically deallocated */
Of course, "automatic storage" doesn't need to be checked for
successful allocation, where your lmalloc() does. OTOH, "automatic
storage" only allocates the object and you have to derive a pointer in
code, where your lmalloc() only provides the pointer, which you must
use in all later work.
To me, your lmalloc() proposal is a half-measure. If you are going to
change the compiler and the language to perform an automatic garbage
collection, you might as well make it work properly and not require a
function call to allocate something that will not (and must not) be
deallocated by a function call. So, why not just add a new language
element instead of your lmalloc()? How about
{
struct a { int aa; char ab;};
new struct a *ptr_to_element ; /* keyword "new" takes the place of
lmalloc() */
/* do useful work with ptr_to_element */
} /* ptr_to_elementt automagically deallocated */
Of course, now we've made the complete tranformation to a new language
that looks like C++.
