Variable-length stack allocated arrays

grauzone none at example.net
Tue Jan 12 00:27:23 PST 2010


Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> grauzone wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> The idea is that the API offers a means to define and use temporary 
>>>>> buffers without compromising memory safety. Even if you escape data 
>>>>> allocated via getBuffer that persists after releaseBuffer, that 
>>>>> will not cause undefined behavior. (It may, however, cause data to 
>>>>> be overwritten because another call to getBuffer will reuse 
>>>>> memory.) Leaks are also possible if you don't release the buffer. 
>>>>> That can be solved by not offering getBuffer and releaseBuffer as 
>>>>> they are, but instead only encapsulated in a struct with the 
>>>>> appropriate constructor and destructor.
>>>>
>>>> That's an interesting point. You can have two things:
>>>> 1. Correct memory managment (one can never access an object that's 
>>>> supposed to be free'd)
>>>> 2. Safe memory managment (event if you access an object that's 
>>>> supposed to be free'd, it's memory safe)
>>>>
>>>> In safe mode, 1. can't be allowed, and 2. is better than nothing. In 
>>>> normal D, I'd say 2. is quite useless, except as an debugging option.
>>>
>>> Normal D must be debuggable D.
>>
>> That isn't the case right now and never will be.
> 
> Then if I were you and I really believed that, I wouldn't waste one more 
> minute hanging out in this group.

Don't worry, I won't leave so easily.

That said, if you use "delete" (or GC.free) incorrectly, you may end up 
with an undebuggable program. Plus there's no way manual free will ever 
be removed from D. I'm sure you know that, but it sounds like you're 
denying that. Whatever.

> Andrei



More information about the Digitalmars-d mailing list