Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Creeping feature #769: `new auto'
Keywords: dynamic stack allocation, alloca
Message-ID: <14847@exodus.Eng.Sun.COM>
Date: 10 Jun 91 20:48:25 GMT
References: <1991May2.074928.25507@kestrel.edu> <12759@exodus.Eng.Sun.COM> <1991May27.233808.14632@hal.com>
Sender: news@exodus.Eng.Sun.COM
Distribution: comp.std.c++
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 31

In article <1991May27.233808.14632@hal.com> shap@hal.com (Jonathan Shapiro) writes:
>In article <12759@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>>In theory, there's no need for alloca.  All the machinery needed to
>>implement running-of-destructors-for-local-objects can be used to
            ****************************************
>>simulate alloca on top of malloc and free.  It's not as efficient, but
>>it isn't impossible.
>>
>>David Chase
>>Sun
...
>Until recently, I was inclined to agree with you. Since then, I have
>run into at least one case where the need to use malloc/free becomes
>impossibly cumbersome: functions that do error recovery or error-based
>abandonment.

Nope, I included that in behavior in my model.  Once you also
implement the machinery for exception handling in C++ (whatever
machinery that is) you can simulate alloca in all important respects.
It could be horribly expensive if your exception-handling
implementation was bad (i.e., high cost in the normal case), or if
your memory allocator was slow (as it often is), but it would work
correctly.

Again, I don't recommend this implementation -- my point is definitely
"in theory".  (What was this all about, anyway?  Someone wanted a
nifty keyword on "new" to get simulated alloca?  That's moderately
reasonable, but not necessary.)

David Chase
Sun