Escape analysis

Robert Fraser fraserofthenight at gmail.com
Wed Oct 29 00:20:35 PDT 2008


Bill Baxter wrote:
> On Wed, Oct 29, 2008 at 1:04 PM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>> "Walter Bright" wrote
>>> Sean Kelly wrote:
>>>> I think the cost/benefit of this could probably be argued either way.
>>>> I've never encountered a bug related to this, for example, so to me the
>>>> benefit is entirely theoretical while the cost is immediate.
>>> I have. Not often in my own code because I am very careful to avoid it,
>>> but it frequently happens in 'bug' reports I get sent. This trap does
>>> happen to programmers who are less familiar with how the underlying stack
>>> machine actually works.
>>>
>>> The real problem is there is no way to verify that this isn't happening in
>>> some arbitrarily large code base. I strongly believe that it is good for D
>>> and for programming languages in general to work towards a design that can
>>> provably eliminate certain types of bugs.
>> I agree with this.  It would be nice to be able to flag these kinds of
>> things.  Even if it was a warning and not a true error.  Just not a solution
>> which silently allocates data that shouldn't be allocated.
> 
> 
> Ok, I think we're completely on the same page here.  I'm for the
> compiler finding bugs.  But I'm not for the compiler being
> conservative and allocating memory when it doesn't have to, as it does
> currently.
> 
> --bb

How about adding a warning switch (I know Walter you're against them but 
it might be justified here) that would flag all the closure allocations. 
I know that should be the job of a "lint" tool, but the compiler already 
has the context here.



More information about the Digitalmars-d mailing list