Variable-length stack allocated arrays
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Tue Jan 12 00:40:31 PST 2010
grauzone wrote:
> 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.
I know. Clearly there is something in D that you find irresistibly
attractive; I wonder what that is :o).
> 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.
Of course I'm denying it because it's false. SafeD will not allow
programs containing manual free. And SafeD is quickly becoming a
reality, your pessimism notwithstanding.
Andrei
More information about the Digitalmars-d
mailing list