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.
That said, I'd prefer solutions that follow 1. instead of 2. I'm sure it
can work somehow; it also worked with closures (at least partial) and
normal stack variables + ref.
Andrei