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