Andrei Alexandrescu wrote:
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).
It's like a narcotic drug.
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.
Does this imply you'Re going to make SafeD default, and discourage use
of "unsafe" D?
Andrei
